diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 25b0ff4753..795b340ba3 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -16,7 +16,7 @@ If you're working on a different localization (not English), or you are documenting a feature that will be part of a future release, see - https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use + https://kubernetes.io/docs/contribute/new-content/overview/#choose-which-git-branch-to-use for advice. --> diff --git a/Makefile b/Makefile index 56359bd32b..75d37f767d 100644 --- a/Makefile +++ b/Makefile @@ -36,7 +36,10 @@ serve: ## Boot the development server. hugo server --buildFuture docker-image: - $(DOCKER) build . --tag $(DOCKER_IMAGE) --build-arg HUGO_VERSION=$(HUGO_VERSION) + $(DOCKER) build . \ + --network=host \ + --tag $(DOCKER_IMAGE) \ + --build-arg HUGO_VERSION=$(HUGO_VERSION) docker-build: $(DOCKER_RUN) $(DOCKER_IMAGE) hugo diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 0a56370edd..bf78ef6a64 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -41,7 +41,6 @@ aliases: sig-docs-en-owners: # Admins for English content - bradtopol - daminisatya - - jaredbhatti - jimangel - kbarnard10 - kbhawkey @@ -59,7 +58,6 @@ aliases: sig-docs-en-reviews: # PR reviews for English content - bradtopol - daminisatya - - jaredbhatti - jimangel - kbarnard10 - kbhawkey @@ -125,6 +123,7 @@ aliases: sig-docs-id-reviews: # PR reviews for Indonesian content - girikuncoro - irvifa + - wahyuoi sig-docs-it-owners: # Admins for Italian content - fabriziopandini - mattiaperi @@ -171,7 +170,6 @@ aliases: - haibinxie - hanjiayao - lichuqiang - - markthink - SataQiu - tengqm - xiangpengzhao @@ -181,7 +179,6 @@ aliases: sig-docs-zh-reviews: # PR reviews for Chinese content - chenrui333 - idealhack - - markthink - SataQiu - tanjunchen - tengqm diff --git a/README-hi.md b/README-hi.md index 12bfeee63c..e572cfc738 100644 --- a/README-hi.md +++ b/README-hi.md @@ -36,7 +36,7 @@ > यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे Hugo का उपयोग करके स्थानीय रूप से साइट चलाना देखें। -यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे दिए गए Hugo का उपयोग करके स्थानीय रूप से [साइट को चलाने](#running-the-site-locally-using-hugo) का तरीका देखें। +यदि आप डॉकर के बिना स्थानीय रूप से वेबसाइट चलाना पसंद करते हैं, तो नीचे दिए गए Hugo का उपयोग करके स्थानीय रूप से [साइट को चलाने](#hugo-का-उपयोग-करते-हुए-स्थानीय-रूप-से-साइट-चलाना) का तरीका देखें। यदि आप [डॉकर](https://www.docker.com/get-started) चला रहे हैं, तो स्थानीय रूप से `कुबेरनेट्स-ह्यूगो` Docker image बनाएँ: diff --git a/README-ru.md b/README-ru.md index 357578acf8..bb290654a8 100644 --- a/README-ru.md +++ b/README-ru.md @@ -1,58 +1,9 @@ # Документация по 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) +[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) Добро пожаловать! Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за старания! -## Вклад в документацию - -Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Эта копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас. - -После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.** Вполне возможно, что более одного ревьювера Kubernetes оставят свои комментарии или даже может быть так, что новый комментарий ревьювера Kubernetes будет отличаться от первоначального назначенного ревьювера. Кроме того, в некоторых случаях один из ревьюверов может запросить технический обзор у [технического ревьювера Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers), если это будет необходимо. Ревьюверы сделают все возможное, чтобы как можно оперативно оставить свои предложения и пожелания, но время ответа может варьироваться в зависимости от обстоятельств. - -Узнать подробнее о том, как поучаствовать в документации Kubernetes, вы можете по ссылкам ниже: - -* [Начните вносить свой вклад](https://kubernetes.io/docs/contribute/start/) -* [Просмотр локальных изменений](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [Использование шаблонов страниц](http://kubernetes.io/docs/contribute/style/page-templates/) -* [Руководство по оформлению документации](http://kubernetes.io/docs/contribute/style/style-guide/) -* [Руководство по локализации Kubernetes](https://kubernetes.io/docs/contribute/localization/) - -## Файл `README.md` на других языках -| | | -|-------------------------------|-------------------------------| -| [Английский](README.md) | [Французский](README-fr.md) | -| [Корейский](README-ko.md) | [Немецкий](README-de.md) | -| [Португальский](README-pt.md) | [Хинди](README-hi.md) | -| [Испанский](README-es.md) | [Индонезийский](README-id.md) | -| [Китайский](README-zh.md) | [Японский](README-ja.md) | -| [Вьетнамский](README-vi.md) | [Итальянский](README-it.md) | -| [Польский]( README-pl.md) | [Украинский](README-uk.md) | -| | | - -## Запуск сайта локально с помощью Docker - -Рекомендованный способ запуска сайта Kubernetes на локальной машине - использовать специальный образ [Docker](https://docker.com), который включает статический генератор сайтов [Hugo](https://gohugo.io). - -> Если вы используете Windows, вам необходимо установить дополнительные инструменты через [Chocolatey](https://chocolatey.org). `choco install make` - -> Если вы хотите запустить сайт локально без Docker, обратитесь к разделу [Запуск сайта с помощью Hugo](#запуск-сайта-с-помощью-hugo) ниже на этой странице. - -Когда Docker [установлен и запущен](https://www.docker.com/get-started), соберите локально Docker-образ `kubernetes-hugo`, выполнив команду в консоли: - -```bash -make docker-image -``` - -После того, как вы собрали образ, можно запустить сайт локально: - -```bash -make docker-serve -``` - -Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы редактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере. - ## Запуск сайта с помощью Hugo Обратитесь к [официальной документации Hugo](https://gohugo.io/getting-started/installing/), чтобы установить Hugo. Убедитесь, что вы установили правильную версию Hugo, которая устанавливается в переменной окружения `HUGO_VERSION` в файле [`netlify.toml`](netlify.toml#L10). @@ -60,7 +11,9 @@ make docker-serve После установки Hugo, чтобы запустить сайт, выполните в консоли: ```bash -make serve +git clone https://github.com/kubernetes/website.git +cd website +hugo server --buildFuture ``` Эта команда запустит сервер Hugo на порту 1313. Откройте браузер и перейдите по ссылке http://localhost:1313, чтобы открыть сайт. Если вы отредактируете исходные файлы сайта, Hugo автоматически применит изменения и обновит страницу в браузере. @@ -74,9 +27,35 @@ make serve - [Канал в Slack](https://kubernetes.slack.com/messages/sig-docs) - [Рассылка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) +## Вклад в документацию + +Нажмите на кнопку **Fork** в правом верхнем углу, чтобы создать копию этого репозитория в ваш GitHub-аккаунт. Эта копия называется *форк-репозиторием*. Делайте любые изменения в вашем форк-репозитории, и когда вы будете готовы опубликовать изменения, откройте форк-репозиторий и создайте новый пулреквест, чтобы уведомить нас. + +После того, как вы отправите пулреквест, ревьювер Kubernetes даст по нему обратную связь. Вы, как автор пулреквеста, **должны обновить свой пулреквест после его рассмотрения ревьювером Kubernetes.** + +Вполне возможно, что более одного ревьювера Kubernetes оставят свои комментарии или даже может быть так, что новый комментарий ревьювера Kubernetes будет отличаться от первоначального назначенного ревьювера. Кроме того, в некоторых случаях один из ревьюверов может запросить технический обзор у [технического ревьювера Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers), если это будет необходимо. Ревьюверы сделают все возможное, чтобы как можно оперативно оставить свои предложения и пожелания, но время ответа может варьироваться в зависимости от обстоятельств. + +Узнать подробнее о том, как поучаствовать в документации Kubernetes, вы можете по ссылкам ниже: + +* [Начните вносить свой вклад](https://kubernetes.io/docs/contribute/) +* [Использование шаблонов страниц](http://kubernetes.io/docs/contribute/style/page-templates/) +* [Руководство по оформлению документации](http://kubernetes.io/docs/contribute/style/style-guide/) +* [Руководство по локализации Kubernetes](https://kubernetes.io/docs/contribute/localization/) + +## Файл `README.md` на других языках +| другие языки | другие языки | +|-------------------------------|-------------------------------| +| [Английский](README.md) | [Французский](README-fr.md) | +| [Корейский](README-ko.md) | [Немецкий](README-de.md) | +| [Португальский](README-pt.md) | [Хинди](README-hi.md) | +| [Испанский](README-es.md) | [Индонезийский](README-id.md) | +| [Китайский](README-zh.md) | [Японский](README-ja.md) | +| [Вьетнамский](README-vi.md) | [Итальянский](README-it.md) | +| [Польский]( README-pl.md) | [Украинский](README-uk.md) | + ### Кодекс поведения -Участие в сообществе Kubernetes регулируется [кодексом поведения Kubernetes](code-of-conduct.md). +Участие в сообществе Kubernetes регулируется [кодексом поведения CNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). ## Спасибо! diff --git a/README-uk.md b/README-uk.md index 53d8b2bb46..3aad33660a 100644 --- a/README-uk.md +++ b/README-uk.md @@ -1,27 +1,68 @@ + # Документація 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) +[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) + Вітаємо! В цьому репозиторії міститься все необхідне для роботи над [сайтом і документацією Kubernetes](https://kubernetes.io/). Ми щасливі, що ви хочете зробити свій внесок! + +## Запуск сайту локально зa допомогою Hugo + + +Для інструкцій з встановлення Hugo дивіться [офіційну документацію](https://gohugo.io/getting-started/installing/). Обов’язково встановіть розширену версію Hugo, яка позначена змінною оточення `HUGO_VERSION` у файлі [`netlify.toml`](netlify.toml#L10). + + +Після встановлення Hugo, запустіть сайт локально командою: + +```bash +git clone https://github.com/kubernetes/website.git +cd website +hugo server --buildFuture +``` + + +Команда запустить локальний Hugo-сервер на порту 1313. Відкрийте у своєму браузері http://localhost:1313, щоб побачити сайт. По мірі того, як ви змінюєте вихідний код, Hugo актуалізує сайт відповідно до внесених змін і оновлює сторінку у браузері. + + +## Спільнота, обговорення, внесок і підтримка + + +Дізнайтеся, як долучитися до спільноти Kubernetes на [сторінці спільноти](http://kubernetes.io/community/). + + +Для зв’язку із супроводжуючими проекту скористайтеся: + +- [Slack](https://kubernetes.slack.com/messages/sig-docs) +- [Поштова розсилка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + + ## Внесок у документацію + Ви можете створити копію цього репозиторія у своєму акаунті на GitHub, натиснувши на кнопку **Fork**, що розташована справа зверху. Ця копія називатиметься *fork* (відгалуження). Зробіть будь-які необхідні зміни у своєму відгалуженні. Коли ви будете готові надіслати їх нам, перейдіть до свого відгалуження і створіть новий pull request, щоб сповістити нас. -Після того, як ви створили pull request, рецензент Kubernetes зобов’язується надати вам по ньому чіткий і конструктивний коментар. **Ваш обов’язок як творця pull request - відкоригувати його відповідно до зауважень рецензента Kubernetes.** Також, зауважте: може статися так, що ви отримаєте коментарі від декількох рецензентів Kubernetes або від іншого рецензента, ніж той, якого вам було призначено від початку. Крім того, за потреби один із ваших рецензентів може запросити технічну перевірку від одного з [технічних рецензентів Kubernetes](https://github.com/kubernetes/website/wiki/Tech-reviewers). Рецензенти намагатимуться відреагувати вчасно, проте час відповіді може відрізнятися в залежності від обставин. + +Після того, як ви створили pull request, рецензент Kubernetes зобов’язується надати вам по ньому чіткий і конструктивний коментар. **Ваш обов’язок як творця pull request - відкоригувати його відповідно до зауважень рецензента Kubernetes.** + +Також, зауважте: може статися так, що ви отримаєте коментарі від декількох рецензентів Kubernetes або від іншого рецензента, ніж той, якого вам було призначено від початку. + + +Крім того, за потреби один із ваших рецензентів може запросити технічну перевірку від одного з технічних рецензентів Kubernetes, коли це необхідно. Рецензенти намагатимуться відреагувати вчасно, проте час відповіді може відрізнятися в залежності від обставин. + + Більше інформації про внесок у документацію Kubernetes ви знайдете у наступних джерелах: -* [Внесок: з чого почати](https://kubernetes.io/docs/contribute/start/) -* [Візуалізація запропонованих змін до документації](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) +* [Внесок: з чого почати](https://kubernetes.io/docs/contribute/) * [Використання шаблонів сторінок](http://kubernetes.io/docs/contribute/style/page-templates/) * [Керівництво зі стилю оформлення документації](http://kubernetes.io/docs/contribute/style/style-guide/) * [Переклад документації Kubernetes іншими мовами](https://kubernetes.io/docs/contribute/localization/) + ## Файл `README.md` іншими мовами -| | | +| інші мови | інші мови | |-------------------------------|-------------------------------| | [Англійська](README.md) | [Французька](README-fr.md) | | [Корейська](README-ko.md) | [Німецька](README-de.md) | @@ -30,55 +71,15 @@ | [Китайська](README-zh.md) | [Японська](README-ja.md) | | [В'єтнамська](README-vi.md) | [Російська](README-ru.md) | | [Італійська](README-it.md) | [Польська](README-pl.md) | -| | | -## Запуск сайту локально за допомогою Docker + +## Кодекс поведінки -Для локального запуску сайту Kubernetes рекомендовано запустити спеціальний [Docker](https://docker.com)-образ, що містить генератор статичних сайтів [Hugo](https://gohugo.io). - -> Якщо ви працюєте під Windows, вам знадобиться ще декілька інструментів, які можна встановити за допомогою [Chocolatey](https://chocolatey.org). `choco install make` - -> Якщо ви вважаєте кращим запустити сайт локально без використання Docker, дивіться пункт нижче [Запуск сайту локально за допомогою Hugo](#запуск-сайту-локально-зa-допомогою-hugo). - -Якщо у вас вже [запущений](https://www.docker.com/get-started) Docker, зберіть локальний Docker-образ `kubernetes-hugo`: - -```bash -make docker-image -``` - -Після того, як образ зібрано, ви можете запустити сайт локально: - -```bash -make docker-serve -``` - -Відкрийте у своєму браузері http://localhost:1313, щоб побачити сайт. По мірі того, як ви змінюєте вихідний код, Hugo актуалізує сайт відповідно до внесених змін і оновлює сторінку у браузері. - -## Запуск сайту локально зa допомогою Hugo - -Для інструкцій по установці Hugo дивіться [офіційну документацію](https://gohugo.io/getting-started/installing/). Обов’язково встановіть розширену версію Hugo, яка позначена змінною оточення `HUGO_VERSION` у файлі [`netlify.toml`](netlify.toml#L9). - -Після установки Hugo, запустіть сайт локально командою: - -```bash -make serve -``` - -Команда запустить локальний Hugo-сервер на порту 1313. Відкрийте у своєму браузері http://localhost:1313, щоб побачити сайт. По мірі того, як ви змінюєте вихідний код, Hugo актуалізує сайт відповідно до внесених змін і оновлює сторінку у браузері. - -## Спільнота, обговорення, внесок і підтримка - -Дізнайтеся, як долучитися до спільноти Kubernetes на [сторінці спільноти](http://kubernetes.io/community/). - -Для зв’язку із супроводжуючими проекту скористайтеся: - -- [Slack](https://kubernetes.slack.com/messages/sig-docs) -- [Поштова розсилка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) - -### Кодекс поведінки - -Участь у спільноті Kubernetes визначається правилами [Кодексу поведінки спільноти Kubernetes](code-of-conduct.md). + +Участь у спільноті Kubernetes визначається правилами [Кодексу поведінки СNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). + ## Дякуємо! -Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію! + +Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію! \ No newline at end of file diff --git a/README.md b/README.md index 3329b1a8c3..d3ee35693b 100644 --- a/README.md +++ b/README.md @@ -48,13 +48,13 @@ For more information about contributing to the Kubernetes documentation, see: | Language | Language | |---|---| -|[French](README-fr.md)|[Korean](README-ko.md)| +|[Chinese](README-zh.md)|[Korean](README-ko.md)| +|[French](README-fr.md)|[Polish](README-pl.md)| |[German](README-de.md)|[Portuguese](README-pt.md)| -|[Hindi](README-hi.md)|[Spanish](README-es.md)| -|[Indonesian](README-id.md)|[Chinese](README-zh.md)| +|[Hindi](README-hi.md)|[Russian](README-ru.md)| +|[Indonesian](README-id.md)|[Spanish](README-es.md)| +|[Italian](README-it.md)|[Ukrainian](README-uk.md)| |[Japanese](README-ja.md)|[Vietnamese](README-vi.md)| -|[Russian](README-ru.md)|[Italian](README-it.md)| -|[Polish](README-pl.md)|[Ukrainian](README-uk.md)| ## Code of conduct diff --git a/assets/sass/_base.sass b/assets/sass/_base.sass index c59d20c346..c8dedc0a72 100644 --- a/assets/sass/_base.sass +++ b/assets/sass/_base.sass @@ -439,6 +439,7 @@ footer width: 100% background-image: url(/images/texture.png) background-color: $dark-grey + overflow-x: hidden .main-section padding: 20px 0 @@ -1214,7 +1215,7 @@ $feature-box-div-margin-bottom: 40px margin-bottom: 20px #desktopKCButton - position: relative + position: absolute font-size: 18px background-color: $dark-grey border-radius: 8px @@ -1802,6 +1803,7 @@ $feature-box-div-margin-bottom: 40px img padding-bottom: 1rem + max-width: 100% div position: relative diff --git a/config.toml b/config.toml index 034b2e7c84..05430dc87b 100644 --- a/config.toml +++ b/config.toml @@ -14,24 +14,27 @@ contentDir = "content/en" timeout = 3000 -# Highlighting config. -pygmentsCodeFences = true -pygmentsUseClasses = false -# See https://help.farbox.com/pygments.html -pygmentsStyle = "emacs" - # Enable Git variables like commit, lastmod enableGitInfo = true # Norwegian ("no") is sometimes but not currently used for testing. # Hindi is disabled because it's currently in development. -# Italian is disabled until it meets minimum standards for quality. -disableLanguages = ["hi", "it", "no"] +disableLanguages = ["hi", "no"] -[blackfriday] -hrefTargetBlank = true -fractions = false -smartDashes = false +[markup] + [markup.goldmark] + [markup.goldmark.renderer] + unsafe = true + [markup.highlight] + codeFences = true + guessSyntax = false + hl_Lines = "" + lineNoStart = 1 + lineNos = false + lineNumbersInTable = true + noClasses = true + style = "emacs" + tabWidth = 4 [frontmatter] date = ["date", ":filename", "publishDate", "lastmod"] @@ -188,8 +191,8 @@ language_alternatives = ["en"] [languages.it] title = "Kubernetes" -description = "Production-Grade Container Orchestration" -languageName ="Italian" +description = "Orchestrazione di Container in produzione" +languageName = "Italiano" weight = 6 contentDir = "content/it" diff --git a/content/de/_index.html b/content/de/_index.html index adb2dce298..48df4cfd1f 100644 --- a/content/de/_index.html +++ b/content/de/_index.html @@ -14,23 +14,23 @@ Es gruppiert Container, aus denen sich eine Anwendung zusammensetzt, in logische {{% /blocks/feature %}} {{% blocks/feature image="scalable" %}} -#### Planet Scale +#### Ausgereift Kubernetes basiert auf denselben Prinzipien, die es Google ermöglichen, Milliarden von Containern pro Woche zu betreiben. {{% /blocks/feature %}} {{% blocks/feature image="blocks" %}} -#### Never Outgrow +#### Mitwachsend -Unabhängig davon, ob Sie lokal testen oder ein globales Unternehmen betreiben, die Flexibilität von Kubernetes wächst mit Ihnen, um Ihre Anwendungen konsistent und einfach bereitzustellen, unabhängig von der Komplexität Ihrer Anforderungen. +Unabhängig davon, ob Du lokal testest oder ein globales Unternehmen betreibst: Die Flexibilität von Kubernetes wächst mit Dir, um Deine Anwendungen konsistent und einfach bereitzustellen - Unabhängig von der Komplexität Deiner Anforderungen. {{% /blocks/feature %}} {{% blocks/feature image="suitcase" %}} -#### Run Anywhere +#### Überall Lauffähig -Kubernetes ist Open Source und bietet Ihnen die Freiheit, die Infrastruktur vor Ort, Hybrid oder Public Cloud zu nutzen. So können Sie Workloads mühelos dorthin verschieben, wo es Ihnen wichtig ist. +Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Ort, Hybrid oder Public Cloud zu nutzen. So kannst Du Workloads mühelos dorthin verschieben, wo es Dir wichtig ist. {{% /blocks/feature %}} @@ -39,17 +39,17 @@ Kubernetes ist Open Source und bietet Ihnen die Freiheit, die Infrastruktur vor {{< blocks/section id="video" background-image="kub_video_banner_homepage" >}}

Die Herausforderungen bei der Migration von über 150 Microservices auf Kubernetes

-

Von Sarah Wells, technischer Direktor für Betrieb und Zuverlässigkeit, Financial Times

+

Von Sarah Wells, technische Direktorin für Betrieb und Zuverlässigkeit, Financial Times




- Besuchen Sie die KubeCon vom 30 März-2 Apr. 2020 in Amsterdam + Besuche die KubeCon - 13-16 August 2020 in Amsterdam



- Besuchen Sie die KubeCon vom 28-30 Juli 2020 in Shanghai + Besuche die KubeCon - 17-20 November 2020 in Boston
diff --git a/content/en/_index.html b/content/en/_index.html index 794734e538..f54851f05d 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -45,7 +45,7 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise


- Attend KubeCon in Amsterdam on August 13-16, 2020 + Attend KubeCon EU virtually on August 17-20, 2020


diff --git a/content/en/blog/_index.md b/content/en/blog/_index.md index 2d534508aa..a16a4ffe49 100644 --- a/content/en/blog/_index.md +++ b/content/en/blog/_index.md @@ -8,3 +8,9 @@ menu: post: >

Read the latest news for Kubernetes and the containers space in general, and get technical how-tos hot off the presses.

--- +{{< comment >}} + +For information about contributing to the blog, see +https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post + +{{< /comment >}} 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 42f9b60e66..71a0fa26d9 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 @@ -144,7 +144,7 @@ The local persistent volume beta feature is not complete by far. Some notable en [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. -[Pod affinity and anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) ensures that your workloads stay either co-located or spread out across failure domains. If you have multiple local persistent volumes available on a single node, it may be preferable to specify an pod anti-affinity policy to spread your workload across nodes. Note that if you want multiple pods to share the same local persistent volume, you do not need to specify a pod affinity policy. The scheduler understands the locality constraints of the local persistent volume and schedules your pod to the correct node. +[Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) ensures that your workloads stay either co-located or spread out across failure domains. If you have multiple local persistent volumes available on a single node, it may be preferable to specify an pod anti-affinity policy to spread your workload across nodes. Note that if you want multiple pods to share the same local persistent volume, you do not need to specify a pod affinity policy. The scheduler understands the locality constraints of the local persistent volume and schedules your pod to the correct node. ## Getting involved diff --git a/content/en/blog/_posts/2018-10-10-runtimeclass.md b/content/en/blog/_posts/2018-10-10-runtimeclass.md index 6a889ada70..5c2ba7208b 100644 --- a/content/en/blog/_posts/2018-10-10-runtimeclass.md +++ b/content/en/blog/_posts/2018-10-10-runtimeclass.md @@ -27,7 +27,7 @@ Why is RuntimeClass a pod level concept? The Kubernetes resource model expects c ## What's next? -The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further. +The RuntimeClass resource is an important foundation for surfacing runtime properties to the control plane. For example, to implement scheduler support for clusters with heterogeneous nodes supporting different runtimes, we might add [NodeAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) terms to the RuntimeClass definition. Another area to address is managing the variable resource requirements to run pods of different runtimes. The [Pod Overhead proposal](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) was an early take on this that aligns nicely with the RuntimeClass design, and may be pursued further. Many other RuntimeClass extensions have also been proposed, and will be revisited as the feature continues to develop and mature. A few more extensions that are being considered include: diff --git a/content/en/blog/_posts/2020-03-18-Kong-Ingress-Controller-and-Service-Mesh.md b/content/en/blog/_posts/2020-03-18-Kong-Ingress-Controller-and-Service-Mesh.md index 2023f2e1da..02ff17838a 100644 --- a/content/en/blog/_posts/2020-03-18-Kong-Ingress-Controller-and-Service-Mesh.md +++ b/content/en/blog/_posts/2020-03-18-Kong-Ingress-Controller-and-Service-Mesh.md @@ -97,7 +97,16 @@ reviews-v2-ccffdd984-9jnsj 2/2 Running 0 101s reviews-v3-98dc67b68-nzw97 2/2 Running 0 101s ``` -This command outputs useful data, so let’s take a second to understand it. If you examine the READY column, each pod has two containers running: the service and an Envoy sidecar injected alongside it. Another thing to highlight is that there are three review pods but only 1 review service. The Envoy sidecar will load balance the traffic to three different review pods that contain different versions, giving us the ability to A/B test our changes. With that said, you should now be able to access your product page! +This command outputs useful data, so let’s take a second to understand it. If you examine the READY column, each pod has two containers running: the service and an Envoy sidecar injected alongside it. Another thing to highlight is that there are three review pods but only 1 review service. The Envoy sidecar will load balance the traffic to three different review pods that contain different versions, giving us the ability to A/B test our changes. We have one step before we can access the deployed application. We need to add an additional annotation to the `productpage` service. To do so, run: + +``` +$ kubectl annotate service productpage ingress.kubernetes.io/service-upstream=true +service/productpage annotated +``` + +Both the API gateway (Kong) and the service mesh (Istio) can handle the load-balancing. Without the additional `ingress.kubernetes.io/service-upstream: "true"` annotation, Kong will try to load-balance by selecting its own endpoint/target from the productpage service. This causes Envoy to receive that pod’s IP as the upstream local address, instead of the service’s cluster IP. But we want the service's cluster IP so that Envoy can properly load balance. + +With that added, you should now be able to access your product page! ``` $ kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o ".*" @@ -150,6 +159,8 @@ metadata: name: do-not-preserve-host route: preserve_host: false +upstream: + host_header: productpage.default.svc " | kubectl apply -f - kongingress.configuration.konghq.com/do-not-preserve-host created ``` diff --git a/content/en/blog/_posts/2020-05-05-introducing-podtopologyspread.md b/content/en/blog/_posts/2020-05-05-introducing-podtopologyspread.md new file mode 100644 index 0000000000..dfed13ca43 --- /dev/null +++ b/content/en/blog/_posts/2020-05-05-introducing-podtopologyspread.md @@ -0,0 +1,192 @@ +--- +title: "Introducing PodTopologySpread" +date: 2020-05-05 +slug: introducing-podtopologyspread +url: /blog/2020/05/Introducing-PodTopologySpread +--- + +**Author:** Wei Huang (IBM), Aldo Culquicondor (Google) + +Managing Pods distribution across a cluster is hard. The well-known Kubernetes +features for Pod affinity and anti-affinity, allow some control of Pod placement +in different topologies. However, these features only resolve part of Pods +distribution use cases: either place unlimited Pods to a single topology, or +disallow two Pods to co-locate in the same topology. In between these two +extreme cases, there is a common need to distribute the Pods evenly across the +topologies, so as to achieve better cluster utilization and high availability of +applications. + +The PodTopologySpread scheduling plugin (originally proposed as EvenPodsSpread) +was designed to fill that gap. We promoted it to beta in 1.18. + +## API changes + +A new field `topologySpreadConstraints` is introduced in the Pod's spec API: + +``` +spec: + topologySpreadConstraints: + - maxSkew: + topologyKey: + whenUnsatisfiable: + labelSelector: +``` + +As this API is embedded in Pod's spec, you can use this feature in all the +high-level workload APIs, such as Deployment, DaemonSet, StatefulSet, etc. + +Let's see an example of a cluster to understand this API. + +![API](/images/blog/2020-05-05-introducing-podtopologyspread/api.png) + +- **labelSelector** is used to find matching Pods. For each topology, we count + the number of Pods that match this label selector. In the above example, given + the labelSelector as "app: foo", the matching number in "zone1" is 2; while + the number in "zone2" is 0. +- **topologyKey** is the key that defines a topology in the Nodes' labels. In + the above example, some Nodes are grouped into "zone1" if they have the label + "zone=zone1" label; while other ones are grouped into "zone2". +- **maxSkew** describes the maximum degree to which Pods can be unevenly + distributed. In the above example: + - if we put the incoming Pod to "zone1", the skew on "zone1" will become 3 (3 + Pods matched in "zone1"; global minimum of 0 Pods matched on "zone2"), which + violates the "maxSkew: 1" constraint. + - if the incoming Pod is placed to "zone2", the skew on "zone2" is 0 (1 Pod + matched in "zone2"; global minimum of 1 Pod matched on "zone2" itself), + which satisfies the "maxSkew: 1" constraint. Note that the skew is + calculated per each qualified Node, instead of a global skew. +- **whenUnsatisfiable** specifies, when "maxSkew" can't be satisfied, what + action should be taken: + - `DoNotSchedule` (default) tells the scheduler not to schedule it. It's a + hard constraint. + - `ScheduleAnyway` tells the scheduler to still schedule it while prioritizing + Nodes that reduce the skew. It's a soft constraint. + +## Advanced usage + +As the feature name "PodTopologySpread" implies, the basic usage of this feature +is to run your workload with an absolute even manner (maxSkew=1), or relatively +even manner (maxSkew>=2). See the [official +document](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) +for more details. + +In addition to this basic usage, there are some advanced usage examples that +enable your workloads to benefit on high availability and cluster utilization. + +### Usage along with NodeSelector / NodeAffinity + +You may have found that we didn't have a "topologyValues" field to limit which +topologies the Pods are going to be scheduled to. By default, it is going to +search all Nodes and group them by "topologyKey". Sometimes this may not be the +ideal case. For instance, suppose there is a cluster with Nodes tagged with +"env=prod", "env=staging" and "env=qa", and now you want to evenly place Pods to +the "qa" environment across zones, is it possible? + +The answer is yes. You can leverage the NodeSelector or NodeAffinity API spec. +Under the hood, the PodTopologySpread feature will **honor** that and calculate +the spread constraints among the nodes that satisfy the selectors. + +![Advanced-Usage-1](/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-1.png) + +As illustrated above, you can specify `spec.affinity.nodeAffinity` to limit the +"searching scope" to be "qa" environment, and within that scope, the Pod will be +scheduled to one zone which satisfies the topologySpreadConstraints. In this +case, it's "zone2". + +### Multiple TopologySpreadConstraints + +It's intuitive to understand how one single TopologySpreadConstraint works. +What's the case for multiple TopologySpreadConstraints? Internally, each +TopologySpreadConstraint is calculated independently, and the result sets will +be merged to generate the eventual result set - i.e., suitable Nodes. + +In the following example, we want to schedule a Pod to a cluster with 2 +requirements at the same time: + +- place the Pod evenly with Pods across zones +- place the Pod evenly with Pods across nodes + +![Advanced-Usage-2](/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-2.png) + +For the first constraint, there are 3 Pods in zone1 and 2 Pods in zone2, so the +incoming Pod can be only put to zone2 to satisfy the "maxSkew=1" constraint. In +other words, the result set is nodeX and nodeY. + +For the second constraint, there are too many Pods in nodeB and nodeX, so the +incoming Pod can be only put to nodeA and nodeY. + +Now we can conclude the only qualified Node is nodeY - from the intersection of +the sets {nodeX, nodeY} (from the first constraint) and {nodeA, nodeY} (from the +second constraint). + +Multiple TopologySpreadConstraints is powerful, but be sure to understand the +difference with the preceding "NodeSelector/NodeAffinity" example: one is to +calculate result set independently and then interjoined; while the other is to +calculate topologySpreadConstraints based on the filtering results of node +constraints. + +Instead of using "hard" constraints in all topologySpreadConstraints, you can +also combine using "hard" constraints and "soft" constraints to adhere to more +diverse cluster situations. + +{{< note >}} +If two TopologySpreadConstraints are being applied for the same {topologyKey, +whenUnsatisfiable} tuple, the Pod creation will be blocked returning a +validation error. +{{< /note >}} + +## PodTopologySpread defaults + +PodTopologySpread is a Pod level API. As such, to use the feature, workload +authors need to be aware of the underlying topology of the cluster, and then +specify proper `topologySpreadConstraints` in the Pod spec for every workload. +While the Pod-level API gives the most flexibility it is also possible to +specify cluster-level defaults. + +The default PodTopologySpread constraints allow you to specify spreading for all +the workloads in the cluster, tailored for its topology. The constraints can be +specified by an operator/admin as PodTopologySpread plugin arguments in the +[scheduling profile configuration +API](/docs/reference/scheduling/profiles/) when starting +kube-scheduler. + +A sample configuration could look like this: + +``` +apiVersion: kubescheduler.config.k8s.io/v1alpha2 +kind: KubeSchedulerConfiguration +profiles: + pluginConfig: + - name: PodTopologySpread + args: + defaultConstraints: + - maxSkew: 1 + topologyKey: example.com/rack + whenUnsatisfiable: ScheduleAnyway +``` + +When configuring default constraints, label selectors must be left empty. +kube-scheduler will deduce the label selectors from the membership of the Pod to +Services, ReplicationControllers, ReplicaSets or StatefulSets. Pods can +always override the default constraints by providing their own through the +PodSpec. + +{{< note >}} +When using default PodTopologySpread constraints, it is recommended to disable +the old DefaultTopologySpread plugin. +{{< /note >}} + +## Wrap-up + +PodTopologySpread allows you to define spreading constraints for your workloads +with a flexible and expressive Pod-level API. In the past, workload authors used +Pod AntiAffinity rules to force or hint the scheduler to run a single Pod per +topology domain. In contrast, the new PodTopologySpread constraints allow Pods +to specify skew levels that can be required (hard) or desired (soft). The +feature can be paired with Node selectors and Node affinity to limit the +spreading to specific domains. Pod spreading constraints can be defined for +different topologies such as hostnames, zones, regions, racks, etc. + +Lastly, cluster operators can define default constraints to be applied to all +Pods. This way, Pods don't need to be aware of the underlying topology of the +cluster. diff --git a/content/en/blog/_posts/2020-05-06-third-party-dual-sourced-content.md b/content/en/blog/_posts/2020-05-06-third-party-dual-sourced-content.md new file mode 100644 index 0000000000..54b2910cf7 --- /dev/null +++ b/content/en/blog/_posts/2020-05-06-third-party-dual-sourced-content.md @@ -0,0 +1,60 @@ +--- +title: "How Docs Handle Third Party and Dual Sourced Content" +date: 2020-05-06 +slug: third-party-dual-sourced +url: /blog/2020/05/third-party-dual-sourced-content +--- + +**Author:** Zach Corleissen, Cloud Native Computing Foundation + +*Editor's note: Zach is one of the chairs for the Kubernetes documentation special interest group (SIG Docs).* + +Late last summer, SIG Docs started a community conversation about third party content in Kubernetes docs. This conversation became a [Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/pull/1327) (KEP) and, after five months for review and comment, SIG Architecture approved the KEP as a [content guide](/docs/contribute/style/content-guide/) for Kubernetes docs. + +Here's how Kubernetes docs handle third party content now: + +> Links to active content in the Kubernetes project (projects in the kubernetes and kubernetes-sigs GitHub orgs) are always allowed. +> +> Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker), networking policy (CNI plugins), Ingress controllers, and logging. +> +> Docs can link to third party open source software (OSS) outside the Kubernetes project if it’s necessary for Kubernetes to function. + +These common sense guidelines make sure that Kubernetes docs document Kubernetes. + +## Keeping the docs focused + +Our goal is for Kubernetes docs to be a trustworthy guide to Kubernetes features. To achieve this goal, SIG Docs is [tracking third party content](https://github.com/kubernetes/website/issues/20232) and removing any third party content that isn't both in the Kubernetes project _and_ required for Kubernetes to function. + +### Re-homing content + +Some content will be removed that readers may find helpful. To make sure readers have continous access to information, we're giving stakeholders until the [1.19 release deadline for docs](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.19), **July 9th, 2020** to re-home any content slated for removal. + +Over the next few months you'll see less third party content in the docs as contributors open PRs to remove content. + +## Background + +Over time, SIG Docs observed increasing vendor content in the docs. Some content took the form of vendor-specific implementations that aren't required for Kubernetes to function in-project. Other content was thinly-disguised advertising with minimal to no feature content. Some vendor content was new; other content had been in the docs for years. It became clear that the docs needed clear, well-bounded guidelines for what kind of third party content is and isn't allowed. The [content guide](https://kubernetes.io/docs/contribute/content-guide/) emerged from an extensive period for review and comment from the community. + +Docs work best when they're accurate, helpful, trustworthy, and remain focused on features. In our experience, vendor content dilutes trust and accuracy. + +Put simply: feature docs aren't a place for vendors to advertise their products. Our content policy keeps the docs focused on helping developers and cluster admins, not on marketing. + +## Dual sourced content + +Less impactful but also important is how Kubernetes docs handle _dual-sourced content_. Dual-sourced content is content published in more than one location, or from a non-canonical source. + +From the [Kubernetes content guide](https://kubernetes.io/docs/contribute/style/content-guide/#dual-sourced-content): + +> Wherever possible, Kubernetes docs link to canonical sources instead of hosting dual-sourced content. + +Minimizing dual-sourced content streamlines the docs and makes content across the Web more searchable. We're working to consolidate and redirect dual-sourced content in the Kubernetes docs as well. + +## Ways to contribute + +We're tracking third-party content in an [issue in the Kubernetes website repository](https://github.com/kubernetes/website/issues/20232). If you see third party content that's out of project and isn't required for Kubernetes to function, please comment on the tracking issue. + +Feel free to open a PR that removes non-conforming content once you've identified it! + +## Want to know more? + +For more information, read the issue description for [tracking third party content](https://github.com/kubernetes/website/issues/20232). diff --git a/content/en/case-studies/babylon/babylon_featured_logo.png b/content/en/case-studies/babylon/babylon_featured_logo.png new file mode 100644 index 0000000000..8b158b5ed3 Binary files /dev/null and b/content/en/case-studies/babylon/babylon_featured_logo.png differ diff --git a/content/en/case-studies/babylon/babylon_featured_logo.svg b/content/en/case-studies/babylon/babylon_featured_logo.svg new file mode 100644 index 0000000000..8bea0b8fc3 --- /dev/null +++ b/content/en/case-studies/babylon/babylon_featured_logo.svg @@ -0,0 +1 @@ +babylon_featured_logo \ No newline at end of file diff --git a/content/en/case-studies/babylon/index.html b/content/en/case-studies/babylon/index.html new file mode 100644 index 0000000000..afdc005411 --- /dev/null +++ b/content/en/case-studies/babylon/index.html @@ -0,0 +1,109 @@ +--- +title: Babylon Case Study +linkTitle: Babylon +case_study_styles: true +cid: caseStudies +css: /css/case-studies-gradient.css +logo: babylon_featured_logo.svg +featured: true +weight: 1 +quote: > + Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need. +--- + + +
+

CASE STUDY: Babylon

+
How Cloud Native Is Enabling Babylon’s Medical AI Innovations
+
+ +
+ Company  Babylon     Location  United Kingdom     Industry  AI, Healthcare +
+ +
+
+
+
+

Challenge

+ A large number of Babylon’s products leverage machine learning and artificial intelligence, and in 2019, there wasn’t enough computing power in-house to run a particular experiment. The company was also growing (from 100 to 1,600 in three years) and planning expansion into other countries. + + +

Solution

+ Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, so the infrastructure team turned to Kubeflow, a toolkit for machine learning on Kubernetes. “We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success,” says AI Infrastructure Lead Jérémie Vallée. The team began building a self-service AI training platform on top of Kubernetes. + +

Impact

+ Instead of waiting hours or days to be able to compute, teams can get access instantaneously. Clinical validations used to take 10 hours; now they are done in under 20 minutes. The portability of the cloud native platform has also enabled Babylon to expand into other countries.
+
+
+
+
+ “Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need.” +

- JÉRÉMIE VALLÉE, AI INFRASTRUCTURE LEAD AT BABYLON

+
+
+ + +
+
+

Babylon’s mission is to put accessible and affordable healthcare services in the hands of every person on earth.

+ +

Since its launch in the U.K. in 2013, the startup has facilitated millions of digital consultations around the world. In the U.K., patients were typically waiting a week or two for a doctor’s appointment. Through Babylon’s NHS service, GP at Hand—which has more than 75,000 registered patients—39% get an appointment through their phone within 30 minutes, and 89% within 6 hours.

+ +

That’s just the start. “We try to combine different types of technology with the medical expertise that we have in-house to build products that will help patients manage and understand their health, and also help doctors be more efficient at what they do,” says Jérémie Vallée, AI Infrastructure Lead at Babylon.

+ +

A large number of these products leverage machine learning and artificial intelligence, and in 2019, researchers hit a pain point. “We have some servers in-house where our researchers were doing a lot of AI experiments and some training of models, and we came to a point where we didn’t have enough compute in-house to run a particular experiment,” says Vallée.

+

+ Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, “and we had a lot of Kubernetes knowledge thanks to the migration,” he adds. To optimize some of the models that had been created, the team turned to Kubeflow, a toolkit for machine learning on Kubernetes. “We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success,” he says.

+

+ Based on that experience, Vallée’s team was tasked with building a self-service platform to help Babylon’s AI teams become more efficient, and by extension help get products to market faster. The main requirements: (1) the ability to give researchers and engineers access to the compute they needed, regardless of the size of the experiments they may need to run; (2) a way to provide teams with the best tools that they needed to do their work, on demand and in a centralized way; and (3) the training platform had to be close to the data that was being managed, because of the company’s expansion into different countries.

+ + +
+
+ +
+
+ “Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation.”

- CAROLINE HARGROVE, CHIEF TECHNOLOGY OFFICER AT BABYLON

+
+
+ +
+
+

+ Kubernetes was an enabler on every count. “Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need,” says Vallée. The need to keep data in every country in which Babylon operates requires a multi-region, multi-cloud strategy, and some countries might not even have a public cloud provider at all. “We wanted to make this platform portable so that we can run training jobs anywhere,” he says. “Kubernetes offered a base layer that allows you to deploy the platform outside of the cloud provider, and then deploy whatever tooling you need. That was a very good selling point for us.”

+

+ Once the team decided to build the Babylon AI Research platform on top of Kubernetes, they referred to the Cloud Native Landscape to build out the stack: Prometheus and Grafana for monitoring; an Istio service mesh to control the network on the training platform and control what access all of the workflows would have; Helm to deploy the stack; and Flux to manage the GitOps part of the pipeline.

+

+ The cloud native AI platform has had a huge impact at Babylon. The first research projects run on the platform mostly involved machine learning and natural language processing. These experiments required a huge amount of compute—1600 CPU, 3.2 TB RAM—which was much more than Babylon had in-house. Plus, access to compute used to take hours, or sometimes even days, depending on how busy the platform team was. “Now, with Kubernetes and the self-service platform that we provide, it’s pretty much instantaneous,” says Vallée.

+

+ Another important type of work that’s done on the platform is clinical validation for new applications such as Babylon’s Symptom Checker, which calculates the probability of a disease given the evidence input by the user. “Being in healthcare, we want all of our models to be safe before they’re going to hit production,” says Vallée. Using Argo for GitOps “enabled us to scale the process massively.”

+ +

+
+
+ + +
+
+ “Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases.”

- JEAN MARIE FERDEGUE, DIRECTOR OF PLATFORM OPERATIONS AT BABYLON

+
+
+ +
+
+

+ Researchers used to have to wait up to 10 hours to get results on new versions of their models. With Kubernetes, that time is now down to under 20 minutes. Plus, previously they could only run one clinical validation at a time, now they can run many parallel ones if they need to—a huge benefit considering that in the past three years, Babylon has grown from 100 to 1,600 employees.

+

+ “Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation,” says Chief Technology Officer Caroline Hargrove.

+

+ Adds Director of Platform Operations Jean Marie Ferdegue: “Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases.”

+

+ Plus, as Babylon continues to expand, “it will be very easy to onboard new countries,” says Vallée. “Fifteen months ago when we deployed this platform, we had one big environment in the U.K., but now we have one in Canada, we have one in Asia, and we have one coming in the U.S. This is one of the things that Kubernetes and the other cloud native projects have enabled for us.” +

+

+ Babylon’s road map for cloud native involves onboarding all of the company’s AI efforts to the platform. Increasingly, that includes AI services of care. “I think this is going to be an interesting field where AI and healthcare meet,” Vallée says. “It’s kind of a complex problem and there’s a lot of issues around this. So with our platform, we want to say, ‘What can we do to make this less painful for our developers and machine learning engineers?’” +

+
+
+ diff --git a/content/en/case-studies/booking-com/booking.com_featured_logo.png b/content/en/case-studies/booking-com/booking.com_featured_logo.png new file mode 100644 index 0000000000..623ca67345 Binary files /dev/null and b/content/en/case-studies/booking-com/booking.com_featured_logo.png differ 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 new file mode 100644 index 0000000000..298c77c773 --- /dev/null +++ b/content/en/case-studies/booking-com/booking.com_featured_logo.svg @@ -0,0 +1 @@ +booking.com_featured_logo \ No newline at end of file diff --git a/content/en/case-studies/booking-com/index.html b/content/en/case-studies/booking-com/index.html new file mode 100644 index 0000000000..ffeb3f2707 --- /dev/null +++ b/content/en/case-studies/booking-com/index.html @@ -0,0 +1,117 @@ +--- +title: Booking.com Case Study +linkTitle: Booking.com +case_study_styles: true +cid: caseStudies +css: /css/case-studies-gradient.css +logo: booking.com_featured_logo.png +featured: true +weight: 3 +quote: > + We realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. +--- + +​ + + +
+

CASE STUDY: Booking.com

+
After Learning the Ropes with a Kubernetes Distribution, Booking.com Built a Platform of Its Own
+
+​ +​ +
+ Company  Booking.com     Location  Netherlands     Industry  Travel +
+​ +
+
+
+
+

Challenge

+ In 2016, Booking.com migrated to an OpenShift platform, which gave product developers faster access to infrastructure. But because Kubernetes was abstracted away from the developers, the infrastructure team became a “knowledge bottleneck” when challenges arose. Trying to scale that support wasn’t sustainable. + + +

Solution

+ After a year operating OpenShift, the platform team decided to build its own vanilla Kubernetes platform—and ask developers to learn some Kubernetes in order to use it. “This is not a magical platform,” says Ben Tyler, Principal Developer, B Platform Track. “We’re not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we’re going to do everything we can to make sure they have access to that knowledge.” +​ +

Impact

+ Despite the learning curve, there’s been a great uptick in adoption of the new Kubernetes platform. Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn’t. On the new platform, it can take as few as 10 minutes. About 500 new services were built on the platform in the first 8 months. +
+
+
+
+
+ “As our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better, more native Kubernetes experience, which is great. It’s a super healthy dynamic.” +

- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM

+
+
+​ +​ +
+
+

Booking.com has a long history with Kubernetes: In 2015, a team at the travel platform prototyped a container platform based on Mesos and Marathon. +

+ +

Impressed by what the technology offered, but in need of enterprise features at its scale—the site handles more than 1.5 million room-night reservations a day on average—the team decided to adopt an OpenShift platform.

+ +

This platform, which was wrapped in a Heroku-style, high-level CLI interface, “was definitely popular with our product developers,” says Ben Tyler, Principal Developer, B Platform Track. “We gave them faster access to infrastructure.”

+ +

But, he adds, “anytime something went slightly off the rails, developers didn’t have any of the knowledge required to support themselves.”

+ +

And after a year of operating this platform, the infrastructure team found that it had become “a knowledge bottleneck,” he says. “Most of the developers who used it did not know it was Kubernetes underneath. An application failure and a platform failure both looked like failures of that Heroku-style tool.”

+

+ Scaling the necessary support did not seem feasible or sustainable, so the platform team needed a new solution. The understanding of Kubernetes that they had gained operating the OpenShift platform gave them confidence to build a vanilla Kubernetes platform of their own and customize it to suit the company’s needs.

+ + +
+
+​ +
+
+ “For entering the landscape, OpenShift was definitely very helpful. It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge.”

- EDUARD IACOBOAIA, SENIOR SYSTEM ADMINISTRATOR, B PLATFORM TRACK AT BOOKING.COM

+
+
+​ +
+
+

+ “For entering the landscape, OpenShift was definitely very helpful,” says Eduard Iacoboaia, Senior System Administrator, B Platform Track. “It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge.”

+

+ Iacoboaia’s team had customized a lot of OpenShift tools to make them work at Booking.com, and “those integrations points were kind of fragile,” he says. “We spent much more time understanding all the components of Kubernetes, how they work, how they interact with each other.” That research led the team to switch from OpenShift’s built-in Ansible playbooks to Puppet deployments, which are used for the rest of Booking’s infrastructure. The control plane was also moved from inside the cluster onto bare metal, as the company runs tens of thousands of bare-metal servers and a large infrastructure for running applications on bare metal. (Booking runs Kubernetes in multiple clusters in multiple data centers across the various regions where it has compute.) “We decided to keep it as simple as possible and to also use the tools that we know best,” says Iacoboaia.

+

+ The other big change was that product engineers would have to learn Kubernetes in order to onboard. “This is not a magical platform,” says Tyler. “We’re not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we’re going to do everything we can to make sure they have access to that knowledge.” That includes trainings, blog posts, videos, and Udemy courses.

+

+ Despite the learning curve, there’s been a great uptick in adoption of the new Kubernetes platform. “I think the reason we’ve been able to strike this bargain successfully is that we’re not asking them to learn a proprietary app system,” says Tyler. “We’re asking them to learn something that’s open source, where the knowledge is transferable. They’re investing in their own careers by learning Kubernetes.”

+

+ One clear sign that this strategy has been a success is that in the support channel, when users have questions, other product engineers are jumping in to respond. “I haven’t seen that kind of community engagement around a particular platform product internally before,” says Tyler. “It helps a lot that it’s visibly an ecosystem standard outside of the company, so people feel value in investing in that knowledge and sharing it with others, which is really, really powerful.”

+ + +
+
+​ +​ +
+
+ “We have a tutorial. You follow the tutorial. Your code is running. Then, it’s business-logic time. The time to gain access to resources is decreased enormously.”

- BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM

+
+
+​ +
+
+

+ There’s other quantifiable evidence too: Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn’t. On the new platform, it takes 10 minutes. “We have a tutorial. You follow the tutorial. Your code is running. Then, it’s business-logic time,” says Tyler. “The time to gain access to resources is decreased enormously.” About 500 new services were built in the first 8 months on the platform, with hundreds of releases per day.

+

+ The platform offers different “layers of contracts, so to speak,” says Tyler. “At the very base, it’s just Kubernetes. If you’re a pro Kubernetes user, here’s a Kubernetes API, just like you get from GKE or AKS. We’re trying to be a provider on that same level. But our whole job inside the company is to be a bigger value add than just vanilla infrastructure, so we provide a set of base images for our main stacks, Perl and Java.” +

+

+ And “as our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better more native Kubernetes experience, which is great,” says Tyler. “It’s a super healthy dynamic.”

+

+ The platform also includes other CNCF technologies, such as Envoy, Helm, and Prometheus. Most of the critical service traffic for Booking.com is routed through Envoy, and Prometheus is used primarily to monitor infrastructure components. Helm is consumed as a packaging standard. The team also developed and open sourced Shipper, an extension for Kubernetes to add more complex rollout strategies and multi-cluster orchestration. +

+

+ To be sure, there have been internal discussions about the wisdom of building a Kubernetes platform from the ground up. “This is not really our core competency—Kubernetes and travel, they’re kind of far apart, right?” says Tyler. “But we’ve made a couple of bets on CNCF components that have worked out really well for us. Envoy and Kubernetes, in particular, have been really beneficial to our organization. We were able to customize them, either because we could look at the source code or because they had extension points, and we were able to get value out of them very quickly without having to change any paradigms internally.” +

+
+
+ 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 new file mode 100644 index 0000000000..b844d99846 --- /dev/null +++ b/content/en/case-studies/booz-allen/booz-allen-featured-logo.svg @@ -0,0 +1 @@ +booz-allen-featured \ No newline at end of file diff --git a/content/en/case-studies/booz-allen/booz-allen_featured_logo.png b/content/en/case-studies/booz-allen/booz-allen_featured_logo.png new file mode 100644 index 0000000000..f9bc64ba3b Binary files /dev/null and b/content/en/case-studies/booz-allen/booz-allen_featured_logo.png differ diff --git a/content/en/case-studies/booz-allen/index.html b/content/en/case-studies/booz-allen/index.html new file mode 100644 index 0000000000..2a48c7f3b7 --- /dev/null +++ b/content/en/case-studies/booz-allen/index.html @@ -0,0 +1,103 @@ +--- +title: Booz Allen Case Study +linkTitle: Booz Allen Hamilton +case_study_styles: true +cid: caseStudies +css: /css/case-studies-gradient.css +logo: booz-allen-featured-logo.svg +featured: true +weight: 2 +quote: > + Kubernetes is a great solution for us. It allows us to rapidly iterate on our clients’ demands. +--- +​ + + +
+

CASE STUDY: Booz Allen Hamilton

+
How Booz Allen Hamilton Is Helping Modernize the Federal Government with Kubernetes
+
+​ +​ +
+ Company  Booz Allen Hamilton     Location  United States     Industry  Government +
+​ +
+
+
+
+

Challenge

+ In 2017, Booz Allen Hamilton’s Strategic Innovation Group worked with the federal government to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country. The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton’s customers. + +

Solution

+ “The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture and containers, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have,” says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff. To meet those requirements, Folkoff’s team looked to Kubernetes for orchestration. +​ +

Impact

+ With the recreation.gov Kubernetes platform, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day. With monitoring, security, and logging built in, developers can create and publish new services to production within a week. Additionally, Folkoff says, “supporting the large, existing monoliths in the government is extremely expensive,” and migrating into a more modern platform has resulted in perhaps 50% cost savings. +
+
+
+
+
+ "When there’s a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that’s the problem we’re trying to help the government solve with tools like Kubernetes." +

- JOSH BOYD, CHIEF TECHNOLOGIST AT BOOZ ALLEN HAMILTON

+
+
+​ +​ +
+
+

The White House launched an IT modernization effort in 2017, and in addition to improving cybersecurity and shifting to the public cloud and a consolidated IT model, “the federal government is looking to provide a better experience to citizens in every way that we interact with the government through every channel,” says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff.

+ +

To that end, Folkoff’s Strategic Innovation Group worked with the federal government last year to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country.

+ +

The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton’s customers. “The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have,” says Folkoff.

+
+
+​ +
+
+ "With CNCF, there’s a lot of focus on scale, and so there’s a lot of comfort knowing that as the project grows, we’re going to be comfortable using that tool set."

- MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON

+
+
+​ +
+
+

+ Booz Allen Hamilton, which has provided consulting services to the federal government for more than a century, introduced microservices, Docker containers, and AWS to its federal agency clients about five years ago. The next logical step was Kubernetes for orchestration. “Knowing that we had to be really agile and really reliable and scalable, we felt that the only technology that we know that can enable those kinds of things are the ones the CNCF provides,” Folkoff says. “One of the things that is always important for the government is to make sure that the things that we build really endure. Using technology that is supported across multiple different companies and has strong governance gives people a lot of confidence.”

+

+ Kubernetes was also aligned with the government’s open source and IT modernization initiatives, so there has been an uptick in its usage at federal agencies over the past two years. “Now that Kubernetes is becoming offered as a service by the cloud providers like AWS and Microsoft, we’re starting to see even more interest,” says Chief Technologist Josh Boyd. Adds Folkoff: “With CNCF, there’s a lot of focus on scale, and so there’s a lot of comfort knowing that as the project grows, we’re going to be comfortable using that tool set.”

+

+ The greenfield recreation.gov project allowed the team to build a new Kubernetes-enabled site running on AWS, and the migration lasted only a week, when the old site didn’t take bookings. “For the actual transition, we just swapped a DNS server, and it only took about 35 seconds between the old site being down and our new site being up and available,” Folkoff adds.

+

+
+
+​ +​ +
+
+ "Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day’s event"

- MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON

+
+
+​ +
+
+

+ In addition to its work with the Department of Interior for recreation.gov, Booz Allen Hamilton has brought Kubernetes to various Defense, Intelligence, and civilian agencies. Says Boyd: “When there’s a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that’s the problem we’re trying to help the government solve with tools like Kubernetes.”

+

+ For recreation.gov, the impact was clear and immediate. With the Kubernetes platform, Folkoff says, “if a new requirement for a permit comes out, we have the ability to design and develop and implement that completely independently of reserving a campsite. It provides a much better experience to users.” Today, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day.

+

+ Developer velocity has been improved. “When I want to do monitoring or security or logging, I don’t have to do anything to my services or my application to enable that anymore,” says Boyd. “I get all of this magic just by being on the Kubernetes platform.” With all of those things built in, developers can create and publish new services to production within one week.

+

+ Additionally, Folkoff says, “supporting the large, existing monoliths in the government is extremely expensive,” and migrating into a more modern platform has resulted in perhaps 50% cost savings. “Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day’s event,” he says. “For example, during a popular campsite release, camping-related services are scaled out while permit services are scaled down.”

+

+ So far, “Kubernetes is a great solution for us,” says Folkoff. “It allows us to rapidly iterate on our clients’ demands.” Looking ahead, the team sees further adoption of the Kubernetes platform across federal agencies. Says Boyd: “You get the ability for the rapid delivery of business value for your customers. You now have observability into everything that you’re doing. You don’t have these onesies and twosies unicorn servers anymore. Now everything that you deploy is deployed in the same way, it’s all instrumented the same way, and it’s all built and deployed the same way through our CI/CD processes.”

+

+ They also see a push toward re-platforming. “There’s still a lot of legacy workloads out there,” says Boyd. “We’ve got the new challenges of greenfield development and integration with legacy systems, but also that brown field of ‘Hey, how do I take this legacy monolith and get it onto a platform where now it’s instrumented with all the magic of the Kubernetes platform without having to do a whole lot to my application?’ I think re-platforming is a pretty big use case for the government right now.”

+

+ And given the success that they’ve had with Kubernetes so far, Boyd says, “I think at this point that technology is becoming pretty easy to sell.” Adds Folkoff: “People are really excited about being able to deploy, scale, be reliable, and do cheaper maintenance of all of this.” +

+
+
+ diff --git a/content/en/case-studies/ccp-games/ccp_featured.svg b/content/en/case-studies/ccp-games/ccp_featured.svg deleted file mode 100644 index e6313711d7..0000000000 --- a/content/en/case-studies/ccp-games/ccp_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/ccp-games/ccp_logo.png b/content/en/case-studies/ccp-games/ccp_logo.png deleted file mode 100644 index cbf3d267ba..0000000000 Binary files a/content/en/case-studies/ccp-games/ccp_logo.png and /dev/null differ diff --git a/content/en/case-studies/ccp-games/index.html b/content/en/case-studies/ccp-games/index.html deleted file mode 100644 index 8867cbb323..0000000000 --- a/content/en/case-studies/ccp-games/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: CCP Games -content_url: https://cloud.google.com/customers/ccp-games/ ---- \ No newline at end of file diff --git a/content/en/case-studies/chinaunicom/index.html b/content/en/case-studies/chinaunicom/index.html index 675273c47f..296b2ce1fc 100644 --- a/content/en/case-studies/chinaunicom/index.html +++ b/content/en/case-studies/chinaunicom/index.html @@ -5,11 +5,7 @@ linkTitle: chinaunicom case_study_styles: true cid: caseStudies css: /css/style_case_studies.css -logo: chinaunicom_featured_logo.png -featured: true -weight: 1 -quote: > - Kubernetes has improved our experience using cloud infrastructure. There is currently no alternative technology that can replace it. +featured: false ---
diff --git a/content/en/case-studies/comcast/comcast_featured.svg b/content/en/case-studies/comcast/comcast_featured.svg deleted file mode 100644 index 04d4ea70e2..0000000000 --- a/content/en/case-studies/comcast/comcast_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/comcast/comcast_logo.png b/content/en/case-studies/comcast/comcast_logo.png deleted file mode 100644 index 3f0ef76645..0000000000 Binary files a/content/en/case-studies/comcast/comcast_logo.png and /dev/null differ diff --git a/content/en/case-studies/comcast/index.html b/content/en/case-studies/comcast/index.html deleted file mode 100644 index 7ace6a246d..0000000000 --- a/content/en/case-studies/comcast/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Comcast -content_url: https://youtu.be/lmeFkH-rHII ---- \ No newline at end of file diff --git a/content/en/case-studies/concur/concur_featured_logo.png b/content/en/case-studies/concur/concur_featured_logo.png deleted file mode 100644 index 473427a3ba..0000000000 Binary files a/content/en/case-studies/concur/concur_featured_logo.png and /dev/null differ diff --git a/content/en/case-studies/concur/concur_featured_logo.svg b/content/en/case-studies/concur/concur_featured_logo.svg deleted file mode 100644 index 3b05edd28e..0000000000 --- a/content/en/case-studies/concur/concur_featured_logo.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/concur/index.html b/content/en/case-studies/concur/index.html deleted file mode 100644 index 0bb619f527..0000000000 --- a/content/en/case-studies/concur/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Concur -content_url: http://searchitoperations.techtarget.com/news/450297178/Tech-firms-roll-out-Kubernetes-in-production ---- \ 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 new file mode 100644 index 0000000000..375d9cefbc --- /dev/null +++ b/content/en/case-studies/denso/denso_featured_logo.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/en/case-studies/denso/index.html b/content/en/case-studies/denso/index.html new file mode 100644 index 0000000000..3ad0812d24 --- /dev/null +++ b/content/en/case-studies/denso/index.html @@ -0,0 +1,110 @@ +--- +title: Denso Case Study +linkTitle: Denso +case_study_styles: true +cid: caseStudies +css: /css/case-studies-gradient.css +logo: denso_featured_logo.svg +featured: true +weight: 4 +quote: > + We got Kubernetes experts involved on our team, and it dramatically accelerated development speed. +--- + + +
+

CASE STUDY: Denso

+
How DENSO Is Fueling Development on the Vehicle Edge with Kubernetes
+
+ +
+ Company  Denso     Location  Japan     Industry  Automotive, Edge +
+ +
+
+
+
+

Challenge

+ DENSO Corporation is one of the biggest automotive components suppliers in the world. With the advent of connected cars, the company launched a Digital Innovation Department to expand into software, working on vehicle edge and vehicle cloud products. But there were several technical challenges to creating an integrated vehicle edge/cloud platform: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says R&D Product Manager Seiichi Koizumi. + + +

Solution

+ Koizumi’s team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes (GKE, EKS, AKS). + +

Impact

+ Critical layer features can take 2-3 years to implement in the traditional, waterfall model of development at DENSO. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and a new prototype is introduced every week. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," says Koizumi. +
+
+
+
+ "Another disruptive innovation is coming, so to survive in this situation, we need to change our culture." +

- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO

+
+
+ + +
+
+

Spun off from Toyota in 1949, DENSO Corporation is one of the top automotive suppliers in the world today, with consolidated net revenue of $48.3 billion. +

+ +

The company’s mission is "contributing to a better world by creating value together with a vision for the future"—and part of that vision in recent years has been development on the vehicle edge and vehicle cloud.

+ +

With the advent of connected cars, DENSO established a Digital Innovation Department to expand its business beyond the critical layer of the engine, braking systems, and other automotive parts into the non-critical analytics and entertainment layer. Comparing connected cars to smartphones, R&D Product Manager Seiichi Koizumi says DENSO wants the ability to quickly and easily develop and install apps for the "blank slate" of the car, and iterate them based on the driver’s preferences. Thus "we need a flexible application platform," he says.

+ +

But working on vehicle edge and vehicle cloud products meant there were several technical challenges: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says Koizumi. "We are tackling these challenges to create an integrated vehicle edge/cloud platform."

+ + +
+
+ +
+
+ "We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."

— SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO

+
+
+ +
+
+

+ Koizumi’s team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. As they evaluated technologies, they were led by these criteria: Because their service-enabler business needed to support multiple cloud and on-premise environments, the solution needed to be cloud agnostic, with no vendor lock-in and open governance. It also had to support an edge-cloud integrated environment.

+

+ After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. During implementation, the team used "design thinking to clarify use cases and their value proposition," says Koizumi. Next, an agile development team worked on a POC, then an MVP, in DevOps style. "Even in the development phase, we are keeping a channel to end users," he adds.

+

+ One lesson learned during this process was the value of bringing in experts. "We tried to learn Kubernetes and cloud native technologies from scratch, but it took more time than expected," says Koizumi. "We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."

+ +

+
+
+ + +
+
+ "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation."

- SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO

+
+
+ +
+
+

+ Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes on GKE, EKS, and AKS. "We are developing a vehicle edge/cloud integrated platform based on a microservice and service mesh architecture," says Koizumi. "We extend cloud into multiple vehicle edges and manage it as a unified platform."

+

+ Cloud native has enabled DENSO to deliver applications via its new dash cam, which has a secure connection that collects data to the cloud. "It’s like a smartphone," he says. "We are installing new applications and getting the data through the cloud, and we can keep updating new applications all through the dash cam."

+

+ The unified cloud native platform, combined with agile development, has had a positive impact on productivity. Critical layer features—those involving engines or braking systems, for example—can take 2-3 years to implement at DENSO, because of the time needed to test safety, but also because of the traditional, waterfall model of development. With the Kubernetes platform and agile methods, there’s a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and with the department’s scrum-style development, a new prototype is introduced every week.

+

+ Application portability has also led to greater developer efficiency. "There’s no need to care about differences in the multi-cloud platform anymore," says Koizumi. Now, "we are also trying to have the same portability between vehicle edge and cloud platform." +

+

+ Another improvement: Automotive Tier-1 suppliers like DENSO always have multiple Tier-2 suppliers. "To provide automotive-grade high-availability services, we tried to do the same thing on a multi-cloud platform," says Koizumi. Before Kubernetes, maintaining two different systems simultaneously was difficult. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," he says. +

+

+Cloud native has also profoundly changed the culture at DENSO. The Digital Innovation Department is known as "Noah’s Ark," and it has grown from 2 members to 70—with plans to more than double in the next year. The way they operate is completely different from the traditional Japanese automotive culture. But just as the company embraced change brought by hybrid cars in the past decade, Koizumi says, they’re doing it again now, as technology companies have moved into the connected car space. "Another disruptive innovation is coming," he says, "so to survive in this situation, we need to change our culture." +

+

+Looking ahead, Koizumi and his team are expecting serverless and zero-trust security architecture to be important enhancements of Kubernetes. They are glad DENSO has come along for the ride. "Mobility service businesses require agility and flexibility," he says. "DENSO is trying to bring cloud native flexibility into the vehicle infrastructure." +

+
+
+ diff --git a/content/en/case-studies/ebay/ebay_featured.png b/content/en/case-studies/ebay/ebay_featured.png deleted file mode 100644 index 4ad17a4af5..0000000000 Binary files a/content/en/case-studies/ebay/ebay_featured.png and /dev/null differ diff --git a/content/en/case-studies/ebay/ebay_featured.svg b/content/en/case-studies/ebay/ebay_featured.svg deleted file mode 100644 index 18ffbdd040..0000000000 --- a/content/en/case-studies/ebay/ebay_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/ebay/ebay_logo.png b/content/en/case-studies/ebay/ebay_logo.png deleted file mode 100644 index 830913c52b..0000000000 Binary files a/content/en/case-studies/ebay/ebay_logo.png and /dev/null differ diff --git a/content/en/case-studies/ebay/index.html b/content/en/case-studies/ebay/index.html deleted file mode 100644 index e0bf4f6e97..0000000000 --- a/content/en/case-studies/ebay/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Ebay -content_url: http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/ ---- \ No newline at end of file diff --git a/content/en/case-studies/goldman-sachs/gs_featured.svg b/content/en/case-studies/goldman-sachs/gs_featured.svg deleted file mode 100644 index be3ed65a78..0000000000 --- a/content/en/case-studies/goldman-sachs/gs_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/goldman-sachs/gs_logo.png b/content/en/case-studies/goldman-sachs/gs_logo.png deleted file mode 100644 index 5cc8c14566..0000000000 Binary files a/content/en/case-studies/goldman-sachs/gs_logo.png and /dev/null differ diff --git a/content/en/case-studies/goldman-sachs/index.html b/content/en/case-studies/goldman-sachs/index.html deleted file mode 100644 index 93d3022d12..0000000000 --- a/content/en/case-studies/goldman-sachs/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Goldman Sachs -content_url: http://blogs.wsj.com/cio/2016/02/24/big-changes-in-goldmans-software-emerge-from-small-containers/ ---- \ No newline at end of file diff --git a/content/en/case-studies/homeoffice/homeoffice_featured.svg b/content/en/case-studies/homeoffice/homeoffice_featured.svg deleted file mode 100644 index 88293794e8..0000000000 --- a/content/en/case-studies/homeoffice/homeoffice_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/homeoffice/homeoffice_logo.png b/content/en/case-studies/homeoffice/homeoffice_logo.png deleted file mode 100644 index 35d9722611..0000000000 Binary files a/content/en/case-studies/homeoffice/homeoffice_logo.png and /dev/null differ diff --git a/content/en/case-studies/homeoffice/index.html b/content/en/case-studies/homeoffice/index.html deleted file mode 100644 index 589c7507d4..0000000000 --- a/content/en/case-studies/homeoffice/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Home Office UK -content_url: https://www.youtube.com/watch?v=F3iMkz_NSvU ---- diff --git a/content/en/case-studies/jd/index.html b/content/en/case-studies/jd/index.html deleted file mode 100644 index ee61da9d14..0000000000 --- a/content/en/case-studies/jd/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: JD.COM -content_url: https://kubernetes.io/blog/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack ---- \ No newline at end of file diff --git a/content/en/case-studies/jd/jd.com_featured_logo.svg b/content/en/case-studies/jd/jd.com_featured_logo.svg deleted file mode 100644 index d13de0240a..0000000000 --- a/content/en/case-studies/jd/jd.com_featured_logo.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/jd/jd_logo.png b/content/en/case-studies/jd/jd_logo.png deleted file mode 100644 index 58ef32a322..0000000000 Binary files a/content/en/case-studies/jd/jd_logo.png and /dev/null differ diff --git a/content/en/case-studies/liveperson/index.html b/content/en/case-studies/liveperson/index.html deleted file mode 100644 index 0cadb0f274..0000000000 --- a/content/en/case-studies/liveperson/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: LivePerson -content_url: https://www.openstack.org/videos/video/running-kubernetes-on-openstack-at-liveperson ---- \ No newline at end of file diff --git a/content/en/case-studies/liveperson/liveperson_featured.svg b/content/en/case-studies/liveperson/liveperson_featured.svg deleted file mode 100644 index b7e9b72b1e..0000000000 --- a/content/en/case-studies/liveperson/liveperson_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos-ancestry \ No newline at end of file diff --git a/content/en/case-studies/liveperson/liveperson_logo.png b/content/en/case-studies/liveperson/liveperson_logo.png deleted file mode 100644 index b7e63d94f7..0000000000 Binary files a/content/en/case-studies/liveperson/liveperson_logo.png and /dev/null differ diff --git a/content/en/case-studies/monzo/index.html b/content/en/case-studies/monzo/index.html deleted file mode 100644 index 99d4f35934..0000000000 --- a/content/en/case-studies/monzo/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Monzo -content_url: https://youtu.be/YkOY7DgXKyw ---- \ No newline at end of file diff --git a/content/en/case-studies/monzo/monzo_featured.svg b/content/en/case-studies/monzo/monzo_featured.svg deleted file mode 100644 index f4c8ee6bee..0000000000 --- a/content/en/case-studies/monzo/monzo_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/monzo/monzo_logo.png b/content/en/case-studies/monzo/monzo_logo.png deleted file mode 100644 index 854409d17e..0000000000 Binary files a/content/en/case-studies/monzo/monzo_logo.png and /dev/null differ diff --git a/content/en/case-studies/nav/index.html b/content/en/case-studies/nav/index.html index 5ec525a047..d4cc89590d 100644 --- a/content/en/case-studies/nav/index.html +++ b/content/en/case-studies/nav/index.html @@ -5,11 +5,7 @@ linkTitle: Nav case_study_styles: true cid: caseStudies css: /css/style_case_studies.css -logo: nav_featured_logo.png -featured: true -weight: 3 -quote: > - The community is absolutely vital: being able to pass ideas around, talk about a lot of the similar challenges that we’re all facing, and just get help. I like that we’re able to tackle the same problems for different reasons but help each other along the way. +featured: false ---
diff --git a/content/en/case-studies/philips/index.html b/content/en/case-studies/philips/index.html deleted file mode 100644 index e45d41a776..0000000000 --- a/content/en/case-studies/philips/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Philips -content_url: https://cloud.google.com/customers/philips/ ---- \ No newline at end of file diff --git a/content/en/case-studies/philips/philips_logo.png b/content/en/case-studies/philips/philips_logo.png deleted file mode 100644 index 9ba3421a61..0000000000 Binary files a/content/en/case-studies/philips/philips_logo.png and /dev/null differ diff --git a/content/en/case-studies/philips/philips_logo.svg b/content/en/case-studies/philips/philips_logo.svg deleted file mode 100644 index 3a59825b21..0000000000 --- a/content/en/case-studies/philips/philips_logo.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/pokemon-go/index.html b/content/en/case-studies/pokemon-go/index.html deleted file mode 100644 index ed4e168019..0000000000 --- a/content/en/case-studies/pokemon-go/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Pokemon GO -content_url: https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-to-life-on-Google-Cloud.html ---- \ No newline at end of file diff --git a/content/en/case-studies/pokemon-go/pokemon_go_featured.svg b/content/en/case-studies/pokemon-go/pokemon_go_featured.svg deleted file mode 100644 index dc5fef2b56..0000000000 --- a/content/en/case-studies/pokemon-go/pokemon_go_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/pokemon-go/pokemon_go_logo.png b/content/en/case-studies/pokemon-go/pokemon_go_logo.png deleted file mode 100644 index 3cf2b5c7ef..0000000000 Binary files a/content/en/case-studies/pokemon-go/pokemon_go_logo.png and /dev/null differ diff --git a/content/en/case-studies/samsung-sds/index.html b/content/en/case-studies/samsung-sds/index.html deleted file mode 100644 index db4aa479ab..0000000000 --- a/content/en/case-studies/samsung-sds/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Samsung SDS -content_url: http://www.nextplatform.com/2016/05/24/samsung-experts-put-kubernetes-paces/ ---- \ No newline at end of file diff --git a/content/en/case-studies/samsung-sds/sds_featured.svg b/content/en/case-studies/samsung-sds/sds_featured.svg deleted file mode 100644 index 87bf7ab647..0000000000 --- a/content/en/case-studies/samsung-sds/sds_featured.svg +++ /dev/null @@ -1 +0,0 @@ -Samsung SDS (member) logo \ No newline at end of file diff --git a/content/en/case-studies/samsung-sds/sds_logo.png b/content/en/case-studies/samsung-sds/sds_logo.png deleted file mode 100644 index 0a172df65d..0000000000 Binary files a/content/en/case-studies/samsung-sds/sds_logo.png and /dev/null differ diff --git a/content/en/case-studies/sap/index.html b/content/en/case-studies/sap/index.html deleted file mode 100644 index 856dc8be9d..0000000000 --- a/content/en/case-studies/sap/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: SAP -content_url: https://youtu.be/4gyeixJLabo ---- \ No newline at end of file diff --git a/content/en/case-studies/sap/sap_featured.svg b/content/en/case-studies/sap/sap_featured.svg deleted file mode 100644 index d7cc45f617..0000000000 --- a/content/en/case-studies/sap/sap_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/sap/sap_logo.png b/content/en/case-studies/sap/sap_logo.png deleted file mode 100644 index 681a3fe5cf..0000000000 Binary files a/content/en/case-studies/sap/sap_logo.png and /dev/null differ diff --git a/content/en/case-studies/sap/sap_small.png b/content/en/case-studies/sap/sap_small.png deleted file mode 100644 index ada89de759..0000000000 Binary files a/content/en/case-studies/sap/sap_small.png and /dev/null differ diff --git a/content/en/case-studies/soundcloud/index.html b/content/en/case-studies/soundcloud/index.html deleted file mode 100644 index 50611ffd85..0000000000 --- a/content/en/case-studies/soundcloud/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Soundcloud -content_url: https://www.youtube.com/watch?v=5378N5iLb2Q ---- \ No newline at end of file diff --git a/content/en/case-studies/soundcloud/soundcloud_featured.svg b/content/en/case-studies/soundcloud/soundcloud_featured.svg deleted file mode 100644 index 06e6da66d5..0000000000 --- a/content/en/case-studies/soundcloud/soundcloud_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/soundcloud/soundcloud_logo.png b/content/en/case-studies/soundcloud/soundcloud_logo.png deleted file mode 100644 index f8c12f05b5..0000000000 Binary files a/content/en/case-studies/soundcloud/soundcloud_logo.png and /dev/null differ diff --git a/content/en/case-studies/spotify/index.html b/content/en/case-studies/spotify/index.html index 67f2c848ee..85e7fc1e86 100644 --- a/content/en/case-studies/spotify/index.html +++ b/content/en/case-studies/spotify/index.html @@ -4,11 +4,7 @@ linkTitle: Spotify case_study_styles: true cid: caseStudies css: /css/style_case_studies.css -logo: spotify_featured_logo.png -featured: true -weight: 2 -quote: > - We saw the amazing community that’s grown up around Kubernetes, and we wanted to be part of that. We wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools. +featured: false ---
diff --git a/content/en/case-studies/wepay/index.html b/content/en/case-studies/wepay/index.html deleted file mode 100644 index b8ce8201d5..0000000000 --- a/content/en/case-studies/wepay/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: WePay -content_url: http://thenewstack.io/wepay-kubernetes-changed-business/ ---- \ No newline at end of file diff --git a/content/en/case-studies/wepay/wepay_featured.svg b/content/en/case-studies/wepay/wepay_featured.svg deleted file mode 100644 index 102b40e212..0000000000 --- a/content/en/case-studies/wepay/wepay_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/wepay/wepay_logo.png b/content/en/case-studies/wepay/wepay_logo.png deleted file mode 100644 index 4e35dd8fd6..0000000000 Binary files a/content/en/case-studies/wepay/wepay_logo.png and /dev/null differ diff --git a/content/en/case-studies/zulily/index.html b/content/en/case-studies/zulily/index.html deleted file mode 100644 index a9e480ea97..0000000000 --- a/content/en/case-studies/zulily/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Zulily -content_url: https://www.youtube.com/embed/of45hYbkIZs ---- \ No newline at end of file diff --git a/content/en/case-studies/zulily/zulily_featured.png b/content/en/case-studies/zulily/zulily_featured.png deleted file mode 100644 index 81179f36d2..0000000000 Binary files a/content/en/case-studies/zulily/zulily_featured.png and /dev/null differ diff --git a/content/en/case-studies/zulily/zulily_featured.svg b/content/en/case-studies/zulily/zulily_featured.svg deleted file mode 100644 index b2c6ce5da4..0000000000 --- a/content/en/case-studies/zulily/zulily_featured.svg +++ /dev/null @@ -1 +0,0 @@ -kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/zulily/zulily_logo.png b/content/en/case-studies/zulily/zulily_logo.png deleted file mode 100644 index e144c7897b..0000000000 Binary files a/content/en/case-studies/zulily/zulily_logo.png and /dev/null differ diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 6e62881451..62bb4da2f4 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -9,32 +9,132 @@ weight: 10 {{% capture overview %}} -A node is a worker machine in Kubernetes, previously known as a `minion`. A node -may be a VM or physical machine, depending on the cluster. Each node contains -the services necessary to run [pods](/docs/concepts/workloads/pods/pod/) and is managed by the master -components. The services on a node include the [container runtime](/docs/concepts/overview/components/#container-runtime), kubelet and kube-proxy. See -[The Kubernetes Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) section in the -architecture design doc for more details. +Kubernetes runs your workload by placing containers into Pods to run on _Nodes_. +A node may be a virtual or physical machine, depending on the cluster. Each node +contains the services necessary to run +{{< glossary_tooltip text="Pods" term_id="pod" >}}, managed by the +{{< glossary_tooltip text="control plane" term_id="control-plane" >}}. + +Typically you have several nodes in a cluster; in a learning or resource-limited +environment, you might have just one. + +The [components](/docs/concepts/overview/components/#node-components) on a node include the +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, a +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}, and the +{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}. {{% /capture %}} - {{% capture body %}} -## Node Status +## Management -A node's status contains the following information: +There are two main ways to have Nodes added to the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}: + +1. The kubelet on a node self-registers to the control plane +2. You, or another human user, manually add a Node object + +After you create a Node object, or the kubelet on a node self-registers, the +control plane checks whether the new Node object is valid. For example, if you +try to create a Node from the following JSON manifest: + +```json +{ + "kind": "Node", + "apiVersion": "v1", + "metadata": { + "name": "10.240.79.157", + "labels": { + "name": "my-first-k8s-node" + } + } +} +``` + +Kubernetes creates a Node object internally (the representation). Kubernetes checks +that a kubelet has registered to the API server that matches the `metadata.name` +field of the Node. If the node is healthy (if all necessary services are running), +it is eligible to run a Pod. Otherwise, that node is ignored for any cluster activity +until it becomes healthy. + +{{< note >}} +Kubernetes keeps the object for the invalid Node and continues checking to see whether +it becomes healthy. + +You, or a {{< glossary_tooltip term_id="controller" text="controller">}}, must explicitly +delete the Node object to stop that health checking. +{{< /note >}} + +The name of a Node object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +### Self-registration of Nodes + +When the kubelet flag `--register-node` is true (the default), the kubelet will attempt to +register itself with the API server. This is the preferred pattern, used by most distros. + +For self-registration, the kubelet is started with the following options: + + - `--kubeconfig` - Path to credentials to authenticate itself to the API server. + - `--cloud-provider` - How to talk to a {{< glossary_tooltip text="cloud provider" term_id="cloud-provider" >}} to read metadata about itself. + - `--register-node` - Automatically register with the API server. + - `--register-with-taints` - Register the node with the given list of {{< glossary_tooltip text="taints" term_id="taint" >}} (comma separated `=:`). + + No-op if `register-node` is false. + - `--node-ip` - IP address of the node. + - `--node-labels` - {{< glossary_tooltip text="Labels" term_id="label" >}} to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)). + - `--node-status-update-frequency` - Specifies how often kubelet posts node status to master. + +When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and +[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled, +kubelets are only authorized to create/modify their own Node resource. + +### Manual Node administration + +You can create and modify Node objects using +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}. + +When you want to create Node objects manually, set the kubelet flag `--register-node=false`. + +You can modify Node objects regardless of the setting of `--register-node`. +For example, you can set labels on an existing Node, or mark it unschedulable. + +You can use labels on Nodes in conjunction with node selectors on Pods to control +scheduling. For example, you can to constrain a Pod to only be eligible to run on +a subset of the available nodes. + +Marking a node as unschedulable prevents the scheduler from placing new pods onto +that Node, but does not affect existing Pods on the Node. This is useful as a +preparatory step before a node reboot or other maintenance. + +To mark a Node unschedulable, run: + +```shell +kubectl cordon $NODENAME +``` + +{{< 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 +that should run on the Node even if it is being drained of workload applications. +{{< /note >}} + +## Node status + +A Node's status contains the following information: * [Addresses](#addresses) * [Conditions](#condition) * [Capacity and Allocatable](#capacity) * [Info](#info) -Node status and other details about a node can be displayed using the following command: +You can use `kubectl` to view a Node's status and other details: + ```shell kubectl describe node ``` -Each section is described in detail below. + +Each section of the output is described below. ### Addresses @@ -49,15 +149,23 @@ The usage of these fields varies depending on your cloud provider or bare metal The `conditions` field describes the status of all `Running` nodes. Examples of conditions include: -| 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) | -| `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` | -| `DiskPressure` | `True` if pressure exists on the disk size -- that is, if the disk capacity is low; otherwise `False` | -| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` | +{{< table caption = "Node conditions, and a description of when each condition applies." >}} +| 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` | +| `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 >}} -The node condition is represented as a JSON object. For example, the following response describes a healthy node. +{{< note >}} +If you use command-line tools to print details of a cordoned Node, the Condition includes +`SchedulingDisabled`. `SchedulingDisabled` is not a Condition in the Kubernetes API; instead, +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: ```json "conditions": [ @@ -72,20 +180,24 @@ The node condition is represented as a JSON object. For example, the following r ] ``` -If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the [kube-controller-manager](/docs/admin/kube-controller-manager/)), 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 apiserver 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 apiserver 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" >}}), 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. -In versions of Kubernetes prior to 1.5, the node controller would [force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) -these unreachable pods from the apiserver. However, in 1.5 and higher, 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 being in -the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the underlying infrastructure if a node has -permanently left a cluster, the cluster administrator may need to delete the node object by hand. Deleting the node object from -Kubernetes causes all the Pod objects running on the node to be deleted from the apiserver, and frees up their names. +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 +being in the `Terminating` or `Unknown` state. In cases where Kubernetes cannot deduce from the +underlying infrastructure if a node has permanently left a cluster, the cluster administrator +may need to delete the node object by hand. Deleting the node object from Kubernetes causes +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/configuration/taint-and-toleration/) that represent conditions. +[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that represent conditions. 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. +See [Taint Nodes by Condition](/docs/concepts/configuration/taint-and-toleration/#taint-nodes-by-condition) +for more details. + ### Capacity and Allocatable {#capacity} Describes the resources available on the node: CPU, memory and the maximum @@ -104,48 +216,10 @@ on a Node. 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. -## Management +### Node controller -Unlike [pods](/docs/concepts/workloads/pods/pod/) and [services](/docs/concepts/services-networking/service/), -a node is not inherently created by Kubernetes: it is created externally by cloud -providers like Google Compute Engine, or it exists in your pool of physical or virtual -machines. So when Kubernetes creates a node, it creates -an object that represents the node. After creation, Kubernetes -checks whether the node is valid or not. For example, if you try to create -a node from the following content: - -```json -{ - "kind": "Node", - "apiVersion": "v1", - "metadata": { - "name": "10.240.79.157", - "labels": { - "name": "my-first-k8s-node" - } - } -} -``` - -Kubernetes creates a node object internally (the representation), and -validates the node by health checking based on the `metadata.name` field. If the node is valid -- that is, if all necessary -services are running -- it is eligible to run a pod. Otherwise, it is -ignored for any cluster activity until it becomes valid. -The name of a Node object must be a valid -[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). - -{{< note >}} -Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid. -You must explicitly delete the Node object to stop this process. -{{< /note >}} - -Currently, there are three components that interact with the Kubernetes node -interface: node controller, kubelet, and kubectl. - -### Node Controller - -The node controller is a Kubernetes master component which manages various -aspects of nodes. +The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a +Kubernetes control plane component that manages various aspects of nodes. The node controller has multiple roles in a node's life. The first is assigning a CIDR block to the node when it is registered (if CIDR assignment is turned on). @@ -168,6 +242,7 @@ 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/{{< latest-version >}}/#lease-v1-coordination-k8s-io). Each Node has an associated Lease object in the `kube-node-lease` @@ -188,13 +263,7 @@ a Lease object. #### Reliability -In Kubernetes 1.4, we updated the logic of the node controller to better handle -cases when a large number of nodes have problems with reaching the master -(e.g. because the master has networking problems). Starting with 1.4, the node -controller looks at the state of all nodes in the cluster when making a -decision about pod eviction. - -In most cases, node controller limits the eviction rate to + In most cases, node controller limits the eviction rate to `--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods from more than 1 node per 10 seconds. @@ -220,62 +289,12 @@ completely unhealthy (i.e. there are no healthy nodes in the cluster). In such a case, the node controller assumes that there's some problem with master connectivity and stops all evictions until some connectivity is restored. -Starting in Kubernetes 1.6, the NodeController is also responsible for evicting -pods that are running on nodes with `NoExecute` taints, when the pods do not tolerate -the taints. Additionally, as an alpha feature that is disabled by default, the -NodeController is responsible for adding taints corresponding to node problems like -node unreachable or not ready. See [this documentation](/docs/concepts/configuration/taint-and-toleration/) -for details about `NoExecute` taints and the alpha feature. +The node controller is also responsible for evicting pods running on nodes with +`NoExecute` taints, unless those pods tolerate that taint. +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. -Starting in version 1.8, the node controller can be made responsible for creating taints that represent -Node conditions. This is an alpha feature of version 1.8. - -### Self-Registration of Nodes - -When the kubelet flag `--register-node` is true (the default), the kubelet will attempt to -register itself with the API server. This is the preferred pattern, used by most distros. - -For self-registration, the kubelet is started with the following options: - - - `--kubeconfig` - Path to credentials to authenticate itself to the apiserver. - - `--cloud-provider` - How to talk to a cloud provider to read metadata about itself. - - `--register-node` - Automatically register with the API server. - - `--register-with-taints` - Register the node with the given list of taints (comma separated `=:`). No-op if `register-node` is false. - - `--node-ip` - IP address of the node. - - `--node-labels` - Labels to add when registering the node in the cluster (see label restrictions enforced by the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) in 1.13+). - - `--node-status-update-frequency` - Specifies how often kubelet posts node status to master. - -When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and -[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) are enabled, -kubelets are only authorized to create/modify their own Node resource. - -#### Manual Node Administration - -A cluster administrator can create and modify node objects. - -If the administrator wishes to create node objects manually, set the kubelet flag -`--register-node=false`. - -The administrator can modify node resources (regardless of the setting of `--register-node`). -Modifications include setting labels on the node and marking it unschedulable. - -Labels on nodes can be used in conjunction with node selectors on pods to control scheduling, -e.g. to constrain a pod to only be eligible to run on a subset of the nodes. - -Marking a node as unschedulable prevents new pods from being scheduled to that -node, but does not affect any existing pods on the node. This is useful as a -preparatory step before a node reboot, etc. For example, to mark a node -unschedulable, run this command: - -```shell -kubectl cordon $NODENAME -``` - -{{< note >}} -Pods created by a DaemonSet controller bypass the Kubernetes scheduler -and do not respect the unschedulable attribute on a node. This assumes that daemons belong on -the machine even if it is being drained of applications while it prepares for a reboot. -{{< /note >}} {{< caution >}} `kubectl cordon` marks a node as 'unschedulable', which has the side effect of the service @@ -285,34 +304,40 @@ eligible for, effectively removing incoming load balancer traffic from the cordo ### Node capacity -The capacity of the node (number of cpus and amount of memory) is part of the node object. -Normally, nodes register themselves and report their capacity when creating the node object. If -you are doing [manual node administration](#manual-node-administration), then you need to set node -capacity when adding a node. +Node objects track information about the Node's resource capacity (for example: the amount +of memory available, and the number of CPUs). +Nodes that [self register](#self-registration-of-nodes) report their capacity during +registration. If you [manually](#manual-node-administration) add a Node, then +you need to set the node's capacity informaton when you add it. -The Kubernetes scheduler ensures that there are enough resources for all the pods on a node. It -checks that the sum of the requests of containers on the node is no greater than the node capacity. It -includes all containers started by the kubelet, but not containers started directly by the [container runtime](/docs/concepts/overview/components/#container-runtime) nor any process running outside of the containers. +The Kubernetes {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} ensures that +there are enough resources for all the Pods on a Node. The scheduler checks that the sum +of the requests of containers on the node is no greater than the node's capacity. +That sum of requests includes all containers managed by the kubelet, but excludes any +containers started directly by the container runtime, and also excludes any +processes running outside of the kubelet's control. -If you want to explicitly reserve resources for non-Pod processes, follow this tutorial to +{{< note >}} +If you want to explicitly reserve resources for non-Pod processes, see [reserve resources for system daemons](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). +{{< /note >}} ## Node topology -{{< feature-state state="alpha" >}} +{{< feature-state state="alpha" for_k8s_version="v1.16" >}} If you have enabled the `TopologyManager` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then the kubelet can use topology hints when making resource assignment decisions. - -## API Object - -Node is a top-level resource in the Kubernetes REST API. More details about the -API object can be found at: -[Node API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). +See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/) +for more information. {{% /capture %}} {{% capture whatsnext %}} -* Read about [node components](/docs/concepts/overview/components/#node-components) -* Read about node-level topology: [Control Topology Management Policies on a node](/docs/tasks/administer-cluster/topology-manager/) +* Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node. +* Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). +* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) + section of the architecture design document. +* Read about [taints and tolerations](/docs/concepts/configuration/taint-and-toleration/). +* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling). {{% /capture %}} diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md index c7f3dd8909..0347327f13 100644 --- a/content/en/docs/concepts/cluster-administration/addons.md +++ b/content/en/docs/concepts/cluster-administration/addons.md @@ -30,6 +30,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) 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. +* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring. * [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). diff --git a/content/en/docs/concepts/cluster-administration/cloud-providers.md b/content/en/docs/concepts/cluster-administration/cloud-providers.md index 8d62d1b196..0d9ba6c1ff 100644 --- a/content/en/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/en/docs/concepts/cluster-administration/cloud-providers.md @@ -395,7 +395,7 @@ For in-depth documentation on the vSphere cloud provider, visit the [vSphere clo ## IBM Cloud Kubernetes Service ### Compute nodes -By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters). +By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes). The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance. @@ -422,3 +422,15 @@ If you wish to use the external cloud provider, its repository is [TencentCloud/ The Tencent cloud provider uses the hostname of the node (as determined by the kubelet or overridden with `--hostname-override`) as the name of the Kubernetes Node object. Note that the Kubernetes Node name must match the Tencent VM private IP. + +## Alibaba Cloud Kubernetes + + If you wish to use the external cloud provider, its repository is [kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud). + +### Node Name + +Alibaba Cloud does not require the format of node name, but the kubelet needs to add `--provider-id=${REGION_ID}.${INSTANCE_ID}`. The parameter `${REGION_ID}` represents the region id of the Kubernetes and `${INSTANCE_ID}` denotes the Alibaba ECS (Elastic Compute Service) ID. + +### Load Balancers + +You can setup external load balancers to use specific features in Alibaba Cloud by configuring the [annotations](https://www.alibabacloud.com/help/en/doc-detail/86531.htm) . \ No newline at end of file diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 6540a05e8f..f9ccdca8e9 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -131,14 +131,14 @@ classes: namespace). These are important to isolate from other traffic because failures in leader election cause their controllers to fail and restart, which in turn causes more expensive traffic as the new controllers sync their informers. - + * The `workload-high` priority level is for other requests from built-in controllers. - + * The `workload-low` priority level is for requests from any other service account, which will typically include all requests from controllers runing in Pods. - + * The `global-default` priority level handles all other traffic, e.g. interactive `kubectl` commands run by nonprivileged users. @@ -150,7 +150,7 @@ are built in and may not be overwritten: special `exempt` FlowSchema classifies all requests from the `system:masters` group into this priority level. You may define other FlowSchemas that direct other requests to this priority level, if appropriate. - + * The special `catch-all` priority level is used in combination with the special `catch-all` FlowSchema to make sure that every request gets some kind of classification. Typically you should not rely on this catch-all configuration, @@ -164,7 +164,7 @@ are built in and may not be overwritten: ## Resources The flow control API involves two kinds of resources. -[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) +[PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1alpha1-flowcontrol-apiserver-k8s-io) define the available isolation classes, the share of the available concurrency budget that each can handle, and allow for fine-tuning queuing behavior. [FlowSchemas](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#flowschema-v1alpha1-flowcontrol-apiserver-k8s-io) @@ -204,7 +204,7 @@ 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](#what-s-next), but in short: +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 @@ -233,20 +233,21 @@ given mouse (low-intensity flow) is squished by the elephants (high-intensity fl an illustrative collection of numbers of elephants. See https://play.golang.org/p/Gi0PLgVHiUg , which computes this table. -{{< table caption="Example Shuffle Sharding Configurations" >}} -|HandSize| Queues| 1 elephant| 4 elephants| 16 elephants| -|--------|-----------|------------|----------------|--------------------| -| 12| 32| 4.428838398950118e-09| 0.11431348830099144| 0.9935089607656024| -| 10| 32| 1.550093439632541e-08| 0.0626479840223545| 0.9753101519027554| -| 10| 64| 6.601827268370426e-12| 0.00045571320990370776| 0.49999929150089345| -| 9| 64| 3.6310049976037345e-11| 0.00045501212304112273| 0.4282314876454858| -| 8| 64| 2.25929199850899e-10| 0.0004886697053040446| 0.35935114681123076| -| 8| 128| 6.994461389026097e-13| 3.4055790161620863e-06| 0.02746173137155063| -| 7| 128| 1.0579122850901972e-11| 6.960839379258192e-06| 0.02406157386340147| -| 7| 256| 7.597695465552631e-14| 6.728547142019406e-08| 0.0006709661542533682| -| 6| 256| 2.7134626662687968e-12| 2.9516464018476436e-07| 0.0008895654642000348| -| 6| 512| 4.116062922897309e-14| 4.982983350480894e-09| 2.26025764343413e-05| -| 6| 1024| 6.337324016514285e-16| 8.09060164312957e-11| 4.517408062903668e-07| +{{< table caption = "Example Shuffle Sharding Configurations" >}} +HandSize | Queues | 1 elephant | 4 elephants | 16 elephants +|----------|-----------|------------|----------------|--------------------| +| 12 | 32 | 4.428838398950118e-09 | 0.11431348830099144 | 0.9935089607656024 | +| 10 | 32 | 1.550093439632541e-08 | 0.0626479840223545 | 0.9753101519027554 | +| 10 | 64 | 6.601827268370426e-12 | 0.00045571320990370776 | 0.49999929150089345 | +| 9 | 64 | 3.6310049976037345e-11 | 0.00045501212304112273 | 0.4282314876454858 | +| 8 | 64 | 2.25929199850899e-10 | 0.0004886697053040446 | 0.35935114681123076 | +| 8 | 128 | 6.994461389026097e-13 | 3.4055790161620863e-06 | 0.02746173137155063 | +| 7 | 128 | 1.0579122850901972e-11 | 6.960839379258192e-06 | 0.02406157386340147 | +| 7 | 256 | 7.597695465552631e-14 | 6.728547142019406e-08 | 0.0006709661542533682 | +| 6 | 256 | 2.7134626662687968e-12 | 2.9516464018476436e-07 | 0.0008895654642000348 | +| 6 | 512 | 4.116062922897309e-14 | 4.982983350480894e-09 | 2.26025764343413e-05 | +| 6 | 1024 | 6.337324016514285e-16 | 8.09060164312957e-11 | 4.517408062903668e-07 | +{{< /table >}} ### FlowSchema @@ -291,7 +292,7 @@ enabled has two extra headers: `X-Kubernetes-PF-FlowSchema-UID` and `X-Kubernetes-PF-PriorityLevel-UID`, noting the flow schema that matched the request and the priority level to which it was assigned, respectively. The API objects' names are not included in these headers in case the requesting user does not -have permission to view them, so when debugging you can use a command like +have permission to view them, so when debugging you can use a command like ```shell kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}" @@ -363,7 +364,7 @@ poorly-behaved workloads that may be harming system health. * `apiserver_flowcontrol_request_execution_seconds` gives a histogram of how long requests took to actually execute, grouped by the FlowSchema that matched the request and the PriorityLevel to which it was assigned. - + {{% /capture %}} @@ -374,4 +375,4 @@ the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/maste You can make suggestions and feature requests via [SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery). -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index f70e6f7a42..c260963d87 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -262,6 +262,10 @@ Lars Kellogg-Stedman. 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. +### OVN4NFV-K8s-Plugin (OVN based CNI controller & plugin) + +[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking + ### NSX-T [VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) is a network virtualization and security platform. NSX-T can provide network virtualization for a multi-cloud and multi-hypervisor environment and is focused on emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere hypervisors, these environments include other hypervisors such as KVM, containers, and bare metal. diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md index 100d04ae78..d07bf762bb 100644 --- a/content/en/docs/concepts/configuration/overview.md +++ b/content/en/docs/concepts/configuration/overview.md @@ -59,8 +59,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN - Avoid using `hostNetwork`, for the same reasons as `hostPort`. -- Use [headless Services](/docs/concepts/services-networking/service/#headless- -services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing. +- Use [headless Services](/docs/concepts/services-networking/service/#headless-services) (which have a `ClusterIP` of `None`) for easy service discovery when you don't need `kube-proxy` load balancing. ## Using Labels diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index d63a2cf3ac..0fa5b13efa 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -81,6 +81,12 @@ The output is similar to: secret "db-user-pass" created ``` +Default key name is the filename. You may optionally set the key name using `[--from-file=[key=]source]`. + +```shell +kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt +``` + {{< note >}} 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 (`'`). diff --git a/content/en/docs/concepts/containers/overview.md b/content/en/docs/concepts/containers/overview.md index 968ba7104a..49162710d7 100644 --- a/content/en/docs/concepts/containers/overview.md +++ b/content/en/docs/concepts/containers/overview.md @@ -9,9 +9,9 @@ weight: 1 {{% capture overview %}} -Containers are a technnology for packaging the (compiled) code for an +Containers are a technology for packaging the (compiled) code for an application along with the dependencies it needs at run time. Each -container that you run is repeatable; the standardisation from having +container that you run is repeatable; the standardization from having dependencies included means that you get the same behavior wherever you run it. diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index d29825d698..dca6f2d0a8 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -163,7 +163,7 @@ with the pod's tolerations in admission, effectively taking the union of the set by each. To learn more about configuring the node selector and tolerations, see [Assigning Pods to -Nodes](/docs/concepts/configuration/assign-pod-node/). +Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/). [RuntimeClass admission controller]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md index f77d83a553..eb56d5475a 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -106,7 +106,7 @@ as well as keeping the existing service in good shape. ## Writing your own Operator {#writing-operator} If there isn't an Operator in the ecosystem that implements the behavior you -want, you can code your own. In [What's next](#what-s-next) you'll find a few +want, you can code your own. In [What's next](#whats-next) you'll find a few links to libraries and tools you can use to write your own cloud native Operator. @@ -129,4 +129,4 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie * Read [CoreOS' original article](https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern * Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index 71b95fc787..04c4bbe805 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -86,7 +86,7 @@ Node components run on every node, maintaining running pods and providing the Ku {{< glossary_definition term_id="kube-proxy" length="all" >}} -### Container Runtime +### Container runtime {{< glossary_definition term_id="container-runtime" length="all" >}} 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 0de7f04a8c..f08daf323b 100644 --- a/content/en/docs/concepts/overview/working-with-objects/labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/labels.md @@ -226,6 +226,6 @@ selector: #### Selecting sets of nodes 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/configuration/assign-pod-node/) for more information. +See the documentation on [node selection](/docs/concepts/scheduling-eviction/assign-pod-node/) for more information. {{% /capture %}} diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index 8ae3111323..39f51bf2d7 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -494,7 +494,8 @@ kubectl create quota test --hard=count/deployments.extensions=2,count/replicaset ``` ```shell -kubectl run nginx --image=nginx --replicas=2 --namespace=myspace +kubectl create deployment nginx --image=nginx --namespace=myspace +kubectl scale deployment nginx --replicas=2 --namespace=myspace ``` ```shell diff --git a/content/en/docs/concepts/configuration/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md similarity index 97% rename from content/en/docs/concepts/configuration/assign-pod-node.md rename to content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index 3811f75301..79a9487c60 100644 --- a/content/en/docs/concepts/configuration/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -155,7 +155,7 @@ value is `another-node-label-value` should be preferred. You can see the operator `In` being used in the example. The new node affinity syntax supports the following operators: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, or use -[node taints](/docs/concepts/configuration/taint-and-toleration/) to repel pods from specific nodes. +[node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) to repel pods from specific nodes. If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the pod to be scheduled onto a candidate node. @@ -226,10 +226,11 @@ The legal operators for pod affinity and anti-affinity are `In`, `NotIn`, `Exist In principle, the `topologyKey` can be any legal label-key. However, for performance and security reasons, there are some constraints on topologyKey: -1. For affinity and for `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, -empty `topologyKey` is not allowed. -2. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or simply disable it. -3. For `preferredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, empty `topologyKey` is not allowed. +1. For pod affinity, empty `topologyKey` is not allowed in both `requiredDuringSchedulingIgnoredDuringExecution` +and `preferredDuringSchedulingIgnoredDuringExecution`. +2. For pod anti-affinity, empty `topologyKey` is also not allowed in both `requiredDuringSchedulingIgnoredDuringExecution` +and `preferredDuringSchedulingIgnoredDuringExecution`. +3. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or simply disable it. 4. Except for the above cases, the `topologyKey` can be any legal label-key. In addition to `labelSelector` and `topologyKey`, you can optionally specify a list `namespaces` @@ -391,7 +392,7 @@ The above pod will run on the node kube-01. {{% capture whatsnext %}} -[Taints](/docs/concepts/configuration/taint-and-toleration/) allow a Node to *repel* a set of Pods. +[Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods. The design documents for [node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md) diff --git a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md index c258a2d46a..2fea98bfb4 100644 --- a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -1,7 +1,7 @@ --- title: Kubernetes Scheduler content_template: templates/concept -weight: 50 +weight: 10 --- {{% capture overview %}} diff --git a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md index 0d4c633391..d1123b72e1 100644 --- a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -157,13 +157,13 @@ the three things: 1. **wait** (with a timeout) \ If a Permit plugin returns "wait", then the Pod is kept in an internal "waiting" Pods list, and the binding cycle of this Pod starts but directly blocks until it - gets [approved](#frameworkhandle). If a timeout occurs, **wait** becomes **deny** + gets approved. If a timeout occurs, **wait** becomes **deny** and the Pod is returned to the scheduling queue, triggering [Unreserve](#unreserve) plugins. {{< note >}} While any plugin can access the list of "waiting" Pods and approve them -(see [`FrameworkHandle`](#frameworkhandle)), we expect only the permit +(see [`FrameworkHandle`](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md#frameworkhandle)), we expect only the permit plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod is approved, it is sent to the [PreBind](#pre-bind) phase. {{< /note >}} @@ -239,4 +239,4 @@ If you are using Kubernetes v1.18 or later, you can configure a set of plugins a a scheduler profile and then define multiple profiles to fit various kinds of workload. Learn more at [multiple profiles](/docs/reference/scheduling/profiles/#multiple-profiles). -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/configuration/taint-and-toleration.md b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md similarity index 82% rename from content/en/docs/concepts/configuration/taint-and-toleration.md rename to content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md index f2a0befec8..0812b2ce05 100644 --- a/content/en/docs/concepts/configuration/taint-and-toleration.md +++ b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -10,16 +10,17 @@ weight: 40 {{% capture overview %}} -Node affinity, described [here](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), -is a property of *pods* that *attracts* them to a set of nodes (either as a -preference or a hard requirement). Taints are the opposite -- they allow a -*node* to *repel* a set of pods. +[_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. + +_Tolerations_ are applied to pods, and allow (but do not require) the pods to schedule +onto nodes with matching taints. Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node; this marks that the node should not accept any pods that do not tolerate the taints. -Tolerations are applied to pods, and allow (but do not require) the pods to schedule -onto nodes with matching taints. {{% /capture %}} @@ -65,12 +66,12 @@ Here’s an example of a pod that uses tolerations: {{< codenew file="pods/pod-with-toleration.yaml" >}} +The default value for `operator` is `Equal`. + A toleration "matches" a taint if the keys are the same and the effects are the same, and: * the `operator` is `Exists` (in which case no `value` should be specified), or -* the `operator` is `Equal` and the `value`s are equal - -`Operator` defaults to `Equal` if not specified. +* the `operator` is `Equal` and the `value`s are equal. {{< note >}} @@ -204,7 +205,7 @@ when there are node problems, which is described in the next section. {{< feature-state for_k8s_version="v1.18" state="stable" >}} -Earlier we mentioned the `NoExecute` taint effect, which affects pods that are already +The `NoExecute` taint effect, mentioned above, affects pods that are already running on the node as follows * pods that do not tolerate the taint are evicted immediately @@ -213,9 +214,8 @@ running on the node as follows * pods that tolerate the taint with a specified `tolerationSeconds` remain bound for the specified amount of time -In addition, Kubernetes 1.6 introduced alpha support for representing node -problems. In other words, the node controller automatically taints a node when -certain condition is true. The following taints are built in: +The node controller automatically taints a Node when certain conditions +are true. The following taints are built in: * `node.kubernetes.io/not-ready`: Node is not ready. This corresponds to the NodeCondition `Ready` being "`False`". @@ -236,19 +236,18 @@ with `NoExecute` effect. If the fault condition returns to normal the kubelet or controller can remove the relevant taint(s). {{< note >}} -To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/) -behavior of pod evictions due to node problems, the system actually adds the taints -in a rate-limited way. This prevents massive pod evictions in scenarios such -as the master becoming partitioned from the nodes. +The control plane limits the rate of adding node new taints to nodes. This rate limiting +manages the number of evictions that are triggered when many nodes become unreachable at +once (for example: if there is a network disruption). {{< /note >}} -The feature, in combination with `tolerationSeconds`, allows a pod -to specify how long it should stay bound to a node that has one or both of these problems. +You can specify `tolerationSeconds` for a Pod to define how long that Pod stays bound +to a failing or unresponsive Node. -For example, an application with a lot of local state might want to stay -bound to node for a long time in the event of network partition, in the hope +For example, you might want to keep an application with a lot of local state +bound to node for a long time in the event of network partition, hoping that the partition will recover and thus the pod eviction can be avoided. -The toleration the pod would use in that case would look like +The toleration you set for that Pod might look like: ```yaml tolerations: @@ -258,20 +257,15 @@ tolerations: tolerationSeconds: 6000 ``` -Note that Kubernetes automatically adds a toleration for -`node.kubernetes.io/not-ready` with `tolerationSeconds=300` -unless the pod configuration provided -by the user already has a toleration for `node.kubernetes.io/not-ready`. -Likewise it adds a toleration for -`node.kubernetes.io/unreachable` with `tolerationSeconds=300` -unless the pod configuration provided -by the user already has a toleration for `node.kubernetes.io/unreachable`. +{{< note >}} +Kubernetes automatically adds a toleration for +`node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` +with `tolerationSeconds=300`, +unless you, or a controller, set those tolerations explictly. -These automatically-added tolerations ensure that -the default pod behavior of remaining bound for 5 minutes after one of these -problems is detected is maintained. -The two default tolerations are added by the [DefaultTolerationSeconds -admission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds). +These automatically-added tolerations mean that Pods remain bound to +Nodes for 5 minutes after one of these problems is detected. +{{< /note >}} [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) pods are created with `NoExecute` tolerations for the following taints with no `tolerationSeconds`: @@ -287,9 +281,8 @@ 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. -Starting in Kubernetes 1.8, the DaemonSet controller automatically adds the -following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from -breaking. +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` @@ -299,3 +292,10 @@ breaking. Adding these tolerations ensures backward compatibility. You can also add arbitrary tolerations to DaemonSets. + +{{% /capture %}} +{{% capture 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/) + +{{% /capture %}} diff --git a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index 6f931a8531..aeae348209 100644 --- a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -93,7 +93,7 @@ hostaliases-pod 0/1 Completed 0 6s 10.200 The `hosts` file content would look like this: ```shell -kubectl logs hostaliases-pod +kubectl exec hostaliases-pod -- cat /etc/hosts ``` ```none 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 ba77587457..b479d8c96a 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -171,7 +171,7 @@ following pod-specific DNS policies. These policies are specified in the - "`None`": It allows a Pod to ignore DNS settings from the Kubernetes environment. All DNS settings are supposed to be provided using the `dnsConfig` field in the Pod Spec. - See [Pod's DNS config](#pod-s-dns-config) subsection below. + See [Pod's DNS config](#pod-dns-config) subsection below. {{< note >}} "Default" is not the default DNS policy. If `dnsPolicy` is not @@ -201,7 +201,7 @@ spec: dnsPolicy: ClusterFirstWithHostNet ``` -### Pod's DNS Config +### Pod's DNS Config {#pod-dns-config} Pod's DNS Config allows users more control on the DNS settings for a Pod. @@ -269,6 +269,4 @@ The availability of Pod DNS Config and DNS Policy "`None`"" is shown as below. For guidance on administering DNS configurations, check [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/) -{{% /capture %}} - - +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index 81f45b5aed..c753c17cc1 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -40,27 +40,30 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack * Kubernetes 1.16 or later * 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) - * Kube-proxy running in mode IPVS ## Enable 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: + * kube-apiserver: + * `--feature-gates="IPv6DualStack=true"` * kube-controller-manager: * `--feature-gates="IPv6DualStack=true"` - * `--cluster-cidr=,` eg. `--cluster-cidr=10.244.0.0/16,fc00::/24` + * `--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: - * `--proxy-mode=ipvs` * `--cluster-cidr=,` * `--feature-gates="IPv6DualStack=true"` -{{< caution >}} -If you specify an IPv6 address block larger than a /24 via `--cluster-cidr` on the command line, that assignment will fail. -{{< /caution >}} +{{< 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)) + +{{< /note >}} ## Services diff --git a/content/en/docs/concepts/services-networking/endpoint-slices.md b/content/en/docs/concepts/services-networking/endpoint-slices.md index 7c39f05086..940374ae52 100644 --- a/content/en/docs/concepts/services-networking/endpoint-slices.md +++ b/content/en/docs/concepts/services-networking/endpoint-slices.md @@ -2,11 +2,6 @@ reviewers: - freehan title: EndpointSlices -feature: - title: EndpointSlices - description: > - Scalable tracking of network endpoints in a Kubernetes cluster. - content_template: templates/concept weight: 15 --- diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index 39e57ffdb0..062dc14f66 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -134,11 +134,10 @@ path types: to 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 >}} - If the last element of the path is a substring of the - last element in request path, it is not a match (for example: - `/foo/bar` matches`/foo/bar/baz`, but does not match `/foo/barbaz`). - {{< /note >}} + + {{< note >}} + If the last element of the path is a substring of the last element in request path, it is not a match (for example: `/foo/bar` matches`/foo/bar/baz`, but does not match `/foo/barbaz`). + {{< /note >}} #### Multiple Matches In some cases, multiple paths within an Ingress will match a request. In those @@ -402,16 +401,16 @@ metadata: spec: tls: - hosts: - - sslexample.foo.com + - sslexample.foo.com secretName: testsecret-tls rules: - - host: sslexample.foo.com - http: - paths: - - path: / - backend: - serviceName: service1 - servicePort: 80 + - host: sslexample.foo.com + http: + paths: + - path: / + backend: + serviceName: service1 + servicePort: 80 ``` {{< note >}} diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 92654fc612..e97d80db21 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -311,8 +311,8 @@ these are: - `nq`: never queue {{< note >}} -To run kube-proxy in IPVS mode, you must make the IPVS Linux available on -the node before you starting kube-proxy. +To run kube-proxy in IPVS mode, you must make IPVS available on +the node before starting kube-proxy. When kube-proxy starts in IPVS proxy mode, it verifies whether IPVS kernel modules are available. If the IPVS kernel modules are not detected, then kube-proxy @@ -692,6 +692,15 @@ metadata: [...] ``` {{% /tab %}} +{{% tab name="Alibaba Cloud" %}} +```yaml +[...] +metadata: + annotations: + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" +[...] +``` +{{% /tab %}} {{< /tabs >}} @@ -896,7 +905,7 @@ the NLB Target Group's health check on the auto-assigned `.spec.healthCheckNodePort` and not receive any traffic. In order to achieve even traffic, either use a DaemonSet or specify a -[pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) +[pod anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) to not locate on the same node. You can also use NLB Services with the [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer) diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 3d444584ee..c365e02171 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -334,7 +334,7 @@ Such volume is presented into a Pod as a block device, without any filesystem on This mode is useful to provide a Pod the fastest possible way to access a volume, without any filesystem layer between the Pod and the volume. On the other hand, the application running in the Pod must know how to handle a raw block device. -See [Raw Block Volume Support](docs/concepts/storage/persistent-volumes/#raw-block-volume-support) +See [Raw Block Volume Support](#raw-block-volume-support) for an example on how to use a volume with `volumeMode: Block` in a Pod. ### Access Modes @@ -736,9 +736,9 @@ and need persistent storage, it is recommended that you use the following patter `persistentVolumeClaim.storageClassName` field. This will cause the PVC to match the right storage class if the cluster has StorageClasses enabled by the admin. - - If the user does not provide a storage class name, leave the - `persistentVolumeClaim.storageClassName` field as nil. This will cause a - PV to be automatically provisioned for the user with the default StorageClass + - If the user does not provide a storage class name, leave the + `persistentVolumeClaim.storageClassName` field as nil. This will cause a + PV to be automatically provisioned for the user with the default StorageClass in the cluster. Many cluster environments have a default StorageClass installed, or administrators can create their own default StorageClass. - In your tooling, watch for PVCs that are not getting bound after some time @@ -759,4 +759,4 @@ and need persistent storage, it is recommended that you use the following patter * [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) -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 2680185785..1ea7c236d9 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -169,9 +169,9 @@ will delay the binding and provisioning of a PersistentVolume until a Pod using PersistentVolumes will be selected or provisioned conforming to the topology that is specified by the Pod's scheduling constraints. These include, but are not limited to, [resource requirements](/docs/concepts/configuration/manage-compute-resources-container), -[node selectors](/docs/concepts/configuration/assign-pod-node/#nodeselector), +[node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector), [pod affinity and -anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), +anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity), and [taints and tolerations](/docs/concepts/configuration/taint-and-toleration). The following plugins support `WaitForFirstConsumer` with dynamic provisioning: diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 537a813ded..cacab214b6 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -248,14 +248,14 @@ spec: #### CSI Migration -{{< feature-state for_k8s_version="v1.14" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} The CSI Migration feature for Cinder, when enabled, shims 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/using-cinder-csi-plugin.md) must be installed on the cluster and the `CSIMigration` and `CSIMigrationOpenStack` -Alpha features must be enabled. +Beta features must be enabled. ### configMap {#configmap} @@ -305,6 +305,11 @@ A Container using a ConfigMap as a [subPath](#using-subpath) volume mount will n receive ConfigMap updates. {{< /note >}} +{{< note >}} +Text data is exposed as files using the UTF-8 character encoding. To use some other character encoding, use binaryData. +{{< /note >}} + + ### downwardAPI {#downwardapi} A `downwardAPI` volume is used to make downward API data available to applications. diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md index f2feb36515..92cd35953b 100644 --- a/content/en/docs/concepts/workloads/controllers/daemonset.md +++ b/content/en/docs/concepts/workloads/controllers/daemonset.md @@ -99,8 +99,8 @@ create a Pod with a different value on a node for testing. If you specify a `.spec.template.spec.nodeSelector`, then the DaemonSet controller will create Pods on nodes which match that [node -selector](/docs/concepts/configuration/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`, -then DaemonSet controller will create Pods on nodes which match that [node affinity](/docs/concepts/configuration/assign-pod-node/). +selector](/docs/concepts/scheduling-eviction/assign-pod-node/). Likewise if you specify a `.spec.template.spec.affinity`, +then DaemonSet controller will create Pods on nodes which match that [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/). If you do not specify either, then the DaemonSet controller will create Pods on all nodes. ## How Daemon Pods are Scheduled diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 1fd6c5c9d6..2610380641 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/content/en/docs/concepts/workloads/controllers/deployment.md @@ -53,12 +53,13 @@ In this example: In this case, you simply select a label that is defined in the Pod template (`app: nginx`). However, more sophisticated selection rules are possible, as long as the Pod template itself satisfies the rule. - {{< note >}} - The `.spec.selector.matchLabels` field is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map - is equivalent to an element of `matchExpressions`, whose key field is "key" the operator is "In", - and the values array contains only "value". - All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match. - {{< /note >}} + + {{< note >}} + The `.spec.selector.matchLabels` field is a map of {key,value} pairs. + A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`, + whose key field is "key" the operator is "In", and the values array contains only "value". + All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match. + {{< /note >}} * The `template` field contains the following sub-fields: * The Pods are labeled `app: nginx`using the `.metadata.labels` field. @@ -67,84 +68,92 @@ In this example: [Docker Hub](https://hub.docker.com/) image at version 1.14.2. * Create one container and name it `nginx` using the `.spec.template.spec.containers[0].name` field. - Follow the steps given below to create the above Deployment: +Before you begin, make sure your Kubernetes cluster is up and running. +Follow the steps given below to create the above Deployment: - Before you begin, make sure your Kubernetes cluster is up and running. - 1. Create the Deployment by running the following command: +1. Create the Deployment by running the following command: - {{< note >}} - You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future introspection. - For example, to see the commands executed in each Deployment revision. - {{< /note >}} - - ```shell - kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml - ``` - - 2. Run `kubectl get deployments` to check if the Deployment was created. If the Deployment is still being created, the output is similar to the following: - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - nginx-deployment 0/3 0 0 1s - ``` - When you inspect the Deployments in your cluster, the following fields are displayed: - - * `NAME` lists the names of the Deployments in the namespace. - * `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired. - * `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state. - * `AVAILABLE` displays how many replicas of the application are available to your users. - * `AGE` displays the amount of time that the application has been running. - - Notice how the number of desired replicas is 3 according to `.spec.replicas` field. - - 3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. The output is similar to this: - ```shell - Waiting for rollout to finish: 2 out of 3 new replicas have been updated... - deployment.apps/nginx-deployment successfully rolled out - ``` - - 4. Run the `kubectl get deployments` again a few seconds later. The output is similar to this: - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - nginx-deployment 3/3 3 3 18s - ``` - Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available. - - 5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this: - ```shell - NAME DESIRED CURRENT READY AGE - nginx-deployment-75675f5897 3 3 3 18s - ``` - ReplicaSet output shows the following fields: - - * `NAME` lists the names of the ReplicaSets in the namespace. - * `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_. - * `CURRENT` displays how many replicas are currently running. - * `READY` displays how many replicas of the application are available to your users. - * `AGE` displays the amount of time that the application has been running. - - Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is - randomly generated and uses the `pod-template-hash` as a seed. - - 6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. The following output is returned: - ```shell - NAME READY STATUS RESTARTS AGE LABELS - nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 - nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 - nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 - ``` - The created ReplicaSet ensures that there are three `nginx` Pods. + ```shell + kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml + ``` {{< note >}} - You must specify an appropriate selector and Pod template labels in a Deployment (in this case, - `app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly. + You can specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. + The recorded change is useful for future introspection. For example, to see the commands executed in each Deployment revision. {{< /note >}} + +2. Run `kubectl get deployments` to check if the Deployment was created. + + If the Deployment is still being created, the output is similar to the following: + ```shell + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 0/3 0 0 1s + ``` + When you inspect the Deployments in your cluster, the following fields are displayed: + * `NAME` lists the names of the Deployments in the namespace. + * `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired. + * `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state. + * `AVAILABLE` displays how many replicas of the application are available to your users. + * `AGE` displays the amount of time that the application has been running. + + Notice how the number of desired replicas is 3 according to `.spec.replicas` field. + +3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. + + The output is similar to: + ```shell + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + deployment.apps/nginx-deployment successfully rolled out + ``` + +4. Run the `kubectl get deployments` again a few seconds later. + The output is similar to this: + ```shell + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 18s + ``` + Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available. + +5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this: + ```shell + NAME DESIRED CURRENT READY AGE + nginx-deployment-75675f5897 3 3 3 18s + ``` + ReplicaSet output shows the following fields: + + * `NAME` lists the names of the ReplicaSets in the namespace. + * `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_. + * `CURRENT` displays how many replicas are currently running. + * `READY` displays how many replicas of the application are available to your users. + * `AGE` displays the amount of time that the application has been running. + + Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. + The random string is randomly generated and uses the `pod-template-hash` as a seed. + +6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. + The output is similar to: + ```shell + NAME READY STATUS RESTARTS AGE LABELS + nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=3123191453 + ``` + The created ReplicaSet ensures that there are three `nginx` Pods. + +{{< note >}} +You must specify an appropriate selector and Pod template labels in a Deployment +(in this case, `app: nginx`). + +Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly. +{{< /note >}} + ### Pod-template-hash label -{{< note >}} +{{< caution >}} Do not change this label. -{{< /note >}} +{{< /caution >}} The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts. @@ -409,9 +418,7 @@ rolled back. ``` {{< note >}} - The Deployment controller stops the bad rollout automatically, and stops scaling up the new - ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified. - Kubernetes by default sets the value to 25%. + The Deployment controller stops the bad rollout automatically, and stops scaling up the new ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified. Kubernetes by default sets the value to 25%. {{< /note >}} * Get the description of the Deployment: @@ -901,9 +908,9 @@ example, rollback the Deployment to its previous version. {{< /note >}} {{< note >}} -If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can -safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the -deadline. +If you pause a Deployment, Kubernetes does not check progress against your specified deadline. +You can safely pause a Deployment in the middle of a rollout and resume without triggering +the condition for exceeding the deadline. {{< /note >}} You may experience transient errors with your Deployments, either due to a low timeout that you have set or @@ -1081,6 +1088,15 @@ the default value. All existing Pods are killed before new ones are created when `.spec.strategy.type==Recreate`. +{{< note >}} +This will only guarantee Pod termination previous to creation for upgrades. If you upgrade a Deployment, all Pods +of the old revision will be terminated immediately. Successful removal is awaited before any Pod of the new +revision is created. If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the +replacement will be created immediately (even if the old Pod is still in a Terminating state). If you need an +"at most" guarantee for your Pods, you should consider using a +[StatefulSet](/docs/concepts/workloads/controllers/statefulset/). +{{< /note >}} + #### Rolling Update Deployment The Deployment updates Pods in a rolling update diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md index fe7a96c138..92cbe60a33 100644 --- a/content/en/docs/concepts/workloads/controllers/replicaset.md +++ b/content/en/docs/concepts/workloads/controllers/replicaset.md @@ -330,7 +330,7 @@ Alternatively, you can use the `kubectl autoscale` command to accomplish the sam (and it's easier!) ```shell -kubectl autoscale rs frontend --max=10 +kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 ``` ## Alternatives to ReplicaSet diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md index aa6a07788b..661955cb48 100644 --- a/content/en/docs/concepts/workloads/controllers/statefulset.md +++ b/content/en/docs/concepts/workloads/controllers/statefulset.md @@ -156,7 +156,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain {{< note >}} Cluster Domain will be set to `cluster.local` unless -[otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works). +[otherwise configured](/docs/concepts/services-networking/dns-pod-service/). {{< /note >}} ### Stable Storage diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 00265e0433..9983a67fc8 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -97,6 +97,8 @@ time as frequent voluntary disruptions. We call this set of features ## How Disruption Budgets Work +{{< feature-state for_k8s_version="v1.5" state="beta" >}} + An Application Owner can create a `PodDisruptionBudget` object (PDB) for each application. A PDB limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, a quorum-based application would @@ -211,7 +213,7 @@ state: | node-1 *drained* | node-2 | node-3 | *no node* | |:--------------------:|:-------------------:|:------------------:|:------------------:| -| | pod-b *available* | pod-c *available* | pod-e *pending* | +| | pod-b *terminating* | pod-c *available* | pod-e *pending* | | | pod-d *available* | pod-y | | At this point, the cluster administrator needs to diff --git a/content/en/docs/concepts/workloads/pods/init-containers.md b/content/en/docs/concepts/workloads/pods/init-containers.md index 2ecbdd702a..eaf48a95a6 100644 --- a/content/en/docs/concepts/workloads/pods/init-containers.md +++ b/content/en/docs/concepts/workloads/pods/init-containers.md @@ -46,8 +46,8 @@ including resource limits, volumes, and security settings. However, the resource requests and limits for an init container are handled differently, as documented in [Resources](#resources). -Also, init containers do not support readiness probes because they must run to -completion before the Pod can be ready. +Also, init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or +`startupProbe` because they must run to completion before the Pod can be ready. If you specify multiple init containers for a Pod, Kubelet runs each init container sequentially. Each init container must succeed before the next can run. @@ -241,7 +241,7 @@ myapp-pod 1/1 Running 0 9m ``` This simple example should provide some inspiration for you to create your own -init containers. [What's next](#what-s-next) contains a link to a more detailed example. +init containers. [What's next](#whats-next) contains a link to a more detailed example. ## Detailed behavior @@ -325,4 +325,4 @@ reasons: * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container) * Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/) -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 1c68ba4ebd..6e6f878449 100644 --- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -55,7 +55,7 @@ Instead of manually applying labels, you can also reuse the [well-known labels]( The field `pod.spec.topologySpreadConstraints` is introduced in 1.16 as below: -```yaml +``` apiVersion: v1 kind: Pod metadata: @@ -97,7 +97,7 @@ If we want an incoming Pod to be evenly spread with existing Pods across zones, {{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}} -`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint. +`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:<any value>" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint. If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB": diff --git a/content/en/docs/concepts/workloads/pods/podpreset.md b/content/en/docs/concepts/workloads/pods/podpreset.md index 876ba995c9..a1906c8b99 100644 --- a/content/en/docs/concepts/workloads/pods/podpreset.md +++ b/content/en/docs/concepts/workloads/pods/podpreset.md @@ -7,6 +7,8 @@ weight: 50 --- {{% capture overview %}} +{{< feature-state for_k8s_version="v1.6" state="alpha" >}} + This page provides an overview of PodPresets, which are objects for injecting certain information into pods at creation time. The information can include secrets, volumes, volume mounts, and environment variables. @@ -14,20 +16,38 @@ secrets, volumes, volume mounts, and environment variables. {{% capture body %}} -## Understanding Pod Presets +## Understanding Pod presets -A `Pod Preset` is an API resource for injecting additional runtime requirements +A PodPreset is an API resource for injecting additional runtime requirements into a Pod at creation time. You use [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) -to specify the Pods to which a given Pod Preset applies. +to specify the Pods to which a given PodPreset applies. -Using a Pod Preset allows pod template authors to not have to explicitly provide +Using a PodPreset allows pod template authors to not have to explicitly provide all information for every pod. This way, authors of pod templates consuming a specific service do not need to know all the details about that service. -For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md). -## How It Works +## Enable PodPreset in your cluster {#enable-pod-preset} + +In order to use Pod presets in your cluster you must ensure the following: + +1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For + example, this can be done by including `settings.k8s.io/v1alpha1=true` in + the `--runtime-config` option for the API server. In minikube add this flag + `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while + starting the cluster. +1. You have enabled the admission controller `PodPreset`. One way to doing this + is to include `PodPreset` in the `--enable-admission-plugins` option value specified + for the API server. In minikube, add this flag + + ```shell + --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset + ``` + + while starting the cluster. + +## How it works Kubernetes provides an admission controller (`PodPreset`) which, when enabled, applies Pod Presets to incoming pod creation requests. @@ -62,31 +82,12 @@ There may be instances where you wish for a Pod to not be altered by any Pod Preset mutations. In these cases, you can add an annotation in the Pod Spec of the form: `podpreset.admission.kubernetes.io/exclude: "true"`. -## Enable Pod Preset - -In order to use Pod Presets in your cluster you must ensure the following: - -1. You have enabled the API type `settings.k8s.io/v1alpha1/podpreset`. For - example, this can be done by including `settings.k8s.io/v1alpha1=true` in - the `--runtime-config` option for the API server. In minikube add this flag - `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` while - starting the cluster. -1. You have enabled the admission controller `PodPreset`. One way to doing this - is to include `PodPreset` in the `--enable-admission-plugins` option value specified - for the API server. In minikube add this flag - - ```shell - --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset - ``` - - while starting the cluster. -1. You have defined your Pod Presets by creating `PodPreset` objects in the - namespace you will use. - {{% /capture %}} {{% capture whatsnext %}} -* [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/) +See [Injecting data into a Pod using PodPreset](/docs/tasks/inject-data-application/podpreset/) + +For more information about the background, see the [design proposal for PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md). {{% /capture %}} diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 6574bba709..2ed3a4afd6 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -35,7 +35,7 @@ The PR wrangler’s duties include: - Assign relevant `sig/` label(s). - If needed, assign reviewers from the `reviewers:` block in the file's front matter. - Assign `Docs Review` and `Tech Review` labels to indicate the PR's review status. - - Assign`Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed. + - Assign `Needs Doc Review` or `Needs Tech Review` for PRs that haven't yet been reviewed. - Assign `Doc Review: Open Issues` or `Tech Review: Open Issues` for PRs that have been reviewed and require further input or action before merging. - Assign `/lgtm` and `/approve` labels to PRs that can be merged. - Merge PRs when they are ready, or close PRs that shouldn’t be accepted. @@ -43,7 +43,7 @@ The PR wrangler’s duties include: ### Helpful GitHub queries for wranglers -The following queries are helpful when wrangling. After working through these three queries, the remaining list of PRs to be +The following queries are helpful when wrangling. After working through these queries, the remaining list of PRs to be reviewed is usually small. These queries specifically exclude localization PRs, and only include the `master` branch (except for the last one). - [No CLA, not eligible to merge](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): @@ -245,4 +245,4 @@ When you’re ready to stop recording, click Stop. The video uploads automatically to YouTube. -{{% /capture %}} \ No newline at end of file +{{% /capture %}} diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md index f2be84f10d..dccc6cfe38 100644 --- a/content/en/docs/contribute/review/for-approvers.md +++ b/content/en/docs/contribute/review/for-approvers.md @@ -73,8 +73,7 @@ true: [Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md) is the Kubernetes-based CI/CD system that runs jobs against pull requests (PRs). Prow enables chatbot-style commands to handle GitHub actions across the Kubernetes -organization, like [adding and removing -labels](#add-and-remove-labels), closing issues, and assigning an approver. Enter Prow commands as GitHub comments using the `/` format. +organization, like [adding and removing labels](#adding-and-removing-issue-labels), closing issues, and assigning an approver. Enter Prow commands as GitHub comments using the `/` format. The most common prow commands reviewers and approvers use are: diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index a19d492d54..a254e43a84 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -250,7 +250,7 @@ for more details. This plug-in facilitates creation of dedicated nodes with extended resources. If operators want to create dedicated nodes with extended resources (like GPUs, FPGAs etc.), they are expected to -[taint the node](/docs/concepts/configuration/taint-and-toleration/#example-use-cases) with the extended resource +[taint the node](/docs/concepts/scheduling-eviction/taint-and-toleration/#example-use-cases) with the extended resource name as the key. This admission controller, if enabled, automatically adds tolerations for such taints to pods requesting extended resources, so users don't have to manually add these tolerations. diff --git a/content/en/docs/reference/access-authn-authz/authorization.md b/content/en/docs/reference/access-authn-authz/authorization.md index ccb19604b8..3a942266fc 100644 --- a/content/en/docs/reference/access-authn-authz/authorization.md +++ b/content/en/docs/reference/access-authn-authz/authorization.md @@ -17,7 +17,7 @@ policies using the supported authorization modules. {{% capture body %}} In Kubernetes, you must be authenticated (logged in) before your request can be authorized (granted permission to access). For information about authentication, -see [Accessing Control Overview](/docs/reference/access-authn-authz/controlling-access/). +see [Controlling Access to the Kubernetes API](/docs/reference/access-authn-authz/controlling-access/). Kubernetes expects attributes that are common to REST API requests. This means that Kubernetes authorization works with existing organization-wide or 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 64ab4d45bf..752ee40f7d 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 @@ -114,6 +114,8 @@ different Kubernetes components. | `MountContainers` | `false` | Alpha | 1.9 | | | `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | | | `NonPreemptingPriority` | `false` | Alpha | 1.15 | | +| `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 | +| `PodDisruptionBudget` | `true` | Beta | 1.5 | | | `PodOverhead` | `false` | Alpha | 1.16 | - | | `ProcMountType` | `false` | Alpha | 1.12 | | | `QOSReserved` | `false` | Alpha | 1.11 | | @@ -333,7 +335,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `Accelerators`: Enable Nvidia GPU support when using Docker - `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug-application-cluster/audit/#advanced-audit) -- `AffinityInAnnotations`(*deprecated*): Enable setting [Pod affinity or anti-affinity](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). +- `AffinityInAnnotations`(*deprecated*): 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. - `AnyVolumeDataSource`: Enable use of any custom resource as the `DataSource` of a {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}}. @@ -441,6 +443,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `NonPreemptingPriority`: Enable NonPreempting option for PriorityClass and Pod. - `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. - `PodOverhead`: Enable the [PodOverhead](/docs/concepts/configuration/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/). - `PodReadinessGates`: Enable the setting of `PodReadinessGate` field for extending @@ -486,7 +489,7 @@ Each feature gate is designed for enabling/disabling a specific feature: - `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. - `TaintBasedEvictions`: Enable evicting pods from nodes based on taints on nodes and tolerations on Pods. - See [taints and tolerations](/docs/concepts/configuration/taint-and-toleration/) for more details. + See [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) for more details. - `TaintNodesByCondition`: Enable automatic tainting nodes based on [node conditions](/docs/concepts/architecture/nodes/#condition). - `TokenRequest`: Enable the `TokenRequest` endpoint on service account resources. - `TokenRequestProjection`: Enable the injection of service account tokens into 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 660463c64d..595ef138fc 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -29,1240 +29,1240 @@ kubelet [flags] {{% capture options %}} - - - - - - +
++++ + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - - - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + + + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--add-dir-header
If true, adds the file directory to the header
--add-dir-header
If true, adds the file directory to the header
--address 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) (default 0.0.0.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.)
--address 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) (default 0.0.0.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.)
--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.)
--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.)
--alsologtostderr
log to standard error as well as files
--alsologtostderr
log to standard error as well as files
--anonymous-auth
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. (default true) (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.)
--anonymous-auth
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. (default true) (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.)
--application-metrics-count-limit int
Max number of application metrics to store (per container) (default 100) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--application-metrics-count-limit int
Max number of application metrics to store (per container) (default 100) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns,it will follow the standard CLI deprecation timeline before being removed.)
--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.)
--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.)
--authentication-token-webhook-cache-ttl duration
The duration to cache responses from the webhook token authenticator. (default 2m0s) (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
The duration to cache responses from the webhook token authenticator. (default 2m0s) (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") (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-webhook-cache-authorized-ttl duration
The duration to cache 'authorized' responses from the webhook authorizer. (default 5m0s) (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
The duration to cache 'authorized' responses from the webhook authorizer. (default 5m0s) (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
The duration to cache 'unauthorized' responses from the webhook authorizer. (default 30s) (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
The duration to cache 'unauthorized' responses from the webhook authorizer. (default 30s) (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.)
--azure-container-registry-config string
Path to the file container Azure container registry configuration information.
--azure-container-registry-config string
Path to the file container Azure container registry configuration information.
--boot-id-file string
Comma-separated list of files to check for boot-id. Use the first one that exists. (default "/proc/sys/kernel/random/boot_id") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--boot-id-file string
Comma-separated list of files to check for boot-id. Use the first one that exists. (default "/proc/sys/kernel/random/boot_id") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--bootstrap-checkpoint-path string
Path to the directory where the checkpoints are stored
--bootstrap-checkpoint-path string
<Warning: Alpha feature> Path to the directory where the checkpoints are stored
--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.
--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.
--cert-dir string
The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/lib/kubelet/pki")
--cert-dir string
The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/lib/kubelet/pki")
--cgroup-driver string
Driver that the kubelet uses to manipulate cgroups on the host. Possible values: 'cgroupfs', 'systemd' (default "cgroupfs") (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-driver string
Driver that the kubelet uses to manipulate cgroups on the host. Possible values: 'cgroupfs', 'systemd' (default "cgroupfs") (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
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.)
--cgroup-root string
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
Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. (default true) (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
Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. (default true) (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.
--chaos-chance float
If > 0.0, introduce random client errors and latency. Intended for testing.
--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.)
--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.)
--cloud-config string
The path to the cloud provider configuration file.
--cloud-config string
The path to the cloud provider configuration file.
--cloud-provider string
The provider for cloud services. Specify empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).
--cloud-provider string
The provider for cloud services. Specify empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).
--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.)
--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.)
--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.)
--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.)
--cni-bin-dir string
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. (default "/opt/cni/bin")
--cni-bin-dir string
<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. (default "/opt/cni/bin")
--cni-cache-dir string
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. (default "/var/lib/cni/cache")
--cni-cache-dir string
<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. (default "/var/lib/cni/cache")
--cni-conf-dir string
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. (default "/etc/cni/net.d")
--cni-conf-dir string
<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. (default "/etc/cni/net.d")
--config string
The Kubelet will load its initial configuration from this file. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Omit this flag to use the built-in default configuration values. Command-line flags override configuration from this file.
--config string
The Kubelet will load its initial configuration from this file. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Omit this flag to use the built-in default configuration values. Command-line flags override configuration from this file.
--container-hints string
location of the container hints file (default "/etc/cadvisor/container_hints.json") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--container-hints string
location of the container hints file (default "/etc/cadvisor/container_hints.json") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--container-log-max-files int32
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. (default 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.)
--container-log-max-size string
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. (default "10Mi") (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-files int32
<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. (default 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.)
--container-runtime string
The container runtime to use. Possible values: 'docker', 'remote', 'rkt(deprecated)'. (default "docker")
--container-log-max-size string
<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. (default "10Mi") (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-endpoint string
[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' (default "unix:///var/run/dockershim.sock")
--container-runtime string
The container runtime to use. Possible values: 'docker', 'remote', 'rkt(deprecated)'. (default "docker")
--containerd string
containerd endpoint (default "/run/containerd/containerd.sock") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--container-runtime-endpoint string
[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' (default "unix:///var/run/dockershim.sock")
--containerd string
containerd endpoint (default "/run/containerd/containerd.sock") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--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.)
--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.)
--cpu-cfs-quota
Enable CPU CFS quota enforcement for containers that specify CPU limits (default true) (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
Enable CPU CFS quota enforcement for containers that specify CPU limits (default true) (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
Sets CPU CFS quota period value, cpu.cfs_period_us, defaults to Linux Kernel default (default 100ms) (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
Sets CPU CFS quota period value, cpu.cfs_period_us, defaults to Linux Kernel default (default 100ms) (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
CPU Manager policy to use. Possible values: 'none', 'static'. Default: 'none' (default "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.)
--cpu-manager-policy string
CPU Manager policy to use. Possible values: 'none', 'static'. Default: 'none' (default "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.)
--cpu-manager-reconcile-period NodeStatusUpdateFrequency
CPU Manager reconciliation period. Examples: '10s', or '1m'. If not supplied, defaults to NodeStatusUpdateFrequency (default 10s) (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 NodeStatusUpdateFrequency
<Warning: Alpha feature> CPU Manager reconciliation period. Examples: '10s', or '1m'. If not supplied, defaults to NodeStatusUpdateFrequency (default 10s) (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 string
docker endpoint (default "unix:///var/run/docker.sock") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker string
docker endpoint (default "unix:///var/run/docker.sock") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-endpoint string
Use this for the docker endpoint to communicate with. This docker-specific flag only works when container-runtime is set to docker. (default "unix:///var/run/docker.sock")
--docker-endpoint string
Use this for the docker endpoint to communicate with. This docker-specific flag only works when container-runtime is set to docker. (default "unix:///var/run/docker.sock")
--docker-env-metadata-whitelist string
a comma-separated list of environment variable keys that needs to be collected for docker containers (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-env-metadata-whitelist string
a comma-separated list of environment variable keys that needs to be collected for docker containers (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-only
Only report docker containers in addition to root stats (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-only
Only report docker containers in addition to root stats (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-root string
DEPRECATED: docker root is read from docker info (this is a fallback, default: /var/lib/docker) (default "/var/lib/docker")
--docker-root string
DEPRECATED: docker root is read from docker info (this is a fallback, default: /var/lib/docker) (default "/var/lib/docker")
--docker-tls
use TLS to connect to docker (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls
use TLS to connect to docker (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-ca string
path to trusted CA (default "ca.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-ca string
path to trusted CA (default "ca.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-cert string
path to client certificate (default "cert.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-cert string
path to client certificate (default "cert.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-key string
path to private key (default "key.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--docker-tls-key string
path to private key (default "key.pem") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--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.
--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.
--enable-cadvisor-json-endpoints
Enable cAdvisor json /spec and /stats/* endpoints. (default false) (DEPRECATED: will be removed in a future version)
--enable-cadvisor-json-endpoints
Enable cAdvisor json /spec and /stats/* endpoints. (default false) (DEPRECATED: will be removed in a future version)
--enable-controller-attach-detach
Enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and disables kubelet from executing any attach/detach operations (default true)
--enable-controller-attach-detach
Enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and disables kubelet from executing any attach/detach operations (default true)
--enable-debugging-handlers
Enables server endpoints for log collection and local running of containers and commands (default true) (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
Enables server endpoints for log collection and local running of containers and commands (default true) (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-load-reader
Whether to enable cpu load reader (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--enable-load-reader
Whether to enable cpu load reader (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--enable-server
Enable the Kubelet's server (default true)
--enable-server
Enable the Kubelet's server (default true)
--enforce-node-allocatable stringSlice
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. (default [pods]) (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 stringSlice
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. (default [pods]) (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
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 (default 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-burst int32
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 (default 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
If > 0, limit event creations per second to this value. If 0, unlimited. (default 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.)
--event-qps int32
If > 0, limit event creations per second to this value. If 0, unlimited. (default 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.)
--event-storage-age-limit string
Max length of time for which to store events (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is a duration. Default is applied to all non-specified event types (default "default=0") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--event-storage-age-limit string
Max length of time for which to store events (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is a duration. Default is applied to all non-specified event types (default "default=0") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--event-storage-event-limit string
Max number of events to store (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is an integer. Default is applied to all non-specified event types (default "default=0") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--event-storage-event-limit string
Max number of events to store (per type). Value is a comma separated list of key values, where the keys are event types (e.g.: creation, oom) or "default" and the value is an integer. Default is applied to all non-specified event types (default "default=0") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--eviction-hard mapStringString
A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. (default imagefs.available<15%,memory.available<100Mi,nodefs.available<10%,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-hard mapStringString
A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. (default imagefs.available<15%,memory.available<100Mi,nodefs.available<10%,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.)
--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.)
--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.)
--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.)
--eviction-pressure-transition-period duration
Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. (default 5m0s) (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
Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. (default 5m0s) (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.)
--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.)
--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.)
--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.)
--exit-on-lock-contention
Whether kubelet should exit upon lock-file contention.
--exit-on-lock-contention
Whether kubelet should exit upon lock-file contention.
--experimental-allocatable-ignore-eviction
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. [default=false]
--experimental-allocatable-ignore-eviction
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. [default=false]
--experimental-bootstrap-kubeconfig string
(DEPRECATED: Use --bootstrap-kubeconfig)
--experimental-bootstrap-kubeconfig string
(DEPRECATED: Use --bootstrap-kubeconfig)
--experimental-check-node-capabilities-before-mount
[Experimental] if set true, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount
--experimental-check-node-capabilities-before-mount
[Experimental] if set true, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount
--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.
--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.
--experimental-mounter-path string
[Experimental] Path of mounter binary. Leave empty to use the default mount.
--experimental-mounter-path string
[Experimental] Path of mounter binary. Leave empty to use the default mount.
--fail-swap-on
Makes the Kubelet fail to start if swap is enabled on the node. (default true) (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.)
--fail-swap-on
Makes the Kubelet fail to start if swap is enabled on the node. (default true) (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
A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
AllAlpha=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
AttachVolumeLimit=true|false (BETA - default=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
BlockVolume=true|false (BETA - default=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)
CPUManager=true|false (BETA - default=true)
CRIContainerLogRotation=true|false (BETA - default=true) -
CSIBlockVolume=true|false (BETA - default=true)
CSIDriverRegistry=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (ALPHA - default=false)
CSIMigrationAWS=true|false (ALPHA - default=false)
CSIMigrationAzureDisk=true|false (ALPHA - default=false)
CSIMigrationAzureFile=true|false (ALPHA - default=false)
CSIMigrationGCE=true|false (ALPHA - default=false)
CSIMigrationOpenStack=true|false (ALPHA - default=false)
CSINodeInfo=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomResourceDefaulting=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DryRun=true|false (BETA - default=true)
DynamicAuditing=true|false (ALPHA - default=false)
DynamicKubeletConfig=true|false (BETA - default=true)
EndpointSlice=true|false (ALPHA - default=false)
EphemeralContainers=true|false (ALPHA - default=false)
EvenPodsSpread=true|false (ALPHA - default=false)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HyperVContainer=true|false (ALPHA - default=false)
IPv6DualStack=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
LegacyNodeRoleBehavior=true|false (ALPHA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
MountContainers=true|false (ALPHA - default=false)
NodeDisruptionExclusion=true|false (ALPHA - default=false)
NodeLease=true|false (BETA - default=true)
NonPreemptingPriority=true|false (ALPHA - default=false)
PodOverhead=true|false (ALPHA - default=false)
PodShareProcessNamespace=true|false (BETA - default=true)
ProcMountType=true|false (ALPHA - default=false)br/>QOSReserved=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (ALPHA - default=false)
RequestManagement=true|false (ALPHA - default=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)
ResourceQuotaScopeSelectors=true|false (BETA - default=true)
RotateKubeletClientCertificate=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
RunAsGroup=true|false (BETA - default=true)
RuntimeClass=true|false (BETA - default=true)
SCTPSupport=true|false (ALPHA - default=false)
ScheduleDaemonSetPods=true|false (BETA - default=true)
ServerSideApply=true|false (BETA - default=true)
ServiceLoadBalancerFinalizer=true|false (BETA - default=true)
ServiceNodeExclusion=true|false (ALPHA - default=false)
StartupProbe=true|false (BETA - default=true)
StorageVersionHash=true|false (BETA - default=true)
StreamingProxyRedirects=true|false (BETA - default=true)
SupportNodePidsLimit=true|false (BETA - default=true)
SupportPodPidsLimit=true|false (BETA - default=true)
Sysctls=true|false (BETA - default=true)
TTLAfterFinished=true|false (ALPHA - default=false)
TaintBasedEvictions=true|false (BETA - default=true)
TaintNodesByCondition=true|false (BETA - default=true)
TokenRequest=true|false (BETA - default=true)
TokenRequestProjection=true|false (BETA - default=true)
TopologyManager=true|false (ALPHA - default=false)
ValidateProxyRedirects=true|false (BETA - default=true)
VolumePVCDataSource=true|false (BETA - default=true)
VolumeSnapshotDataSource=true|false (ALPHA - default=false)
VolumeSubpathEnvExpansion=true|false (BETA - default=true)
WatchBookmark=true|false (BETA - default=true)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (ALPHA - default=false)
WindowsGMSA=true|false (BETA - default=true)
WindowsRunAsUserName=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.)
--feature-gates mapStringBool
A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
AllAlpha=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
AttachVolumeLimit=true|false (BETA - default=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
BlockVolume=true|false (BETA - default=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)
CPUManager=true|false (BETA - default=true)
CRIContainerLogRotation=true|false (BETA - default=true) +
CSIBlockVolume=true|false (BETA - default=true)
CSIDriverRegistry=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (ALPHA - default=false)
CSIMigrationAWS=true|false (ALPHA - default=false)
CSIMigrationAzureDisk=true|false (ALPHA - default=false)
CSIMigrationAzureFile=true|false (ALPHA - default=false)
CSIMigrationGCE=true|false (ALPHA - default=false)
CSIMigrationOpenStack=true|false (ALPHA - default=false)
CSINodeInfo=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomResourceDefaulting=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DryRun=true|false (BETA - default=true)
DynamicAuditing=true|false (ALPHA - default=false)
DynamicKubeletConfig=true|false (BETA - default=true)
EndpointSlice=true|false (ALPHA - default=false)
EphemeralContainers=true|false (ALPHA - default=false)
EvenPodsSpread=true|false (ALPHA - default=false)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HyperVContainer=true|false (ALPHA - default=false)
IPv6DualStack=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
LegacyNodeRoleBehavior=true|false (ALPHA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
MountContainers=true|false (ALPHA - default=false)
NodeDisruptionExclusion=true|false (ALPHA - default=false)
NodeLease=true|false (BETA - default=true)
NonPreemptingPriority=true|false (ALPHA - default=false)
PodOverhead=true|false (ALPHA - default=false)
PodShareProcessNamespace=true|false (BETA - default=true)
ProcMountType=true|false (ALPHA - default=false)br/>QOSReserved=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (ALPHA - default=false)
RequestManagement=true|false (ALPHA - default=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - default=false)
ResourceQuotaScopeSelectors=true|false (BETA - default=true)
RotateKubeletClientCertificate=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
RunAsGroup=true|false (BETA - default=true)
RuntimeClass=true|false (BETA - default=true)
SCTPSupport=true|false (ALPHA - default=false)
ScheduleDaemonSetPods=true|false (BETA - default=true)
ServerSideApply=true|false (BETA - default=true)
ServiceLoadBalancerFinalizer=true|false (BETA - default=true)
ServiceNodeExclusion=true|false (ALPHA - default=false)
StartupProbe=true|false (BETA - default=true)
StorageVersionHash=true|false (BETA - default=true)
StreamingProxyRedirects=true|false (BETA - default=true)
SupportNodePidsLimit=true|false (BETA - default=true)
SupportPodPidsLimit=true|false (BETA - default=true)
Sysctls=true|false (BETA - default=true)
TTLAfterFinished=true|false (ALPHA - default=false)
TaintBasedEvictions=true|false (BETA - default=true)
TaintNodesByCondition=true|false (BETA - default=true)
TokenRequest=true|false (BETA - default=true)
TokenRequestProjection=true|false (BETA - default=true)
TopologyManager=true|false (ALPHA - default=false)
ValidateProxyRedirects=true|false (BETA - default=true)
VolumePVCDataSource=true|false (BETA - default=true)
VolumeSnapshotDataSource=true|false (ALPHA - default=false)
VolumeSubpathEnvExpansion=true|false (BETA - default=true)
WatchBookmark=true|false (BETA - default=true)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (ALPHA - default=false)
WindowsGMSA=true|false (BETA - default=true)
WindowsRunAsUserName=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
Duration between checking config files for new data (default 20s) (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
Duration between checking config files for new data (default 20s) (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.)
--global-housekeeping-interval duration
Interval between global housekeepings (default 1m0s) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--global-housekeeping-interval duration
Interval between global housekeepings (default 1m0s) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--hairpin-mode string
How should the kubelet setup hairpin NAT. This allows endpoints of a Service to loadbalance back to themselves if they should try to access their own Service. Valid values are "promiscuous-bridge", "hairpin-veth" and "none". (default "promiscuous-bridge") (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
How should the kubelet setup hairpin NAT. This allows endpoints of a Service to loadbalance back to themselves if they should try to access their own Service. Valid values are "promiscuous-bridge", "hairpin-veth" and "none". (default "promiscuous-bridge") (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 0.0.0.0
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) (default 127.0.0.1) (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 0.0.0.0
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) (default 127.0.0.1) (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
The port of the localhost healthz endpoint (set to 0 to disable) (default 10248) (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
The port of the localhost healthz endpoint (set to 0 to disable) (default 10248) (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.)
-h, --help
help for kubelet
-h, --help
help for kubelet
--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).
--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).
--housekeeping-interval duration
Interval between container housekeepings (default 10s)
--housekeeping-interval duration
Interval between container housekeepings (default 10s)
--http-check-frequency duration
Duration between checking http for new data (default 20s) (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.)
--http-check-frequency duration
Duration between checking http for new data (default 20s) (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
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. (default 85) (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
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. (default 85) (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
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. (default 80) (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
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. (default 80) (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
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. (default 1m0s)
--image-pull-progress-deadline duration
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. (default 1m0s)
--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'
--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'
--iptables-drop-bit int32
The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (default 15) (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-drop-bit int32
The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (default 15) (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
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. (default 14) (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
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. (default 14) (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.)
--keep-terminated-pod-volumes
Keep terminated pod volumes mounted to the node after the pod terminates. Can be useful for debugging volume related issues. (DEPRECATED: will be removed in a future version)
--keep-terminated-pod-volumes
Keep terminated pod volumes mounted to the node after the pod terminates. Can be useful for debugging volume related issues. (DEPRECATED: will be removed in a future version)
--kube-api-burst int32
Burst to use while talking with kubernetes apiserver (default 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-burst int32
Burst to use while talking with kubernetes apiserver (default 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
Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf") (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
Content type of requests sent to apiserver. (default "application/vnd.kubernetes.protobuf") (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
QPS to use while talking with kubernetes apiserver (default 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-api-qps int32
QPS to use while talking with kubernetes apiserver (default 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
A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) 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. [default=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.)
--kube-reserved mapStringString
A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) 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. [default=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.)
--kube-reserved-cgroup string
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'. [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.)
--kube-reserved-cgroup string
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'. [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.)
--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.
--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.
--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.)
--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.)
--lock-file string
The path to file for kubelet to use as a lock file.
--lock-file string
<Warning: Alpha feature> The path to file for kubelet to use as a lock file.
--log-backtrace-at traceLocation
when logging hits line file:N, emit a stack trace (default :0)
--log-backtrace-at traceLocation
when logging hits line file:N, emit a stack trace (default :0)
--log-cadvisor-usage
Whether to log the usage of the cAdvisor container (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--log-cadvisor-usage
Whether to log the usage of the cAdvisor container (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--log-dir string
If non-empty, write log files in this directory
--log-dir string
If non-empty, write log files in this directory
--log-file string
If non-empty, use this log file
--log-file-max-size uint
Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
--log-flush-frequency duration
Maximum number of seconds between log flushes (default 5s)
--logtostderr
log to standard error instead of files (default true)
--machine-id-file string
Comma-separated list of files to check for machine-id. Use the first one that exists. (default "/etc/machine-id,/var/lib/dbus/machine-id") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--make-iptables-util-chains
If true, kubelet will ensure iptables utility rules are present on host. (default true) (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.)
--manifest-url-header --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'
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
The namespace from which the kubernetes master services should be injected into pods (default "default") (DEPRECATED: This flag will be removed in a future version.)
--log-file string
If non-empty, use this log file
--log-file-max-size uint
Defines the maximum - size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
--log-flush-frequency duration
Maximum number of seconds between log flushes (default 5s)
--logtostderr
log to standard error instead of files (default true)
--machine-id-file string
Comma-separated list of files to check for machine-id. Use the first one that exists. (default "/etc/machine-id,/var/lib/dbus/machine-id") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--make-iptables-util-chains
If true, kubelet will ensure iptables utility rules are present on host. (default true) (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.)
--manifest-url-header --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'
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
The namespace from which the kubernetes master services should be injected into pods (default "default") (DEPRECATED: This flag will be removed in a future version.)
--max-open-files int
Number of files that can be opened by Kubelet process. (default 1000000) (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
Number of Pods that can run on this Kubelet. (default 110) (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
Maximum number of old instances of containers to retain globally. Each container takes up some disk space. To disable, set to a negative number. (default -1) (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--maximum-dead-containers-per-container int32
Maximum number of old instances to retain per container. Each container takes up some disk space. (default 1) (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--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-image-ttl-duration duration
Minimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. (default 2m0s) (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
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.
--network-plugin-mtu int32
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.
--node-ip string
IP address of the node. If set, kubelet will use this IP address for the node
--node-labels mapStringString
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, failure-domain.kubernetes.io/region, failure-domain.kubernetes.io/zone, kubernetes.io/arch, kubernetes.io/hostname, kubernetes.io/instance-type, kubernetes.io/os)
--node-status-max-images int32
The maximum number of images to report in Node.Status.Images. If -1 is specified, no cap will be applied. (default 50)
--node-status-update-frequency duration
Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in nodecontroller. (default 10s) (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
Traffic to IPs outside this range will use IP masquerade. Set to '0.0.0.0/0' to never masquerade. (default "10.0.0.0/8") (DEPRECATED: will be removed in a future version)
--oom-score-adj int32
The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000] (default -999) (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.)
--pod-infra-container-image string
The image whose network/ipc namespaces containers in each pod will use. This docker-specific flag only works when container-runtime is set to docker. (default "k8s.gcr.io/pause:3.2")
--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.)
--pod-max-pids int
Set the maximum number of processes per pod. If -1, the kubelet defaults to the node allocatable pid capacity. (default -1) (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.)
--port int32
The port for the Kubelet to serve on. (default 10250) (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.)
--provider-id string
Unique identifier for identifying the node in a machine database, i.e cloudprovider
--qos-reserved mapStringString
A set of ResourceName=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
The read-only port for the Kubelet to serve on with no authentication/authorization (set to 0 to disable) (default 10255) (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.)
--really-crash-for-testing
If true, when panics occur crash. Intended for testing.
--redirect-container-streaming
Enables container streaming redirect. If false, kubelet will proxy container streaming data between apiserver and container runtime; if true, kubelet will return an http redirect to apiserver, and apiserver 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.
--register-node
Register the node with the apiserver. If --kubeconfig is not provided, this flag is irrelevant, as the Kubelet won't have an apiserver to register with. Default=true. (default true)
--register-schedulable
Register the node as schedulable. Won't have any effect if register-node is false. (default true) (DEPRECATED: will be removed in a future version)
--register-with-taints []api.Taint
Register the node with the given list of taints (comma separated "=:"). No-op if register-node is false.
--registry-burst int32
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 (default 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.)
--registry-qps int32
If > 0, limit registry pull QPS to this value. If 0, unlimited. (default 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.)
--resolv-conf string
Resolver configuration file used as the basis for the container DNS resolution configuration. (default "/etc/resolv.conf") (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
Directory path for managing kubelet files (volume mounts,etc). (default "/var/lib/kubelet")
--rotate-certificates
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.)
--runonce
If true, exit after spawning pods from local manifests or remote urls. Exclusive with --enable-server
--runtime-cgroups string
Optional absolute name of cgroups to create and run the runtime in.
--runtime-request-timeout duration
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. (default 2m0s) (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
Directory path for seccomp profiles. (default "/var/lib/kubelet/seccomp")
--serialize-image-pulls
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. (default true) (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 messages
--skip-log-headers
If true, avoid headers when opening log files
--stderrthreshold severity
logs at or above this threshold go to stderr (default 2)
--storage-driver-buffer-duration duration
Writes in the storage driver will be buffered for this duration, and committed to the non memory backends as a single transaction (default 1m0s) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-db string
database name (default "cadvisor") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-host string
database host:port (default "localhost:8086") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-password string
database password (default "root") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-secure
use secure connection with database (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-table string
table name (default "stats") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-user string
database username (default "root") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--streaming-connection-idle-timeout duration
Maximum time a streaming connection can be idle before the connection is automatically closed. 0 indicates no timeout. Example: '5m' (default 4h0m0s) (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
Max period between synchronizing running containers and config (default 1m0s) (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 /
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
A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) 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. [default=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.)
--system-reserved-cgroup string
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'. [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.)
--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.)
--tls-cipher-suites stringSlice
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,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_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,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_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,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.)
--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.)
--topology-manager-policy string
Topology Manager policy to use. Possible values: 'none', 'best-effort', 'restricted', 'single-numa-node'. (default "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.)
-v, --v Level
number for the log level verbosity
--version version[=true]
Print version information and quit
--vmodule moduleSpec
comma-separated list of pattern=N settings for file-filtered logging
--volume-plugin-dir string
The full path of the directory in which to search for additional third party volume plugins (default "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/")
--volume-stats-agg-period duration
Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes. To disable volume calculations, set to 0. (default 1m0s) (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-open-files int
Number of files that can be opened by Kubelet process. (default 1000000) (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
Number of Pods that can run on this Kubelet. (default 110) (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
Maximum number of old instances of containers to retain globally. Each container takes up some disk space. To disable, set to a negative number. (default -1) (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--maximum-dead-containers-per-container int32
Maximum number of old instances to retain per container. Each container takes up some disk space. (default 1) (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--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-image-ttl-duration duration
Minimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. (default 2m0s) (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.
--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.
--node-ip string
IP address of the node. If set, kubelet will use this IP address for the node
--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, failure-domain.kubernetes.io/region, failure-domain.kubernetes.io/zone, kubernetes.io/arch, kubernetes.io/hostname, kubernetes.io/instance-type, kubernetes.io/os)
--node-status-max-images int32
<Warning: Alpha feature> The maximum number of images to report in Node.Status.Images. If -1 is specified, no cap will be applied. (default 50)
--node-status-update-frequency duration
Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in nodecontroller. (default 10s) (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
Traffic to IPs outside this range will use IP masquerade. Set to '0.0.0.0/0' to never masquerade. (default "10.0.0.0/8") (DEPRECATED: will be removed in a future version)
--oom-score-adj int32
The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000] (default -999) (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.)
--pod-infra-container-image string
The image whose network/ipc namespaces containers in each pod will use. This docker-specific flag only works when container-runtime is set to docker. (default "k8s.gcr.io/pause:3.2")
--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.)
--pod-max-pids int
Set the maximum number of processes per pod. If -1, the kubelet defaults to the node allocatable pid capacity. (default -1) (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.)
--port int32
The port for the Kubelet to serve on. (default 10250) (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.)
--provider-id string
Unique identifier for identifying the node in a machine database, i.e cloudprovider
--qos-reserved mapStringString
<Warning: Alpha feature> A set of ResourceName=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
The read-only port for the Kubelet to serve on with no authentication/authorization (set to 0 to disable) (default 10255) (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.)
--really-crash-for-testing
If true, when panics occur crash. Intended for testing.
--redirect-container-streaming
Enables container streaming redirect. If false, kubelet will proxy container streaming data between apiserver and container runtime; if true, kubelet will return an http redirect to apiserver, and apiserver 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.
--register-node
Register the node with the apiserver. If --kubeconfig is not provided, this flag is irrelevant, as the Kubelet won't have an apiserver to register with. Default=true. (default true)
--register-schedulable
Register the node as schedulable. Won't have any effect if register-node is false. (default true) (DEPRECATED: will be removed in a future version)
--register-with-taints []api.Taint
Register the node with the given list of taints (comma separated "=:"). No-op if register-node is false.
--registry-burst int32
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 (default 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.)
--registry-qps int32
If > 0, limit registry pull QPS to this value. If 0, unlimited. (default 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.)
--resolv-conf string
Resolver configuration file used as the basis for the container DNS resolution configuration. (default "/etc/resolv.conf") (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
Directory path for managing kubelet files (volume mounts,etc). (default "/var/lib/kubelet")
--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.)
--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.)
--runonce
If true, exit after spawning pods from local manifests or remote urls. Exclusive with --enable-server
--runtime-cgroups string
Optional absolute name of cgroups to create and run the runtime in.
--runtime-request-timeout duration
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. (default 2m0s) (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
<Warning: Alpha feature> Directory path for seccomp profiles. (default "/var/lib/kubelet/seccomp")
--serialize-image-pulls
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. (default true) (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 messages
--skip-log-headers
If true, avoid headers when opening log files
--stderrthreshold severity
logs at or above this threshold go to stderr (default 2)
--storage-driver-buffer-duration duration
Writes in the storage driver will be buffered for this duration, and committed to the non memory backends as a single transaction (default 1m0s) (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-db string
database name (default "cadvisor") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-host string
database host:port (default "localhost:8086") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-password string
database password (default "root") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-secure
use secure connection with database (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-table string
table name (default "stats") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--storage-driver-user string
database username (default "root") (DEPRECATED: This is a cadvisor flag that was mistakenly registered with the Kubelet. Due to legacy concerns, it will follow the standard CLI deprecation timeline before being removed.)
--streaming-connection-idle-timeout duration
Maximum time a streaming connection can be idle before the connection is automatically closed. 0 indicates no timeout. Example: '5m' (default 4h0m0s) (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
Max period between synchronizing running containers and config (default 1m0s) (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 /
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
A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi) 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. [default=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.)
--system-reserved-cgroup string
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'. [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.)
--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.)
--tls-cipher-suites stringSlice
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used. Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,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_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,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_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,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.)
--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.)
--topology-manager-policy string
Topology Manager policy to use. Possible values: 'none', 'best-effort', 'restricted', 'single-numa-node'. (default "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.)
-v, --v Level
number for the log level verbosity
--version version[=true]
Print version information and quit
--vmodule moduleSpec
comma-separated list of pattern=N settings for file-filtered logging
--volume-plugin-dir string
<Warning: Alpha feature> The full path of the directory in which to search for additional third party volume plugins (default "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/")
--volume-stats-agg-period duration
Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes. To disable volume calculations, set to 0. (default 1m0s) (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.)
{{% /capture %}} diff --git a/content/en/docs/reference/glossary/node.md b/content/en/docs/reference/glossary/node.md index a67ecf488d..fd09ec75b4 100755 --- a/content/en/docs/reference/glossary/node.md +++ b/content/en/docs/reference/glossary/node.md @@ -15,3 +15,5 @@ tags: A worker node may be a VM or physical machine, depending on the cluster. It has local daemons or services necessary to run {{< glossary_tooltip text="Pods" term_id="pod" >}} and is managed by the control plane. The daemons on a node include {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}, and a container runtime implementing the {{< glossary_tooltip text="CRI" term_id="cri" >}} such as {{< glossary_tooltip term_id="docker" >}}. + +In early Kubernetes versions, Nodes were called “Minions”. diff --git a/content/en/docs/reference/glossary/taint.md b/content/en/docs/reference/glossary/taint.md index c1aaaf5f65..50ba2d087e 100644 --- a/content/en/docs/reference/glossary/taint.md +++ b/content/en/docs/reference/glossary/taint.md @@ -2,7 +2,7 @@ title: Taint id: taint date: 2019-01-11 -full_link: /docs/concepts/configuration/taint-and-toleration/ +full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/ short_description: > A core object consisting of three required properties: key, value, and effect. Taints prevent the scheduling of pods on nodes or node groups. diff --git a/content/en/docs/reference/glossary/toleration.md b/content/en/docs/reference/glossary/toleration.md index e6264224e9..fb2f2e6d78 100644 --- a/content/en/docs/reference/glossary/toleration.md +++ b/content/en/docs/reference/glossary/toleration.md @@ -2,7 +2,7 @@ title: Toleration id: toleration date: 2019-01-11 -full_link: /docs/concepts/configuration/taint-and-toleration/ +full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/ short_description: > A core object consisting of three required properties: key, value, and effect. Tolerations enable the scheduling of pods on nodes or node groups that have a matching taint. diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md index 1bb82cf962..fa8633fb5f 100644 --- a/content/en/docs/reference/kubectl/overview.md +++ b/content/en/docs/reference/kubectl/overview.md @@ -69,31 +69,49 @@ The following table includes short descriptions and the general syntax for all o Operation | Syntax | Description -------------------- | -------------------- | -------------------- +`alpha` | `kubectl alpha SUBCOMMAND [flags]` | List the available commands that correspond to alpha features, which are not enabled in Kubernetes clusters by default. `annotate` | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | Add or update the annotations of one or more resources. +`api-resources` | `kubectl api-resources [flags]` | List the API resources that are available. `api-versions` | `kubectl api-versions [flags]` | List the API versions that are available. `apply` | `kubectl apply -f FILENAME [flags]`| Apply a configuration change to a resource from a file or stdin. `attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | Attach to a running container either to view the output stream or interact with the container (stdin). +`auth` | `kubectl auth [flags] [options]` | Inspect authorization. `autoscale` | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | Automatically scale the set of pods that are managed by a replication controller. +`certificate` | `kubectl certificate SUBCOMMAND [options]` | Modify certificate resources. `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. +`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. `delete` | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources. `describe` | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | Display the detailed state of one or more resources. `diff` | `kubectl diff -f FILENAME [flags]`| Diff file or stdin against live configuration. +`drain` | `kubectl drain NODE [options]` | Drain node in preparation for maintenance. `edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | Edit and update the definition of one or more resources on the server by using the default editor. `exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Execute a command against a container in a pod. `explain` | `kubectl explain [--recursive=false] [flags]` | Get documentation of various resources. For instance pods, nodes, services, etc. `expose` | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | Expose a replication controller, service, or pod as a new Kubernetes service. `get` | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | List one or more resources. +`kustomize` | `kubectl kustomize [flags] [options]` | List a set of API resources generated from instructions in a kustomization.yaml file. The argument must be the path to the directory containing the file, or a git repository URL with a path suffix specifying same with respect to the repository root. `label` | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | Add or update the labels of one or more resources. `logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod. +`options` | `kubectl options` | List of global command-line options, which apply to all commands. `patch` | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | Update one or more fields of a resource by using the strategic merge patch process. +`plugin` | `kubectl plugin [flags] [options]` | Provides utilities for interacting with plugins. `port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | Forward one or more local ports to a pod. `proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Run a proxy to the Kubernetes API server. `replace` | `kubectl replace -f FILENAME` | Replace a resource from a file or stdin. -`run` | `kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=server|client|none] [--overrides=inline-json] [flags]` | Run a specified image on the cluster. +`rollout` | `kubectl rollout SUBCOMMAND [options]` | Manage the rollout of a resource. Valid resource types include: deployments, daemonsets and statefulsets. +`run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | Run a specified image on the cluster. `scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | Update the size of the specified replication controller. +`set` | `kubectl set SUBCOMMAND [options]` | Configure application resources. +`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | Update the taints on one or more nodes. +`top` | `kubectl top [flags] [options]` | Display Resource (CPU/Memory/Storage) usage. +`uncordon` | `kubectl uncordon NODE [options]` | Mark node as schedulable. `version` | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server. +`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | Experimental: Wait for a specific condition on one or many resources. Remember: For more about command operations, see the [kubectl](/docs/user-guide/kubectl/) reference documentation. @@ -243,8 +261,8 @@ kubectl get pods --server-print=false Output looks like this: ```shell -NAME READY STATUS RESTARTS AGE -pod-name 1/1 Running 0 1m +NAME AGE +pod-name 1m ``` ### Sorting list objects @@ -339,8 +357,8 @@ the pods running on it, the events generated for the node etc. # Delete a pod using the type and name specified in the pod.yaml file. kubectl delete -f pod.yaml -# Delete all the pods and services that have the label name=. -kubectl delete pods,services -l name= +# Delete all the pods and services that have the label '='. +kubectl delete pods,services -l = # Delete all pods, including uninitialized ones. kubectl delete pods --all @@ -350,13 +368,13 @@ kubectl delete pods --all ```shell # Get output from running 'date' from pod . By default, output is from the first container. -kubectl exec date +kubectl exec -- date # Get output from running 'date' in container of pod . -kubectl exec -c date +kubectl exec -c -- date # Get an interactive TTY and run /bin/bash from pod . By default, output is from the first container. -kubectl exec -ti /bin/bash +kubectl exec -ti -- /bin/bash ``` `kubectl logs` - Print the logs for a container in a pod. @@ -451,7 +469,7 @@ cat ./kubectl-whoami # this plugin makes use of the `kubectl config` command in order to output # information about the current user, based on the currently selected context -kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ .context.user }}{{ end }}{{ end }}' +kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}' ``` Running the above plugin gives us an output containing the user for the currently selected diff --git a/content/en/docs/reference/scheduling/policies.md b/content/en/docs/reference/scheduling/policies.md index 53e5981dea..0bf6e030b0 100644 --- a/content/en/docs/reference/scheduling/policies.md +++ b/content/en/docs/reference/scheduling/policies.md @@ -77,7 +77,7 @@ The following *priorities* implement scoring: {{< glossary_tooltip term_id="replica-set" >}}. - `InterPodAffinityPriority`: Implements preferred - [inter pod affininity and antiaffinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity). + [inter pod affininity and antiaffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity). - `LeastRequestedPriority`: Favors nodes with fewer requested resources. In other words, the more Pods that are placed on a Node, and the more resources those @@ -97,7 +97,7 @@ The following *priorities* implement scoring: - `NodeAffinityPriority`: Prioritizes nodes according to node affinity scheduling preferences indicated in PreferredDuringSchedulingIgnoredDuringExecution. - You can read more about this in [Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/). + You can read more about this in [Assigning Pods to Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/). - `TaintTolerationPriority`: Prepares the priority list for all the nodes, based on the number of intolerable taints on the node. This policy adjusts a node's rank diff --git a/content/en/docs/reference/scheduling/profiles.md b/content/en/docs/reference/scheduling/profiles.md index b8ab40c3fe..48fa961b2e 100644 --- a/content/en/docs/reference/scheduling/profiles.md +++ b/content/en/docs/reference/scheduling/profiles.md @@ -68,7 +68,7 @@ extension points: Pod runs. Extension points: `Score`. - `TaintToleration`: Implements - [taints and tolerations](/docs/concepts/configuration/taint-and-toleration/). + [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`. @@ -79,8 +79,8 @@ extension points: `scheduler.alpha.kubernetes.io/preferAvoidPods`. Extension points: `Score`. - `NodeAffinity`: Implements - [node selectors](/docs/concepts/configuration/assign-pod-node/#nodeselector) - and [node affinity](/docs/concepts/configuration/assign-pod-node/#node-affinity). + [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/). @@ -117,7 +117,7 @@ extension points: the node. Extension points: `Filter`. - `InterPodAffinity`: Implements - [inter-Pod affinity and anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity). + [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`. 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 e368a56847..a0aa304217 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -81,12 +81,12 @@ The user can skip specific preflight checks or all of them with the `--ignore-pr - [warning] If the Kubernetes version to use (specified with the `--kubernetes-version` flag) is at least one minor version higher than the kubeadm CLI version. - Kubernetes system requirements: - if running on linux: - - [error] if not Kernel 3.10+ or 4+ with specific KernelSpec + - [error] if Kernel is older than the minimum required version - [error] if required cgroups subsystem aren't in set up - if using docker: - [warning/error] if Docker service does not exist, if it is disabled, if it is not active. - [error] if Docker endpoint does not exist or does not work - - [warning] if docker version >17.03 + - [warning] if docker version is not in the list of validated docker versions - If using other cri engine: - [error] if crictl socket does not answer - [error] if user is not root @@ -108,7 +108,7 @@ The user can skip specific preflight checks or all of them with the `--ignore-pr - [warning] if connection to services subnet goes through proxy (only first address checked) - [warning] if connection to Pods subnet goes through proxy (only first address checked) - If external etcd is provided: - - [Error] if etcd version less than 3.0.14 + - [Error] if etcd version is older than the minimum required version - [Error] if etcd certificates or keys are specified, but not provided - If external etcd is NOT provided (and thus local etcd will be installed): - [Error] if ports 2379 is used @@ -325,7 +325,8 @@ 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 and alpha in v1.9) Write base kubelet configuration +### (optional) Write base kubelet configuration +{{< feature-state for_k8s_version="v1.9" state="alpha" >}} If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: @@ -516,7 +517,8 @@ Please note that: 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 and alpha in v1.9) Write init kubelet configuration +### (optional) Write init kubelet configuration +{{< feature-state for_k8s_version="v1.9" state="alpha" >}} If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index 4d06194a59..956c31323d 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -109,6 +109,7 @@ To mitigate the impact of short history window, we introduced a concept of `book `Bookmark` events can be requested by `allowWatchBookmarks=true` option in watch requests, but clients shouldn't assume bookmarks are returned at any specific interval, nor may they assume the server will send any `bookmark` event. ## Retrieving large results sets in chunks +{{< feature-state for_k8s_version="v1.9" state="beta" >}} On large clusters, retrieving the collection of some resource types may result in very large responses that can impact the server and client. For instance, a cluster may have tens of thousands of pods, each of which is 1-2kb of encoded JSON. Retrieving all pods across all namespaces may result in a very large response (10-20MB) and consume a large amount of server resources. Starting in Kubernetes 1.9 the server supports the ability to break a single large collection request into many smaller chunks while preserving the consistency of the total request. Each chunk can be returned sequentially which reduces both the total size of the request and allows user-oriented clients to display results incrementally to improve responsiveness. diff --git a/content/en/docs/setup/learning-environment/minikube.md b/content/en/docs/setup/learning-environment/minikube.md index ed9578452a..e314d56608 100644 --- a/content/en/docs/setup/learning-environment/minikube.md +++ b/content/en/docs/setup/learning-environment/minikube.md @@ -37,116 +37,151 @@ See [Installing Minikube](/docs/tasks/tools/install-minikube/). This brief demo guides you on how to start, use, and delete Minikube locally. Follow the steps given below to start and explore Minikube. 1. Start Minikube and create a cluster: - ```shell - minikube start - ``` - The output is similar to this: - ``` - Starting local Kubernetes cluster... - Running pre-create checks... - Creating machine... - Starting local Kubernetes cluster... - ``` - For more information on starting your cluster on a specific Kubernetes version, VM, or container runtime, see [Starting a Cluster](#starting-a-cluster). + ```shell + minikube start + ``` + + The output is similar to this: + + ``` + Starting local Kubernetes cluster... + Running pre-create checks... + Creating machine... + Starting local Kubernetes cluster... + ``` + + For more information on starting your cluster on a specific Kubernetes version, VM, or container runtime, see [Starting a Cluster](#starting-a-cluster). 2. Now, you can interact with your cluster using kubectl. For more information, see [Interacting with Your Cluster](#interacting-with-your-cluster). - Let’s create a Kubernetes Deployment using an existing image named `echoserver`, which is a simple HTTP server and expose it on port 8080 using `--port`. - ```shell - kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 - ``` - The output is similar to this: - ``` - deployment.apps/hello-minikube created - ``` -3. To access the `hello-minikube` Deployment, expose it as a Service: - ```shell - kubectl expose deployment hello-minikube --type=NodePort --port=8080 - ``` - The option `--type=NodePort` specifies the type of the Service. + Let’s create a Kubernetes Deployment using an existing image named `echoserver`, which is a simple HTTP server and expose it on port 8080 using `--port`. + + ```shell + kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 + ``` + + The output is similar to this: + + ``` + deployment.apps/hello-minikube created + ``` +3. To access the `hello-minikube` Deployment, expose it as a Service: + + ```shell + kubectl expose deployment hello-minikube --type=NodePort --port=8080 + ``` + + The option `--type=NodePort` specifies the type of the Service. + + The output is similar to this: + + ``` + service/hello-minikube exposed + ``` - The output is similar to this: - ``` - service/hello-minikube exposed - ``` 4. The `hello-minikube` Pod is now launched but you have to wait until the Pod is up before accessing it via the exposed Service. - Check if the Pod is up and running: - ```shell - kubectl get pod - ``` - If the output shows the `STATUS` as `ContainerCreating`, the Pod is still being created: - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s - ``` - If the output shows the `STATUS` as `Running`, the Pod is now up and running: - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 1/1 Running 0 13s - ``` + Check if the Pod is up and running: + + ```shell + kubectl get pod + ``` + + If the output shows the `STATUS` as `ContainerCreating`, the Pod is still being created: + + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s + ``` + + If the output shows the `STATUS` as `Running`, the Pod is now up and running: + + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 1/1 Running 0 13s + ``` + 5. Get the URL of the exposed Service to view the Service details: - ```shell - minikube service hello-minikube --url - ``` + + ```shell + minikube service hello-minikube --url + ``` + 6. To view the details of your local cluster, copy and paste the URL you got as the output, on your browser. - The output is similar to this: - ``` - Hostname: hello-minikube-7c77b68cff-8wdzq + The output is similar to this: - Pod Information: - -no pod information available- + ``` + Hostname: hello-minikube-7c77b68cff-8wdzq - Server values: - server_version=nginx: 1.13.3 - lua: 10008 + Pod Information: + -no pod information available- - 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/ + Server values: + server_version=nginx: 1.13.3 - lua: 10008 - Request Headers: + 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: + Request Body: -no body in request- - ``` - If you no longer want the Service and cluster to run, you can delete them. + ``` + + If you no longer want the Service and cluster to run, you can delete them. + 7. Delete the `hello-minikube` Service: - ```shell - kubectl delete services hello-minikube - ``` - The output is similar to this: - ``` - service "hello-minikube" deleted - ``` + + ```shell + kubectl delete services hello-minikube + ``` + + The output is similar to this: + + ``` + service "hello-minikube" deleted + ``` + 8. Delete the `hello-minikube` Deployment: - ```shell - kubectl delete deployment hello-minikube - ``` - The output is similar to this: - ``` - deployment.extensions "hello-minikube" deleted - ``` + + ```shell + kubectl delete deployment hello-minikube + ``` + + The output is similar to this: + + ``` + deployment.extensions "hello-minikube" deleted + ``` + 9. Stop the local Minikube cluster: - ```shell - minikube stop - ``` - The output is similar to this: - ``` - Stopping "minikube"... - "minikube" stopped. - ``` - For more information, see [Stopping a Cluster](#stopping-a-cluster). + + ```shell + minikube stop + ``` + + The output is similar to this: + + ``` + Stopping "minikube"... + "minikube" stopped. + ``` + + For more information, see [Stopping a Cluster](#stopping-a-cluster). + 10. Delete the local Minikube cluster: + ```shell minikube delete ``` @@ -192,15 +227,16 @@ For example the command would be. ```shell minikube start --driver= ``` - Minikube supports the following drivers: - {{< note >}} - See [DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/) for details on supported drivers and how to install +Minikube supports the following drivers: +{{< note >}} +See [DRIVERS](https://minikube.sigs.k8s.io/docs/reference/drivers/) for details on supported drivers and how to install plugins. {{< /note >}} -* virtualbox +* docker ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/docker/)) +* virtualbox ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/)) +* podman ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/podman/)) (EXPERIMENTAL) * vmwarefusion -* docker ([driver installation](https://minikube.sigs.k8s.io/docs/drivers/docker/) * kvm2 ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/)) * hyperkit ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/)) * hyperv ([driver installation](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/)) diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index cccf422587..7db25e022b 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -21,8 +21,8 @@ A flaw was found in the way runc handled system file descriptors when running co A malicious container could use this flaw to overwrite contents of the runc binary and consequently run arbitrary commands on the container host system. -Please refer to this link for more information about this issue -[cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736) +Please refer to [CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736) for more +information about the issue. {{< /caution >}} ### Applicability @@ -70,29 +70,39 @@ Keep track of the latest verified Docker version in the Kubernetes release notes Use the following commands to install Docker on your system: {{< tabs name="tab-cri-docker-installation" >}} -{{< tab name="Ubuntu 16.04+" codelang="bash" >}} -# Install Docker CE +{{< tab name="Ubuntu 16.04+" >}} + +```shell +# (Install Docker CE) ## Set up the repository: ### Install packages to allow apt to use a repository over HTTPS apt-get update && apt-get install -y \ apt-transport-https ca-certificates curl software-properties-common gnupg2 +``` -### Add Docker’s official GPG key +```shell +# Add Docker’s official GPG key: curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` -### Add Docker apt repository. +```shell +# Add the Docker apt repository: add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` -## Install Docker CE. +```shell +# Install Docker CE apt-get update && apt-get install -y \ containerd.io=1.2.13-1 \ docker-ce=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) \ docker-ce-cli=5:19.03.8~3-0~ubuntu-$(lsb_release -cs) +``` -# Setup daemon. +```shell +# Set up the Docker daemon cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{< tab name="CentOS/RHEL 7.4+" >}} -# Install Docker CE +```shell +# (Install Docker CE) ## Set up the repository -### Install required packages. +### Install required packages yum install -y yum-utils device-mapper-persistent-data lvm2 +``` -### Add Docker repository. +```shell +## Add the Docker repository yum-config-manager --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +``` -## Install Docker CE. +```shell +# Install Docker CE yum update -y && yum install -y \ containerd.io-1.2.13 \ docker-ce-19.03.8 \ docker-ce-cli-19.03.8 +``` -## Create /etc/docker directory. +```shell +## Create /etc/docker mkdir /etc/docker +``` -# Setup daemon. +```shell +# Set up the Docker daemon cat > /etc/docker/daemon.json < /etc/docker/daemon.json <}} {{< /tabs >}} @@ -173,7 +202,7 @@ For more information, see the [CRI-O compatiblity matrix](https://github.com/cri modprobe overlay modprobe br_netfilter -# Setup required sysctl params, these persist across reboots. +# Set up required sysctl params, these persist across reboots. cat > /etc/sysctl.d/99-kubernetes-cri.conf <}} -{{< tab name="Debian" codelang="bash" >}} +{{< tab name="Debian" >}} + +```shell # Debian Unstable/Sid echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Unstable/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Unstable/Release.key -O- | sudo apt-key add - +``` +```shell # Debian Testing echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_Testing/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_Testing/Release.key -O- | sudo apt-key add - +``` +```shell # Debian 10 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Debian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Debian_10/Release.key -O- | sudo apt-key add - +``` +```shell # Raspbian 10 echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/Raspbian_10/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/Raspbian_10/Release.key -O- | sudo apt-key add - +``` -# Install CRI-O +and then install CRI-O: +```shell sudo apt-get install cri-o-1.17 +``` {{< /tab >}} -{{< tab name="Ubuntu 18.04, 19.04 and 19.10" codelang="bash" >}} -# Setup repository +{{< tab name="Ubuntu 18.04, 19.04 and 19.10" >}} + +```shell +# Configure package repository . /etc/os-release sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/x${NAME}_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/x${NAME}_${VERSION_ID}/Release.key -O- | sudo apt-key add - sudo apt-get update +``` +```shell # Install CRI-O sudo apt-get install cri-o-1.17 +``` {{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} +{{< tab name="CentOS/RHEL 7.4+" >}} + +```shell # Install prerequisites -yum-config-manager --add-repo=https://cbs.centos.org/repos/paas7-crio-115-release/x86_64/os/ +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_7/devel:kubic:libcontainers:stable.repo +curl -L -o /etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}/CentOS_7/devel:kubic:libcontainers:stable:cri-o:{{< skew latestVersion >}}.repo +``` +```shell # Install CRI-O -yum install --nogpgcheck -y cri-o +yum install -y cri-o +``` {{< /tab >}} -{{< tab name="openSUSE Tumbleweed" codelang="bash" >}} +{{< tab name="openSUSE Tumbleweed" >}} + +```shell sudo zypper install cri-o +``` {{< /tab >}} {{< /tabs >}} ### Start CRI-O -``` +```shell systemctl daemon-reload systemctl start crio ``` @@ -269,51 +323,72 @@ sysctl --system ### Install containerd {{< tabs name="tab-cri-containerd-installation" >}} -{{< tab name="Ubuntu 16.04" codelang="bash" >}} -# Install containerd +{{< tab name="Ubuntu 16.04" >}} + +```shell +# (Install containerd) ## Set up the repository ### Install packages to allow apt to use a repository over HTTPS apt-get update && apt-get install -y apt-transport-https ca-certificates curl software-properties-common +``` -### Add Docker’s official GPG key +```shell +## Add Docker’s official GPG key curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - +``` -### Add Docker apt repository. +```shell +## Add Docker apt repository. add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) \ stable" +``` +```shell ## Install containerd apt-get update && apt-get install -y containerd.io +``` +```shell # Configure containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` +```shell # Restart containerd systemctl restart containerd +``` {{< /tab >}} -{{< tab name="CentOS/RHEL 7.4+" codelang="bash" >}} -# Install containerd +{{< tab name="CentOS/RHEL 7.4+" >}} + +```shell +# (Install containerd) ## Set up the repository ### Install required packages yum install -y yum-utils device-mapper-persistent-data lvm2 -### Add docker repository +```shell +## Add docker repository yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo +```shell ## Install containerd yum update -y && yum install -y containerd.io -# Configure containerd +```shell +## Configure containerd mkdir -p /etc/containerd containerd config default > /etc/containerd/config.toml +``` +```shell # Restart containerd systemctl restart containerd +``` {{< /tab >}} {{< /tabs >}} 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 4a0d567f00..2d38666386 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 @@ -303,10 +303,10 @@ Below you can find installation instructions for some popular Pod network plugin {{% tab name="Calico" %}} [Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. Calico works on several architectures, including `amd64`, `arm64`, and `ppc64le`. -By default, Calico uses `192.168.0.0/16` as the Pod network CIDR, though this can be configured in the calico.yaml file. For Calico to work correctly, you need to pass this same CIDR to the `kubeadm init` command using the `--pod-network-cidr=192.168.0.0/16` flag or via kubeadm's configuration. +Calico will automatically detect which IP address range to use for pod IPs based on the value provided via the `--pod-network-cidr` flag or via kubeadm's configuration. ```shell -kubectl apply -f https://docs.projectcalico.org/v3.11/manifests/calico.yaml +kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml ``` {{% /tab %}} 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 c93186b28d..9d67fa8e53 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 @@ -122,8 +122,8 @@ option. Your cluster requirements may need a different configuration. {{< /note >}} {{< note >}} - Some CNI network plugins like Calico require a CIDR such as `192.168.0.0/16` and - some like Weave do not. See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network). + Some CNI network plugins require additional configuration, for example specifying the pod IP CIDR, while others do not. + See the [CNI network documentation](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network). To add a pod CIDR pass the flag `--pod-network-cidr`, or if you are using a kubeadm configuration file set the `podSubnet` field under the `networking` object of `ClusterConfiguration`. {{< /note >}} 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 b44275302a..9438e86140 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 @@ -28,7 +28,7 @@ For information how to create a cluster with kubeadm once you have performed thi * 2 GB or more of RAM per machine (any less will leave little room for your apps) * 2 CPUs or more * Full network connectivity between all machines in the cluster (public or private network is fine) -* Unique hostname, MAC address, and product_uuid for every node. See [here](#verify-the-mac-address-and-product-uuid-are-unique-for-every-node) for more details. +* Unique hostname, MAC address, and product_uuid for every node. See [here](#verify-mac-address) for more details. * Certain ports are open on your machines. See [here](#check-required-ports) for more details. * Swap disabled. You **MUST** disable swap in order for the kubelet to work properly. @@ -36,7 +36,7 @@ For information how to create a cluster with kubeadm once you have performed thi {{% capture steps %}} -## Verify the MAC address and product_uuid are unique for every node +## Verify the MAC address and product_uuid are unique for every node {#verify-mac-address} * You can get the MAC address of the network interfaces using the command `ip link` or `ifconfig -a` * The product_uuid can be checked by using the command `sudo cat /sys/class/dmi/id/product_uuid` @@ -210,12 +210,14 @@ yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes systemctl enable --now kubelet ``` - **Note:** + **Notes:** - Setting SELinux in permissive mode by running `setenforce 0` and `sed ...` effectively disables it. This is required to allow containers to access the host filesystem, which is needed by pod networks for example. You have to do this until SELinux support is improved in the kubelet. + - You can leave SELinux enabled if you know how to configure it but it may require settings that are not supported by kubeadm. + {{% /tab %}} {{% tab name="Container Linux" %}} Install CNI plugins (required for most pod network): @@ -303,4 +305,4 @@ If you are running into difficulties with kubeadm, please consult our [troublesh * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md index 641d349440..070dbd7274 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -15,15 +15,15 @@ The lifecycle of the kubeadm CLI tool is decoupled from the on each node within the Kubernetes cluster. The kubeadm CLI tool is executed by the user when Kubernetes is initialized or upgraded, whereas the kubelet is always running in the background. -Since the kubelet is a daemon, it needs to be maintained by some kind of a init +Since the kubelet is a daemon, it needs to be maintained by some kind of an init system or service manager. When the kubelet is installed using DEBs or RPMs, systemd is configured to manage the kubelet. You can use a different service manager instead, but you need to configure it manually. Some kubelet configuration details need to be the same across all kubelets involved in the cluster, while -other configuration aspects need to be set on a per-kubelet basis, to accommodate the different -characteristics of a given machine, such as OS, storage, and networking. You can manage the configuration -of your kubelets manually, but [kubeadm now provides a `KubeletConfiguration` API type for managing your +other configuration aspects need to be set on a per-kubelet basis to accommodate the different +characteristics of a given machine (such as OS, storage, and networking). You can manage the configuration +of your kubelets manually, but kubeadm now provides a `KubeletConfiguration` API type for [managing your kubelet configurations centrally](#configure-kubelets-using-kubeadm). {{% /capture %}} @@ -67,7 +67,7 @@ For more details on the ComponentConfig have a look at [this section](#configure ### Providing instance-specific configuration details -Some hosts require specific kubelet configurations, due to differences in hardware, operating system, +Some hosts require specific kubelet configurations due to differences in hardware, operating system, networking, or other host-specific parameters. The following list provides a few examples. - The path to the DNS resolution file, as specified by the `--resolv-conf` kubelet @@ -79,7 +79,7 @@ networking, or other host-specific parameters. The following list provides a few unless you are using a cloud provider. You can use the `--hostname-override` flag to override the default behavior if you need to specify a Node name different from the machine's hostname. -- Currently, the kubelet cannot automatically detects the cgroup driver used by the CRI runtime, +- Currently, the kubelet cannot automatically detect the cgroup driver used by the CRI runtime, but the value of `--cgroup-driver` must match the cgroup driver used by the CRI runtime to ensure the health of the kubelet. @@ -107,7 +107,7 @@ for more information on the individual fields. When you call `kubeadm init`, the kubelet configuration is marshalled to disk at `/var/lib/kubelet/config.yaml`, and also uploaded to a ConfigMap in the cluster. The ConfigMap -is named `kubelet-config-1.X`, where `.X` is the minor version of the Kubernetes version you are +is named `kubelet-config-1.X`, where `X` is the minor version of the Kubernetes version you are initializing. A kubelet configuration file is also written to `/etc/kubernetes/kubelet.conf` with the baseline cluster-wide configuration for all kubelets in the cluster. This configuration file points to the client certificates that allow the kubelet to communicate with the API server. This @@ -157,12 +157,12 @@ has finished performing the TLS Bootstrap. ## The kubelet drop-in file for systemd -kubeadm ships with configuration for how systemd should run the kubelet. +`kubeadm` ships with configuration for how systemd should run the kubelet. Note that the kubeadm CLI command never touches this drop-in file. -This configuration file installed by the `kubeadm` [DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/10-kubeadm.conf) or [RPM package](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/10-kubeadm.conf) is written to +This configuration file installed by the `kubeadm` [DEB](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubeadm/10-kubeadm.conf) or [RPM package](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubeadm/10-kubeadm.conf) is written to `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` and is used by systemd. -It augments the basic [`kubelet.service` for RPM](https://github.com/kubernetes/kubernetes/blob/master/build/rpms/kubelet.service) (resp. [`kubelet.service` for DEB](https://github.com/kubernetes/kubernetes/blob/master/build/debs/kubelet.service))): +It augments the basic [`kubelet.service` for RPM](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service) or [`kubelet.service` for DEB](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service): ```none [Service] 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 a7ef208052..054f4b28fb 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 @@ -356,7 +356,7 @@ the field will be omitted when marshalling. When the field is omitted, kubeadm a 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/configuration/taint-and-toleration/), unless other nodes have capacity. +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 diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index 996f588dc7..ae323d38cf 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -21,7 +21,7 @@ Kubespray is a composition of [Ansible](http://docs.ansible.com/) playbooks, [in * openSUSE Leap 15 * continuous integration tests -To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](../kops). +To choose a tool which best fits your use case, read [this comparison](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md) to [kubeadm](/docs/admin/kubeadm/) and [kops](/docs/setup/production-environment/tools/kops/). {{% /capture %}} @@ -119,4 +119,4 @@ When running the reset playbook, be sure not to accidentally target your product Check out planned work on Kubespray's [roadmap](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md). -{{% /capture %}} +{{% /capture %}} \ No newline at end of file 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 e8e23b8574..78e61d4588 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 @@ -263,7 +263,7 @@ As a result, the following storage functionality is not supported on Windows nod 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 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 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 a79cc80b59..aa1c1f3783 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 @@ -70,7 +70,7 @@ spec: - -command - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows ``` {{< note >}} diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster.md b/content/en/docs/tasks/access-application-cluster/access-cluster.md index bd0de435e4..05835f2b08 100644 --- a/content/en/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/access-cluster.md @@ -277,7 +277,7 @@ This shows the proxy-verb URL for accessing each service. For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed. Logging can also be reached through a kubectl proxy, for example at: `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`. -(See [above](#accessing-the-cluster-api) for how to pass credentials or use kubectl proxy.) +(See [Access Clusters Using the Kubernetes API](/docs/tasks/administer-cluster/access-cluster-api/) for how to pass credentials or use kubectl proxy.) #### Manually constructing apiserver proxy URLs @@ -376,4 +376,4 @@ There are several different proxies you may encounter when using Kubernetes: Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin will typically ensure that the latter types are setup correctly. -{{% /capture %}} +{{% /capture %}} \ No newline at end of file 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 4cccac0f58..acd023548a 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 @@ -346,7 +346,7 @@ export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config ``` ### Windows Powershell ```shell -$Env:KUBECONFIG=($Env:KUBECONFIG;$HOME/.kube/config) +$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" ``` View configuration information merged from all the files that are now listed diff --git a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md index 123271be44..264d930d5f 100644 --- a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -203,6 +203,17 @@ The output shows the message generated by the backend: {{% /capture %}} +{{% capture cleanup %}} + +To delete the Services, enter this command: + + kubectl delete services frontend hello + +To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command: + + kubectl delete deployment frontend hello + +{{% /capture %}} {{% capture whatsnext %}} 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 c07155a259..0a16c71064 100644 --- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md +++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md @@ -66,7 +66,7 @@ This page shows you how to set up a simple Ingress which routes requests to Serv 1. Create a Deployment using the following command: ```shell - kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0 --port=8080 + kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0 ``` Output: @@ -203,7 +203,7 @@ The following file is an Ingress resource that sends traffic to your Service via 1. Create a v2 Deployment using the following command: ```shell - kubectl run web2 --image=gcr.io/google-samples/hello-app:2.0 --port=8080 + kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0 ``` Output: @@ -214,7 +214,7 @@ The following file is an Ingress resource that sends traffic to your Service via 1. Expose the Deployment: ```shell - kubectl expose deployment web2 --target-port=8080 --type=NodePort + kubectl expose deployment web2 --port=8080 --type=NodePort ``` Output: @@ -228,7 +228,7 @@ The following file is an Ingress resource that sends traffic to your Service via 1. Edit the existing `example-ingress.yaml` and add the following lines: ```yaml - - path: /v2/* + - path: /v2 backend: serviceName: web2 servicePort: 8080 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 b62438a8a1..0069334214 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 @@ -97,7 +97,7 @@ If needed, you can expand the **Advanced options** section where you can specify Example: - ```conf +```conf release=1.0 tier=frontend environment=pod diff --git a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md index ddcf7d4875..4fcd389ba2 100644 --- a/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md @@ -28,6 +28,7 @@ into the Kubernetes API by creating a {{% /capture %}} {{% capture steps %}} + ## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server @@ -41,6 +42,7 @@ For example, if you save the following CustomResourceDefinition to `resourcedefi {{< tabs name="CustomResourceDefinition_example_1" >}} {{% tab name="apiextensions.k8s.io/v1" %}} + ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -83,8 +85,10 @@ spec: shortNames: - ct ``` + {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 @@ -129,6 +133,7 @@ spec: replicas: type: integer ``` + {{% /tab %}} {{< /tabs >}} @@ -188,7 +193,7 @@ kubectl get crontab Should print a list like this: -```console +```none NAME AGE my-new-cron-object 6s ``` @@ -205,7 +210,7 @@ kubectl get ct -o yaml You should see that it contains the custom `cronSpec` and `image` fields from the yaml you used to create it: -```console +```yaml apiVersion: v1 kind: List items: @@ -228,14 +233,14 @@ metadata: ## Delete a CustomResourceDefinition When you delete a CustomResourceDefinition, the server will uninstall the RESTful API endpoint -and **delete all custom objects stored in it**. +and delete all custom objects stored in it. ```shell kubectl delete -f resourcedefinition.yaml kubectl get crontabs ``` -```console +```none Error from server (NotFound): Unable to list {"stable.example.com" "v1" "crontabs"}: the server could not find the requested resource (get crontabs.stable.example.com) ``` @@ -362,7 +367,7 @@ Structural schemas are a requirement for `apiextensions.k8s.io/v1`, and disables * [Webhook Conversion](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#webhook-conversion) * [Pruning](#preserving-unknown-fields) -### Pruning versus preserving unknown fields +### Pruning versus preserving unknown fields {#preserving-unknown-fields} {{< feature-state state="stable" for_k8s_version="v1.16" >}} @@ -630,7 +635,9 @@ These fields can only be set with specific features enabled: - `default`: can be set for `apiextensions.k8s.io/v1` CustomResourceDefinitions. Defaulting is in GA since 1.17 (beta since 1.16 with the `CustomResourceDefaulting` feature gate to be enabled, which is the case automatically for many clusters for beta features). Compare [Validation Schema Defaulting](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting). -Note: compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features. +{{< note >}} +Compare with [structural schemas](#specifying-a-structural-schema) for further restriction required for certain CustomResourceDefinition features. +{{< /note >}} The schema is defined in the CustomResourceDefinition. In the following example, the CustomResourceDefinition applies the following validations on the custom object: @@ -642,6 +649,7 @@ Save the CustomResourceDefinition to `resourcedefinition.yaml`: {{< tabs name="CustomResourceDefinition_validation" >}} {{% tab name="apiextensions.k8s.io/v1" %}} + ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -676,8 +684,10 @@ spec: shortNames: - ct ``` + {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 @@ -714,6 +724,7 @@ spec: minimum: 1 maximum: 10 ``` + {{% /tab %}} {{< /tabs >}} @@ -852,7 +863,7 @@ spec: replicas: 1 ``` -Note that defaulting happens on the object +Defaulting happens on the object * in the request to the API server using the request version defaults, * when reading from etcd using the storage version defaults, @@ -895,9 +906,11 @@ columns are shown by the `kubectl get` command. You can customize these columns CustomResourceDefinition. The following example adds the `Spec`, `Replicas`, and `Age` columns. -1. Save the CustomResourceDefinition to `resourcedefinition.yaml`. - {{< tabs name="CustomResourceDefinition_printer_columns" >}} - {{% tab name="apiextensions.k8s.io/v1" %}} +Save the CustomResourceDefinition to `resourcedefinition.yaml`: + +{{< tabs name="CustomResourceDefinition_printer_columns" >}} +{{% tab name="apiextensions.k8s.io/v1" %}} + ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -942,8 +955,10 @@ spec: type: date jsonPath: .metadata.creationTimestamp ``` - {{% /tab %}} - {{% tab name="apiextensions.k8s.io/v1beta1" %}} + +{{% /tab %}} +{{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 @@ -986,31 +1001,34 @@ spec: type: date JSONPath: .metadata.creationTimestamp ``` - {{% /tab %}} - {{< /tabs >}} -2. Create the CustomResourceDefinition: +{{% /tab %}} +{{< /tabs >}} - ```shell - kubectl apply -f resourcedefinition.yaml - ``` +Create the CustomResourceDefinition: -3. Create an instance using the `my-crontab.yaml` from the previous section. +```shell +kubectl apply -f resourcedefinition.yaml +``` -4. Invoke the server-side printing: +Create an instance using the `my-crontab.yaml` from the previous section. - ```shell - kubectl get crontab my-new-cron-object - ``` +Invoke the server-side printing: - Notice the `NAME`, `SPEC`, `REPLICAS`, and `AGE` columns in the output: +```shell +kubectl get crontab my-new-cron-object +``` - ``` - NAME SPEC REPLICAS AGE - my-new-cron-object * * * * * 1 7s - ``` +Notice the `NAME`, `SPEC`, `REPLICAS`, and `AGE` columns in the output: +``` +NAME SPEC REPLICAS AGE +my-new-cron-object * * * * * 1 7s +``` + +{{< note >}} The `NAME` column is implicit and does not need to be defined in the CustomResourceDefinition. +{{< /note >}} #### Priority @@ -1133,6 +1151,7 @@ Save the CustomResourceDefinition to `resourcedefinition.yaml`: {{< tabs name="CustomResourceDefinition_scale" >}} {{% tab name="apiextensions.k8s.io/v1" %}} + ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -1184,8 +1203,10 @@ spec: shortNames: - ct ``` + {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 @@ -1238,6 +1259,7 @@ spec: # labelSelectorPath defines the JSONPath inside of a custom resource that corresponds to Scale.Status.Selector. labelSelectorPath: .status.labelSelector ``` + {{% /tab %}} {{< /tabs >}} @@ -1307,6 +1329,7 @@ Save the following CustomResourceDefinition to `resourcedefinition.yaml`: {{< tabs name="CustomResourceDefinition_categories" >}} {{% tab name="apiextensions.k8s.io/v1" %}} + ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -1342,8 +1365,10 @@ spec: categories: - all ``` + {{% /tab %}} {{% tab name="apiextensions.k8s.io/v1beta1" %}} + ```yaml # Deprecated in v1.16 in favor of apiextensions.k8s.io/v1 apiVersion: apiextensions.k8s.io/v1beta1 @@ -1380,6 +1405,7 @@ spec: categories: - all ``` + {{% /tab %}} {{< /tabs >}} @@ -1431,4 +1457,4 @@ crontabs/my-new-cron-object 3s * Serve [multiple versions](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/) of a CustomResourceDefinition. -{{% /capture %}} +{{% /capture %}} \ No newline at end of file diff --git a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md b/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md index d67ec982a0..436584ad14 100644 --- a/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md +++ b/content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md @@ -108,40 +108,63 @@ my-scheduler-lnf4s-4744f 1/1 Running 0 2m You should see a "Running" my-scheduler pod, in addition to the default kube-scheduler pod in this list. +### Enable leader election + To run multiple-scheduler with leader election enabled, you must do the following: First, update the following fields in your YAML file: * `--leader-elect=true` -* `--lock-object-namespace=lock-object-namespace` -* `--lock-object-name=lock-object-name` +* `--lock-object-namespace=` +* `--lock-object-name=` -If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for endpoints resources, as in the following example: +{{< note >}} +The control plane creates the lock objects for you, but the namespace must already exist. +You can use the `kube-system` namespace. +{{< /note >}} + +If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example: ``` kubectl edit clusterrole system:kube-scheduler ``` ```yaml -- apiVersion: rbac.authorization.k8s.io/v1 - kind: ClusterRole - metadata: - annotations: - rbac.authorization.kubernetes.io/autoupdate: "true" - labels: - kubernetes.io/bootstrapping: rbac-defaults - name: system:kube-scheduler - rules: - - apiGroups: - - "" - resourceNames: - - kube-scheduler - - my-scheduler - resources: - - endpoints - verbs: - - delete - - get - - patch - - update +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + annotations: + rbac.authorization.kubernetes.io/autoupdate: "true" + labels: + kubernetes.io/bootstrapping: rbac-defaults + name: system:kube-scheduler +rules: +- apiGroups: + - coordination.k8s.io + resources: + - leases + verbs: + - create +- apiGroups: + - coordination.k8s.io + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - leases + verbs: + - get + - update +- apiGroups: + - "" + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - endpoints + verbs: + - delete + - get + - patch + - update ``` ## Specify schedulers for pods diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md index 920fe19197..b96f034963 100644 --- a/content/en/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md @@ -62,12 +62,12 @@ but not both in the same item). The first provider in the list is used to encrypt resources going into storage. When reading resources from storage each provider that matches the stored data attempts to decrypt the data in -order. If no provider can read the stored data due to a mismatch in format or secret key, an error -is returned which prevents clients from accessing that resource. +order. If no provider can read the stored data due to a mismatch in format or secret key, an error +is returned which prevents clients from accessing that resource. {{< caution >}} -**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed), -the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to +**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed), +the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to read that resource will fail until it is deleted or a valid decryption key is provided. {{< /caution >}} @@ -117,9 +117,9 @@ To create a new secret perform the following steps: 1. Generate a 32 byte random key and base64 encode it. If you're on Linux or macOS, run the following command: - ``` - head -c 32 /dev/urandom | base64 - ``` + ```shell + head -c 32 /dev/urandom | base64 + ``` 2. Place that value in the secret field. 3. Set the `--encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file. @@ -138,39 +138,42 @@ program to retrieve the contents of your secret. 1. Create a new secret called `secret1` in the `default` namespace: - ``` - kubectl create secret generic secret1 -n default --from-literal=mykey=mydata - ``` + ```shell + kubectl create secret generic secret1 -n default --from-literal=mykey=mydata + ``` 2. Using the etcdctl commandline, read that secret out of etcd: - ``` -    ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C - ``` + `ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C` + + where `[...]` must be the additional arguments for connecting to the etcd server. + +3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data. - where `[...]` must be the additional arguments for connecting to the etcd server. -3. Verify the stored secret is prefixed with `k8s:enc:aescbc:v1:` which indicates the `aescbc` provider has encrypted the resulting data. 4. Verify the secret is correctly decrypted when retrieved via the API: - ``` - kubectl describe secret secret1 -n default - ``` + ```shell + 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 - completely decode the secret. + should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to + completely decode the secret. ## Ensure all secrets are encrypted Since secrets are encrypted on write, performing an update on a secret will encrypt that content. -``` +```shell kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` The command above reads all secrets and then updates them to apply server side encryption. + +{{< note >}} If an error occurs due to a conflicting write, retry the command. For larger clusters, you may wish to subdivide the secrets by namespace or script an update. +{{< /note >}} ## Rotating a decryption key @@ -206,7 +209,10 @@ resources: secret: ``` -and restart all `kube-apiserver` processes. Then run the command `kubectl get secrets --all-namespaces -o json | kubectl replace -f -` +and restart all `kube-apiserver` processes. Then run: +```shell +kubectl get secrets --all-namespaces -o json | kubectl replace -f - +``` to force all secrets to be decrypted. {{% /capture %}} 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 6e7cfe079d..f0368ecaf9 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -50,59 +50,59 @@ The upgrade workflow at high level is the following: ## Determine which version to upgrade to -1. Find the latest stable 1.18 version: +Find the latest stable 1.18 version: - {{< tabs name="k8s_install_versions" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_install_versions" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} apt update apt-cache madison kubeadm # find the latest 1.18 version in the list # it should look like 1.18.x-00, where x is the latest patch - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} yum list --showduplicates kubeadm --disableexcludes=kubernetes # find the latest 1.18 version in the list # it should look like 1.18.x-0, where x is the latest patch - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{< /tabs >}} ## Upgrading control plane nodes ### Upgrade the first control plane node -1. On your first control plane node, upgrade kubeadm: +- On your first control plane node, upgrade kubeadm: - {{< tabs name="k8s_install_kubeadm_first_cp" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_install_kubeadm_first_cp" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm=1.18.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=1.18.x-00 - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} # replace x in 1.18.x-0 with the latest patch version yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{< /tabs >}} -1. Verify that the download works and has the expected version: +- Verify that the download works and has the expected version: ```shell kubeadm version ``` -1. Drain the control plane node: +- Drain the control plane node: ```shell # replace with the name of your control plane node kubectl drain --ignore-daemonsets ``` -1. On the control plane node, run: +- On the control plane node, run: ```shell sudo kubeadm upgrade plan @@ -145,13 +145,13 @@ The upgrade workflow at high level is the following: This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to. - {{< note >}} - `kubeadm upgrade` also automatically renews the certificates that it manages on this node. - To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used. - For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs). - {{}} +{{< note >}} +`kubeadm upgrade` also automatically renews the certificates that it manages on this node. +To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used. +For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadmkubeadm-certs). +{{}} -1. Choose a version to upgrade to, and run the appropriate command. For example: +- Choose a version to upgrade to, and run the appropriate command. For example: ```shell # replace x with the patch version you picked for this upgrade @@ -240,7 +240,7 @@ The upgrade workflow at high level is the following: [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. ``` -1. Manually upgrade your CNI provider plugin. +- Manually upgrade your CNI provider plugin. Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow. Check the [addons](/docs/concepts/cluster-administration/addons/) page to @@ -248,7 +248,7 @@ The upgrade workflow at high level is the following: This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet. -1. Uncordon the control plane node: +- Uncordon the control plane node: ```shell # replace with the name of your control plane node @@ -257,46 +257,46 @@ The upgrade workflow at high level is the following: ### Upgrade additional control plane nodes -1. Same as the first control plane node but use: +Same as the first control plane node but use: - ``` - sudo kubeadm upgrade node - ``` +``` +sudo kubeadm upgrade node +``` - instead of: +instead of: - ``` - sudo kubeadm upgrade apply - ``` +``` +sudo kubeadm upgrade apply +``` - Also `sudo kubeadm upgrade plan` is not needed. +Also `sudo kubeadm upgrade plan` is not needed. ### Upgrade kubelet and kubectl -1. Upgrade the kubelet and kubectl on all control plane nodes: +Upgrade the kubelet and kubectl on all control plane nodes: - {{< tabs name="k8s_install_kubelet" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_install_kubelet" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.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=1.18.x-00 kubectl=1.18.x-00 - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} # replace x in 1.18.x-0 with the latest patch version yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{< /tabs >}} -1. Restart the kubelet +Restart the kubelet - ```shell - sudo systemctl restart kubelet - ``` +```shell +sudo systemctl restart kubelet +``` ## Upgrade worker nodes @@ -305,28 +305,28 @@ without compromising the minimum required capacity for running your workloads. ### Upgrade kubeadm -1. Upgrade kubeadm on all worker nodes: +- Upgrade kubeadm on all worker nodes: - {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_install_kubeadm_worker_nodes" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubeadm && \ apt-get update && apt-get install -y kubeadm=1.18.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=1.18.x-00 - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} # replace x in 1.18.x-0 with the latest patch version yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{< /tabs >}} ### Drain the node -1. Prepare the node for maintenance by marking it unschedulable and evicting the workloads: +- Prepare the node for maintenance by marking it unschedulable and evicting the workloads: ```shell # replace with the name of your node you are draining @@ -343,7 +343,7 @@ without compromising the minimum required capacity for running your workloads. ### Upgrade the kubelet configuration -1. Call the following command: +- Call the following command: ```shell sudo kubeadm upgrade node @@ -351,26 +351,26 @@ without compromising the minimum required capacity for running your workloads. ### Upgrade kubelet and kubectl -1. Upgrade the kubelet and kubectl on all worker nodes: +- Upgrade the kubelet and kubectl on all worker nodes: - {{< tabs name="k8s_kubelet_and_kubectl" >}} - {{% tab name="Ubuntu, Debian or HypriotOS" %}} +{{< tabs name="k8s_kubelet_and_kubectl" >}} +{{% tab name="Ubuntu, Debian or HypriotOS" %}} # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubelet kubectl && \ apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.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=1.18.x-00 kubectl=1.18.x-00 - {{% /tab %}} - {{% tab name="CentOS, RHEL or Fedora" %}} +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} # replace x in 1.18.x-0 with the latest patch version yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes - {{% /tab %}} - {{< /tabs >}} +{{% /tab %}} +{{< /tabs >}} -1. Restart the kubelet +- Restart the kubelet ```shell sudo systemctl restart kubelet @@ -378,7 +378,7 @@ without compromising the minimum required capacity for running your workloads. ### Uncordon the node -1. Bring the node back online by marking it schedulable: +- Bring the node back online by marking it schedulable: ```shell # replace with the name of your node @@ -441,4 +441,4 @@ and post-upgrade manifest file for a certain component, a backup file for it wil `kubeadm upgrade node` does the following on worker nodes: - Fetches the kubeadm `ClusterConfiguration` from the cluster. -- Upgrades the kubelet configuration for this node. +- Upgrades the kubelet configuration for this node. \ No newline at end of file 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 42be624d76..6ffe290a19 100644 --- a/content/en/docs/tasks/administer-cluster/kubelet-config-file.md +++ b/content/en/docs/tasks/administer-cluster/kubelet-config-file.md @@ -7,7 +7,7 @@ content_template: templates/task --- {{% capture overview %}} -{{< feature-state state="beta" >}} +{{< feature-state for_k8s_version="v1.10" state="beta" >}} A subset of the Kubelet's configuration parameters may be set via an on-disk config file, as a substitute for command-line flags. diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index 2098a42991..a1d4c786c6 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -20,7 +20,7 @@ in the namespace. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -Each node in your cluster must have at least 1 CPU. +Your cluster must have at least 1 CPU available for use to run the task examples. {{% /capture %}} @@ -204,11 +204,7 @@ Because your Container did not specify its own CPU request and limit, it was giv [default CPU request and limit](/docs/tasks/administer-cluster/cpu-default-namespace/) from the LimitRange. -At this point, your Container might be running or it might not be running. Recall that a prerequisite -for this task is that your Nodes have at least 1 CPU. If each of your Nodes has only -1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request -of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have -enough CPU to accommodate the 800 millicpu request. +At this point, your Container might be running or it might not be running. Recall that a prerequisite for this task is that your cluster must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request. Delete your Pod: diff --git a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md index 9a69058ceb..9e3f4d6371 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md +++ b/content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md @@ -268,7 +268,8 @@ kubectl get pods Production likes to run cattle, so let's create some cattle pods. ```shell -kubectl run cattle --image=k8s.gcr.io/serve_hostname --replicas=5 +kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname +kubectl scale deployment cattle --replicas=5 kubectl get deployment ``` diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md index de2230a6a4..076f81d9b9 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces.md +++ b/content/en/docs/tasks/administer-cluster/namespaces.md @@ -189,7 +189,8 @@ This delete is asynchronous, so for a time you will see the namespace in the `Te To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace. ```shell - kubectl run snowflake --image=k8s.gcr.io/serve_hostname --replicas=2 -n=development + kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development + kubectl scale deployment snowflake --replicas=2 -n=development ``` We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname. Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead. diff --git a/content/en/docs/tasks/administer-cluster/nodelocaldns.md b/content/en/docs/tasks/administer-cluster/nodelocaldns.md index 6502ce1472..0907f8f0ac 100644 --- a/content/en/docs/tasks/administer-cluster/nodelocaldns.md +++ b/content/en/docs/tasks/administer-cluster/nodelocaldns.md @@ -32,7 +32,7 @@ Having a local cache will help improve the latency in such scenarios. * Skipping iptables DNAT and connection tracking will help reduce [conntrack races](https://github.com/kubernetes/kubernetes/issues/56903) and avoid UDP DNS entries filling up conntrack table. -* Connections from local caching agent to kube-dns servie can be upgraded to TCP. TCP conntrack entries will be removed on connection close in contrast with UDP entries that have to timeout ([default](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt) `nf_conntrack_udp_timeout` is 30 seconds) +* Connections from local caching agent to kube-dns service can be upgraded to TCP. TCP conntrack entries will be removed on connection close in contrast with UDP entries that have to timeout ([default](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt) `nf_conntrack_udp_timeout` is 30 seconds) * Upgrading DNS queries from UDP to TCP would reduce tail latency attributed to dropped UDP packets and DNS timeouts usually up to 30s (3 retries + 10s timeout). Since the nodelocal cache listens for UDP DNS queries, applications don't need to be changed. diff --git a/content/en/docs/tasks/administer-cluster/quota-api-object.md b/content/en/docs/tasks/administer-cluster/quota-api-object.md index c6cff90769..faf7210384 100644 --- a/content/en/docs/tasks/administer-cluster/quota-api-object.md +++ b/content/en/docs/tasks/administer-cluster/quota-api-object.md @@ -122,7 +122,7 @@ by quotas: - + diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md index 83bb8f3379..af5696d622 100644 --- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md +++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md @@ -70,10 +70,10 @@ and is overridden by command-line flags. Unspecified values in the new configura will receive default values appropriate to the configuration version (e.g. `kubelet.config.k8s.io/v1beta1`), unless overridden by flags. -The status of the Node's kubelet configuration is reported via +The status of the Node's kubelet configuration is reported via `Node.Spec.Status.Config`. Once you have updated a Node to use the new ConfigMap, you can observe this status to confirm that the Node is using the -intended configuration. +intended configuration. This document describes editing Nodes using `kubectl edit`. There are other ways to modify a Node's spec, including `kubectl patch`, for @@ -136,7 +136,7 @@ adapt the steps if you prefer to extract the `kubeletconfig` subobject manually. 1. Choose a Node to reconfigure. In this example, the name of this Node is referred to as `NODE_NAME`. -2. Start the kubectl proxy in the background using the following command: +2. Start the kubectl proxy in the background using the following command: ```bash kubectl proxy --port=8001 & @@ -236,8 +236,8 @@ Retrieve the Node using the `kubectl get node ${NODE_NAME} -o yaml` command and The`lastKnownGood` configuration might not be present if it is set to its default value, the local config deployed with the node. The status will update `lastKnownGood` to -match a valid `assigned` config after the kubelet becomes comfortable with the config. -The details of how the kubelet determines a config should become the `lastKnownGood` are +match a valid `assigned` config after the kubelet becomes comfortable with the config. +The details of how the kubelet determines a config should become the `lastKnownGood` are not guaranteed by the API, but is currently implemented as a 10-minute grace period. You can use the following command (using `jq`) to filter down @@ -287,7 +287,7 @@ by eye). If an error occurs, the kubelet reports it in the `Node.Status.Config.Error` structure. Possible errors are listed in -[Understanding Node.Status.Config.Error messages](#understanding-node-status-config-error-messages). +[Understanding Node.Status.Config.Error messages](#understanding-node-config-status-errors). You can search for the identical text in the kubelet log for additional details and context about the error. @@ -355,7 +355,7 @@ metadata and checkpoints. The structure of the kubelet's checkpointing directory | - ... ``` -## Understanding Node.Status.Config.Error messages +## Understanding Node.Status.Config.Error messages {#understanding-node-config-status-errors} The following table describes error messages that can occur when using Dynamic Kubelet Config. You can search for the identical text @@ -379,4 +379,4 @@ internal failure, see Kubelet log for details | The kubelet encountered some int - For more information on configuring the kubelet via a configuration file, see [Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file). - See the reference documentation for [`NodeConfigSource`](https://kubernetes.io/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core) -{{% /capture %}} +{{% /capture %}} \ No newline at end of file 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 e82b55583b..c78c9edb42 100644 --- a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -173,7 +173,7 @@ For example: in Centos, you can do this using the tuned toolset. 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`](./out-of-resource.md) management. Evictions are +provides [`Out of Resource`](/docs/tasks/administer-cluster/out-of-resource/) 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 availability on the node drops below the reserved value. Hypothetically, if @@ -190,7 +190,7 @@ The scheduler treats `Allocatable` as the available `capacity` for pods. `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](./out-of-resource.md#eviction-policy). This enforcement is controlled by +[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by specifying `pods` value to the kubelet flag `--enforce-node-allocatable`. @@ -251,4 +251,4 @@ 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` -{{% /capture %}} +{{% /capture %}} \ No newline at end of file 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 38eab4ded2..d2d58ae702 100644 --- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md @@ -173,8 +173,8 @@ to the metadata API, and avoid using provisioning data to deliver secrets. ### Controlling which nodes pods may access 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/configuration/assign-pod-node/) -and the [taint based pod placement and eviction](/docs/concepts/configuration/taint-and-toleration/) +[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/) 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. diff --git a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md index 5e57c18379..f96c066dd5 100644 --- a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md @@ -159,7 +159,7 @@ A pod with the _unsafe_ sysctls will fail to launch on any node which has not enabled those two _unsafe_ sysctls explicitly. As with _node-level_ sysctls it is recommended to use [_taints and toleration_ feature](/docs/reference/generated/kubectl/kubectl-commands/#taint) or -[taints on nodes](/docs/concepts/configuration/taint-and-toleration/) +[taints on nodes](/docs/concepts/scheduling-eviction/taint-and-toleration/) to schedule those pods onto the right nodes. ## PodSecurityPolicy diff --git a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md index c5ec448e48..181b92b8e1 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/en/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -18,7 +18,7 @@ allocated as much CPU as it requests. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -Each node in your cluster must have at least 1 CPU. +Your cluster must have at least 1 CPU available for use to run the task examples. A few of the steps on this page require you to run the [metrics-server](https://github.com/kubernetes-incubator/metrics-server) @@ -122,9 +122,7 @@ Recall that by setting `-cpu "2"`, you configured the Container to attempt to us {{< note >}} Another possible explanation for the CPU use being below 1.0 is that the Node might not have -enough CPU resources available. Recall that the prerequisites for this exercise require each of -your Nodes to have at least 1 CPU. If your Container runs on a Node that has only 1 CPU, the Container -cannot use more than 1 CPU regardless of the CPU limit specified for the Container. +enough CPU resources available. Recall that the prerequisites for this exercise require your cluster to have at least 1 CPU available for use. If your Container runs on a Node that has only 1 CPU, the Container cannot use more than 1 CPU regardless of the CPU limit specified for the Container. {{< /note >}} ## CPU units @@ -182,9 +180,6 @@ The output shows that the Pod status is Pending. That is, the Pod has not been scheduled to run on any Node, and it will remain in the Pending state indefinitely: -```shell -kubectl get pod cpu-demo-2 --namespace=cpu-example -``` ``` NAME READY STATUS RESTARTS AGE cpu-demo-2 0/1 Pending 0 7m diff --git a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md index ded131d610..16773cd215 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md +++ b/content/en/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md @@ -116,5 +116,5 @@ This means that the pod will prefer a node that has a `disktype=ssd` label. {{% capture whatsnext %}} Learn more about -[Node Affinity](/docs/concepts/configuration/assign-pod-node/#node-affinity). +[Node Affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity). {{% /capture %}} 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 83d9dee596..8045ae9a02 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -154,7 +154,7 @@ spec: imagePullPolicy: Always name: iis nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows ``` Individual containers in a Pod spec can also specify the desired GMSA credspec using a per-container `securityContext.windowsOptions.gmsaCredentialSpecName` field. For example: @@ -185,7 +185,7 @@ spec: windowsOptions: gmsaCredentialSpecName: gmsa-Webapp1 nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows ``` As Pod specs with GMSA fields populated (as described above) are applied in a cluster, the following sequence of events take place: 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 71fad95de9..c7f80b0fad 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 @@ -588,6 +588,10 @@ SPECIAL_TYPE If there are some files in the `/etc/config/` directory, they will be deleted. {{< /caution >}} +{{< note >}} +Text data is exposed as files using the UTF-8 character encoding. To use some other character encoding, use binaryData. +{{< /note >}} + ### Add ConfigMap data to a specific path in the Volume Use the `path` field to specify the desired file path for specific ConfigMap items. 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 530666e9dc..ac912327f3 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md +++ b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md @@ -16,6 +16,10 @@ This page shows how to use the `runAsUserName` setting for Pods and containers t You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running Windows workloads will get scheduled. +{{% /capture %}} + +{{% capture steps %}} + ## 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. @@ -118,4 +122,4 @@ For more information about these limtations, check [here](https://support.micros * [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts) * [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/) -{{% /capture %}} +{{% /capture %}} \ No newline at end of file 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 a86ae91aca..021a8feb22 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 @@ -183,27 +183,38 @@ The content of `token` is elided here. ## Add ImagePullSecrets to a service account -First, create an imagePullSecret, as described [here](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). -Next, verify it has been created. For example: +### Create an imagePullSecret -```shell -kubectl get secrets myregistrykey -``` +- Create an imagePullSecret, as described in [Specifying ImagePullSecrets on a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod). -The output is similar to this: + ```shell + kubectl create secret docker-registry myregistrykey --docker-server=DUMMY_SERVER \ + --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \ + --docker-email=DUMMY_DOCKER_EMAIL + ``` -``` -NAME TYPE DATA AGE -myregistrykey   kubernetes.io/.dockerconfigjson   1       1d -``` +- Verify it has been created. + ```shell + kubectl get secrets myregistrykey + ``` + + The output is similar to this: + + ``` + NAME TYPE DATA AGE + myregistrykey   kubernetes.io/.dockerconfigjson   1       1d + ``` + +### Add image pull secret to service account Next, modify the default service account for the namespace to use this secret as an imagePullSecret. + ```shell kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' ``` -Interactive version requires manual edit: +You can instead use `kubectl edit`, or manually edit the YAML manifests as shown below: ```shell kubectl get serviceaccounts default -o yaml > ./sa.yaml @@ -248,12 +259,19 @@ Finally replace the serviceaccount with the new updated `sa.yaml` file kubectl replace serviceaccount default -f ./sa.yaml ``` -Now, any new pods created in the current namespace will have this added to their spec: +### Verify imagePullSecrets was added to pod spec -```yaml -spec: - imagePullSecrets: - - name: myregistrykey +Now, when a new Pod is created in the current namespace and using the default ServiceAccount, the new Pod has its `spec.imagePullSecrets` field set automatically: + +```shell +kubectl run nginx --image=nginx --restart=Never +kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}' +``` + +The output is: + +``` +myregistrykey ``` + + + +
+

+

+
+

Eventi futuri

+ {{< upcoming-events >}} +
+
+ +
+
+
+

Comunità globale

+Con oltre 150 meetup in tutto il mondo in continua crescita, trova le persone della comunità che sono vicine a te. Se non ci sono eventi vicini a te, organizzane uno tu! +
+ +
+TROVA UN MEETUP +
+ + +
+
+ + + + +
+

+

+

Notizie Recenti

+ +
+
+ +
+ +
+



+
+ + diff --git a/content/it/community/code-of-conduct.md b/content/it/community/code-of-conduct.md index 7c64183ece..01cbc40fbb 100644 --- a/content/it/community/code-of-conduct.md +++ b/content/it/community/code-of-conduct.md @@ -1,5 +1,5 @@ --- -title: Community +title: Comunità layout: basic cid: community css: /css/community.css @@ -10,15 +10,16 @@ css: /css/community.css Kubernetes segue il codice di condotta CNCF. -Il testo del CNC CoC è replicato di seguito a partire dal -commit 0ce4694. -Se noti che questo non è aggiornato, ti preghiamo di far presente questo problema. -file an issue. +Il testo del codice di condotta CNCF è replicato di seguito a partire dal +commit 214585e. +Se noti che questo non è aggiornato, ti preghiamo +inviare una issue -Se noti una violazione del Codice di condotta in occasione di un evento o una riunione, in Slack o in un altro meccanismo di comunicazione, -contatta il Comitato per -il codice di condotta di Kubernetes/a>. -Potete raggiungerci via email all'indirizzo conduct@kubernetes.io. +Se noti una violazione del codice di condotta in occasione di un evento +o una riunione, in Slack o in un altro canale di comunicazione, +contatta il comitato per +il codice di condotta di Kubernetes. +Potete raggiungerci tramite email a conduct@kubernetes.io. Il tuo anonimato sarà protetto.
diff --git a/content/it/community/static/cncf-code-of-conduct.md b/content/it/community/static/cncf-code-of-conduct.md index 3ee025ba34..0622b9edab 100644 --- a/content/it/community/static/cncf-code-of-conduct.md +++ b/content/it/community/static/cncf-code-of-conduct.md @@ -1,46 +1,28 @@ -## CNCF Community Code of Conduct v1.0 +## CNCF Codice di condotta comunitaria v1.0 -### Contributor Code of Conduct +### Codice di condotta dei collaboratori -As contributors and maintainers of this project, and in the interest of fostering -an open and welcoming community, we pledge to respect all people who contribute -through reporting issues, posting feature requests, updating documentation, -submitting pull requests or patches, and other activities. +Come collaboratori e responsabili di questo progetto, per creare un ambiente accogliente e aperto, ci impegniamo a rispettare tutte le persone che contribuiranno a segnalare dei problemi, condividendo richieste, aggiornando la documentazione, inviando richieste o patch e altre attività. -We are committed to making participation in this project a harassment-free experience for -everyone, regardless of level of experience, gender, gender identity and expression, -sexual orientation, disability, personal appearance, body size, race, ethnicity, age, -religion, or nationality. +Ci impegniamo a far si che la partecipazione ai progetti CNCF sia un’esperienza senza alcun tipo di molestia, indipendentemente dal livello di esperienza, genere, espressione, orientamento sessuale, disabilità, apparenza fisica, taglia, razza, etnia, età, religione o nazionalità. -Examples of unacceptable behavior by participants include: +Esempi di comportamenti inaccettabili includono: -* The use of sexualized language or imagery -* Personal attacks -* Trolling or insulting/derogatory comments -* Public or private harassment -* Publishing other's private information, such as physical or electronic addresses, - without explicit permission -* Other unethical or unprofessional conduct. +- Uso di linguaggio o immagini volgari +- Attacchi personali +- Trolling o commenti dispregiativi +- Molestie privato o pubbliche +- Pubblicazione di informazioni personali, come indirizzi di posta elettronica o indirizzi di residenza, senza permesso esplicito +- Altri tipi di condotta non etica o non professionale -Project maintainers have the right and responsibility to remove, edit, or reject -comments, commits, code, wiki edits, issues, and other contributions that are not -aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers -commit themselves to fairly and consistently applying these principles to every aspect -of managing this project. Project maintainers who do not follow or enforce the Code of -Conduct may be permanently removed from the project team. +I responsabili di progetto hanno il diritto e la responsabilità di rimuovere, modificare o respingere commenti, aggressioni, codice, wiki edit, reclami e altri contributi che non siano allineati con questo codice di condotta. Adottando il codice di condotta, i responsabili del progetto si impegnano ad applicare questi principi in prima persona e a ogni aspetto della gestione del progetto. I responsabili che non seguiranno o non faranno rispettare il codice di condotta saranno rimossi dal team. Questo codice di condotta verrà applicato a chiunque contribuisca o rappresenti un progetto o la sua comunità in pubblico. -This code of conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. +Casi di comportamenti abusivi, molestie o altri comportamenti inaccettabili in Kubernetes potranno essere denunciati contattando [Il comitato del codice di condotta Kubernetes (CNCF)](https://git.k8s.io/community/committee-code-of-conduct) attraverso . Per altri progetti, contattare il Project manager del CNCF o il nostro mediatore, Mishi Choudhary . -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting -the [Kubernetes Code of Conduct Committee](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct) . +Il codice di condotta è stato adattato dal Contributor Covenant (http://contributor-covenant.org), versione 1.2.0, disponibile su http://contributor-covenant.org/version/1/2/0/ -This Code of Conduct is adapted from the Contributor Covenant -(http://contributor-covenant.org), version 1.2.0, available at -http://contributor-covenant.org/version/1/2/0/ +### CNCF Codice di condotta negli eventi -### CNCF Events Code of Conduct - -CNCF events are governed by the Linux Foundation [Code of Conduct](http://events.linuxfoundation.org/events/cloudnativecon/attend/code-of-conduct) available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents. +Gli eventi CNCF sono gestiti da Linux Foundation Codice di Condotta disponibile sulla pagina dell'evento. Questo è compatibile con quanto descritto sopra e include maggiori dettagli sulla gestione degli incidenti. diff --git a/content/it/docs/_index.md b/content/it/docs/_index.md new file mode 100644 index 0000000000..b4ffb21447 --- /dev/null +++ b/content/it/docs/_index.md @@ -0,0 +1,3 @@ +--- +title: Documentazione +--- diff --git a/content/it/docs/concepts/_index.md b/content/it/docs/concepts/_index.md index 5acaec055e..f471f2cd79 100644 --- a/content/it/docs/concepts/_index.md +++ b/content/it/docs/concepts/_index.md @@ -1,5 +1,5 @@ --- -title: Concepts +title: Concetti main_menu: true content_template: templates/concept weight: 40 diff --git a/content/it/docs/concepts/architecture/cloud-controller.md b/content/it/docs/concepts/architecture/cloud-controller.md index 632157e892..866309ce2d 100644 --- a/content/it/docs/concepts/architecture/cloud-controller.md +++ b/content/it/docs/concepts/architecture/cloud-controller.md @@ -6,11 +6,11 @@ weight: 30 {{% capture overview %}} -Il concetto CCM (cloud controller manager) (da non confondere con il binario) è stato originariamente creato per consentire al codice del fornitore specifico del cloud e al core Kubernetes di evolversi indipendentemente l'uno dall'altro. Il gestore del controller cloud viene eseguito insieme ad altri componenti principali come il controller controller di Kubernetes, il server API e lo scheduler. Può anche essere avviato come addon di Kubernetes, nel qual caso viene eseguito su Kubernetes. +Il concetto di CCM (cloud controller manager), da non confondere con il binario, è stato originariamente creato per consentire di sviluppare Kubernetes indipendentemente dall'implementazione dello specifico cloud provider. Il cloud controller manager viene eseguito insieme ad altri componenti principali come il Kubernetes controller manager, il server API e lo scheduler. Può anche essere avviato come addon di Kubernetes, nel qual caso viene eseguito su Kubernetes. -Il design del gestore del controller cloud è basato su un meccanismo di plug-in che consente ai nuovi provider cloud di integrarsi facilmente con Kubernetes utilizzando plug-in. Sono in atto piani per l'acquisizione a bordo di nuovi provider di cloud su Kubernetes e per la migrazione dei provider di cloud dal vecchio modello al nuovo modello CCM. +Il design del cloud controller manager è basato su un meccanismo di plug-in che consente ai nuovi provider cloud di integrarsi facilmente con Kubernetes creando un plug-in. Sono in atto programmi per l'aggiunta di nuovi provider di cloud su Kubernetes e per la migrazione dei provider che usano il vecchio metodo a questo nuovo metodo. -Questo documento discute i concetti alla base del gestore del controller cloud e fornisce dettagli sulle funzioni associate. +Questo documento discute i concetti alla base del cloud controller manager e fornisce dettagli sulle funzioni associate. Ecco l'architettura di un cluster Kubernetes senza il gestore del controller cloud: @@ -21,7 +21,7 @@ Ecco l'architettura di un cluster Kubernetes senza il gestore del controller clo {{% capture body %}} -## Design +## Architettura Nel diagramma precedente, Kubernetes e il provider cloud sono integrati attraverso diversi componenti: @@ -30,100 +30,84 @@ Nel diagramma precedente, Kubernetes e il provider cloud sono integrati attraver * Kubernetes API server -CCM consolida tutta la logica dipendente dal cloud dai tre componenti precedenti per creare un singolo punto di integrazione con il cloud. La nuova architettura con il CCM si presenta così: +Il CCM consolida tutta la logica dipendente dal cloud presente nei tre componenti precedenti, per creare un singolo punto di integrazione con il cloud. La nuova architettura con il CCM si presenta così: ![CCM Kube Arch](/images/docs/post-ccm-arch.png) -## Components of the CCM +## Componenti del CCM -CCM interrompe alcune funzionalità di Kubernetes controller manager (KCM) e lo esegue come processo separato. In particolare, elimina i controller in KCM dipendenti dal cloud. KCM ha i seguenti loop del controller dipendenti dal cloud: +Il CCM divide alcune funzionalità del Kubernetes controller manager (KCM) e le esegue in un differente processo. In particolare, toglie dal KCM le integrazioni con il cloud specifico. Il KCM ha i seguenti controller che dipendono dal cloud specifico: * Node controller * Volume controller * Route controller * Service controller -Nella versione 1.9, CCM esegue i seguenti controller dall'elenco precedente: +Nella versione 1.9, il CCM esegue i seguenti controller dall'elenco precedente: * Node controller * Route controller * Service controller -Inoltre, esegue un altro controller chiamato controller PersistentVolumeLabels. Questo controller è responsabile dell'impostazione delle etichette delle zone e delle regioni su PersistentVolumes creati nei cloud GCP e AWS. - {{< note >}} -Il controller del volume è stato deliberatamente scelto per non far parte di CCM. A causa della complessità e degli sforzi già esistenti per estrapolare la logica del volume specifica del fornitore, è stato deciso che il controller del volume non verrà spostato su CCM. +È stato deliberatamente deciso di non spostare il Volume controller nel CCM. Data la complessità del Volume controller e gli sforzi già fatti per astrarre le logiche specifiche dei singoli fornitori, è stato deciso che il Volume controller non verrà spostato nel CCM. {{< /note >}} -Il piano originale per supportare i volumi utilizzando CCM era di utilizzare i volumi Flex per supportare volumi collegabili. Tuttavia, è in programma uno sforzo concorrente noto come CSI per sostituire la logica Flex.me, è stato deciso che il controller del volume non verrà spostato su CCM. +Il piano originale per supportare i volumi utilizzando il CCM era di utilizzare [Flex](/docs/concepts/storage/volumes/#flexVolume) per supportare volumi collegabili. Tuttavia, una implementazione parallela, nota come [CSI](/docs/concepts/storage/volumes/#csi) è stata designata per sostituire Flex. -Considerando queste dinamiche, abbiamo deciso di adottare una misurazione dell'interruzione intermedia finché il CSI non è pronto. +Considerando queste evoluzioni, abbiamo deciso di adottare un approccio intermedio finché il CSI non è pronto. -## Functions of the CCM +## Funzioni del CCM -Il CCM eredita le sue funzioni da componenti di Kubernetes che dipendono da un provider di cloud. Questa sezione è strutturata in base a tali componenti. +Il CCM eredita le sue funzioni da componenti di Kubernetes che dipendono da uno specifico provider di cloud. Questa sezione è strutturata sulla base di tali componenti. ### 1. Kubernetes controller manager -La maggior parte delle funzioni del CCM è derivata dal KCM. Come menzionato nella sezione precedente, CCM esegue i seguenti cicli di controllo: +La maggior parte delle funzioni del CCM deriva dal KCM. Come menzionato nella sezione precedente, CCM esegue i seguenti cicli di controllo: * Node controller * Route controller * Service controller -* PersistentVolumeLabels controller #### Node controller -Il controller del nodo è responsabile per l'inizializzazione di un nodo ottenendo informazioni sui nodi in esecuzione nel cluster dal provider cloud. Il controller del nodo esegue le seguenti funzioni: +Il Node controller è responsabile per l'inizializzazione di un nodo ottenendo informazioni sui nodi in esecuzione nel cluster dal provider cloud. Il controller del nodo esegue le seguenti funzioni: -1. Inizializzare un nodo con etichette zona / regione specifiche per il cloud. -2. Inizializzare un nodo con dettagli di istanza specifici del cloud, ad esempio, tipo e dimensione. -3. Ottenere gli indirizzi di rete del nodo e il nome host. +1. Inizializzare un nodo con le label zone/region specifiche per il cloud in uso. +2. Inizializzare un nodo con le specifiche, ad esempio, tipo e dimensione specifiche del cloud in uso. +3. Ottenere gli indirizzi di rete del nodo e l'hostname. 4. Nel caso in cui un nodo non risponda, controlla il cloud per vedere se il nodo è stato cancellato dal cloud. -Se il nodo è stato eliminato dal cloud, elimina l'oggetto Nodo Kubernetes. +Se il nodo è stato eliminato dal cloud, elimina l'oggetto Nodo di Kubernetes. #### Route controller -Il controller di instradamento è responsabile della configurazione delle rotte nel cloud in modo appropriato in modo che i contenitori su nodi diversi nel cluster Kubernetes possano comunicare tra loro. Il controller di percorso è applicabile solo ai cluster di Google Compute Engine. +Il Route controller è responsabile della configurazione delle route nel cloud in modo che i container su nodi differenti del cluster Kubernetes possano comunicare tra loro. Il Route controller è utilizzabile solo dai cluster su Google Compute Engine. #### Service Controller -Il responsabile del servizio è responsabile dell'ascolto del servizio di creazione, aggiornamento ed eliminazione di eventi. In base allo stato attuale dei servizi in Kubernetes, configura i bilanciatori del carico cloud (come ELB o Google LB) per riflettere lo stato dei servizi in Kubernetes. Inoltre, assicura che i back-end di servizio per i servizi di bilanciamento del carico del cloud siano aggiornati. - -#### PersistentVolumeLabels controller - -Il controllore PersistentVolumeLabels applica le etichette sui volumi AWS EBS / GCE PD al momento della creazione. Ciò elimina la necessità per gli utenti di impostare manualmente le etichette su questi volumi. - -Queste etichette sono essenziali per la pianificazione dei pod in quanto questi volumi sono costretti a funzionare solo all'interno della regione / zona in cui si trovano. Qualsiasi pod che utilizza questi volumi deve essere pianificato nella stessa zona / zona. - -Il controller PersistentVolumeLabels è stato creato appositamente per CCM; cioè, non esisteva prima della creazione del CCM. Ciò è stato fatto per spostare la logica di etichettatura fotovoltaica nel server API Kubernetes (era un controller di ammissione) al CCM. Non funziona su KCM. +Il Service Controller rimane in ascolto per eventi di creazione, aggiornamento ed eliminazione di servizi. In base allo stato attuale dei servizi in Kubernetes, configura i bilanciatori di carico forniti dal cloud (come gli ELB, i Google LB, o gli Oracle Cloud Infrastructure LB) per riflettere lo stato dei servizi in Kubernetes. Inoltre, assicura che i back-end dei bilanciatori di carico forniti dal cloud siano aggiornati. ### 2. Kubelet -Il controller del nodo contiene la funzionalità dipendente dal cloud di kubelet. Prima dell'introduzione del CCM, il kubelet era responsabile dell'inizializzazione di un nodo con dettagli specifici del cloud come indirizzi IP, etichette regione / zona e informazioni sul tipo di istanza. L'introduzione del CCM ha spostato questa operazione di inizializzazione dal kubelet al CCM. +Il Node Controller contiene l'implementazione dipendente dal cloud della kubelet. Prima dell'introduzione del CCM, la kubelet era responsabile dell'inizializzazione di un nodo con dettagli dipendenti dallo specifico cloud come gli indirizzi IP, le label region/zone e le informazioni sul tipo di istanza. L'introduzione del CCM ha spostato questa operazione di inizializzazione dalla kubelet al CCM. -In questo nuovo modello, kubelet inizializza un nodo senza informazioni specifiche del cloud. Tuttavia, aggiunge un disturbo al nodo appena creato che rende il nodo non programmabile finché CCM non inizializza il nodo con informazioni specifiche del cloud. Rimuove quindi questa macchia. +In questo nuovo modello, la kubelet inizializza un nodo senza informazioni specifiche del cloud. Tuttavia, aggiunge un blocco al nodo appena creato che rende il nodo non selezionabile per eseguire container finché il CCM non inizializza il nodo con le informazioni specifiche del cloud. Il CCM rimuove quindi questo blocco. +## Sistema a plug-in -### 3. Kubernetes API server +Il cloud controller manager utilizza le interfacce di Go per consentire l'implementazione di implementazioni di qualsiasi cloud. In particolare, utilizza l'interfaccia CloudProvider definita [qui](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62). -Il controller Persistent Volume Labels sposta la funzionalità dipendente dal cloud del server API di Kubernetes sul CCM come descritto nelle sezioni precedenti +L'implementazione dei quattro controller generici evidenziati sopra, alcune strutture, l'interfaccia cloudprovider condivisa rimarranno nel core di Kubernetes. Le implementazioni specifiche per i vari cloud saranno costruite al di fuori del core e implementeranno le interfacce definite nel core. -## Plugin mechanism +Per ulteriori informazioni sullo sviluppo di plug-in, consultare [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). -Il gestore del controller cloud utilizza le interfacce Go per consentire l'implementazione di implementazioni da qualsiasi cloud. In particolare, utilizza l'interfaccia CloudProvider definita [qui](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62). +## Autorizzazione -L'implementazione dei quattro controller condivisi evidenziati sopra e alcuni scaffolding con l'interfaccia cloudprovider condivisa rimarranno nel core di Kubernetes. Le implementazioni specifiche per i fornitori di cloud saranno costruite al di fuori del core e implementeranno le interfacce definite nel core. +Questa sezione dettaglia l'accesso richiesto dal CCM sui vari API objects per eseguire le sue operazioni. -Per ulteriori informazioni sullo sviluppo di plug-in, consultare [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). +### Node controller -## Authorization - -Questa sezione suddivide l'accesso richiesto su vari oggetti API da CCM per eseguire le sue operazioni. - -### Node Controller - -Il controller del nodo funziona solo con oggetti nodo. Richiede l'accesso completo per ottenere, elencare, creare, aggiornare, applicare patch, guardare ed eliminare oggetti nodo. +Il Node controller funziona solo con oggetti di tipo Node. Richiede l'accesso completo per ottenere, elencare, creare, aggiornare, applicare patch, guardare ed eliminare oggetti di tipo Node. v1/Node: @@ -137,7 +121,7 @@ v1/Node: ### Route controller -Il controllore del percorso ascolta la creazione dell'oggetto Nodo e configura le rotte in modo appropriato. Richiede l'accesso agli oggetti Nodo. +Il Route controller ascolta la creazione dell'oggetto Node e configura le rotte in modo appropriato. Richiede l'accesso in lettura agli oggetti di tipo Node. v1/Node: @@ -145,11 +129,11 @@ v1/Node: ### Service controller -Il controller del servizio ascolta Service object crea, aggiorna ed elimina eventi e quindi configura gli endpoint per tali Servizi in modo appropriato. +Il Service controller resta in ascolto per eventi di creazione, aggiornamento ed eliminazione di oggetti di tipo Servizi, e configura gli endpoint per tali Servizi in modo appropriato. -Per accedere ai Servizi, è necessario un elenco e controllare l'accesso. Per aggiornare i servizi, richiede la patch e l'accesso agli aggiornamenti. +Per accedere ai Servizi, è necessario il permesso per list e watch. Per aggiornare i Servizi, sono necessari i permessi patch e update. -Per impostare gli endpoint per i Servizi, richiede l'accesso per creare, elencare, ottenere, guardare e aggiornare. +Per impostare gli endpoint per i Servizi, richiede i permessi create, list, get, watch, e update. v1/Service: @@ -159,20 +143,9 @@ v1/Service: - Patch - Update -### PersistentVolumeLabels controller - -Il controller Persistent Volume Labels ascolta su Persistent Volume (PV) crea eventi e quindi li aggiorna. Questo controller richiede l'accesso per ottenere e aggiornare PV. - -v1/PersistentVolume: - -- Get -- List -- Watch -- Update - ### Others -L'implementazione del core di CCM richiede l'accesso per creare eventi e per garantire operazioni sicure richiede l'accesso per creare ServiceAccounts. +L'implementazione del core di CCM richiede l'accesso per creare eventi e, per garantire operazioni sicure, richiede l'accesso per creare ServiceAccounts. v1/Event: @@ -184,7 +157,7 @@ v1/ServiceAccount: - Create -RBAC ClusterRole per il CCM ha il seguente aspetto: +L'RBAC ClusterRole per il CCM ha il seguente aspetto: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -250,18 +223,23 @@ rules: ## Vendor Implementations -I seguenti fornitori di cloud hanno implementato CCM: +I seguenti fornitori di cloud hanno una implementazione di CCM: -* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) -* [Azure](https://github.com/kubernetes/cloud-provider-azure) -* [GCP](https://github.com/kubernetes/cloud-provider-gcp) +* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud) * [AWS](https://github.com/kubernetes/cloud-provider-aws) +* [Azure](https://github.com/kubernetes/cloud-provider-azure) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) +* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) +* [GCP](https://github.com/kubernetes/cloud-provider-gcp) +* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager) +* [Linode](https://github.com/linode/linode-cloud-controller-manager) +* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) +* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) +* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) ## Cluster Administration -Sono fornite le istruzioni complete per la configurazione e l'esecuzione del CCM +Le istruzioni complete per la configurazione e l'esecuzione del CCM sono fornite [qui](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager). -{{% /capture %}} \ No newline at end of file +{{% /capture %}} diff --git a/content/it/docs/concepts/architecture/master-node-communication.md b/content/it/docs/concepts/architecture/master-node-communication.md index bcfabac7ee..afbac85793 100644 --- a/content/it/docs/concepts/architecture/master-node-communication.md +++ b/content/it/docs/concepts/architecture/master-node-communication.md @@ -1,4 +1,5 @@ --- +draft: True title: Comunicazione Master-Node content_template: templates/concept weight: 20 diff --git a/content/it/docs/concepts/architecture/nodes.md b/content/it/docs/concepts/architecture/nodes.md index 4ad016b327..f881e8a8eb 100644 --- a/content/it/docs/concepts/architecture/nodes.md +++ b/content/it/docs/concepts/architecture/nodes.md @@ -1,4 +1,5 @@ --- +draft: True title: Nodi content_template: templates/concept weight: 10 diff --git a/content/it/docs/concepts/cluster-administration/_index.md b/content/it/docs/concepts/cluster-administration/_index.md index 72af40feec..68eb847f47 100755 --- a/content/it/docs/concepts/cluster-administration/_index.md +++ b/content/it/docs/concepts/cluster-administration/_index.md @@ -1,5 +1,5 @@ --- -title: "Cluster Administration" +title: "Amministrazione del Cluster" weight: 100 --- diff --git a/content/it/docs/concepts/cluster-administration/addons.md b/content/it/docs/concepts/cluster-administration/addons.md index 67571124ce..65fe5c582f 100644 --- a/content/it/docs/concepts/cluster-administration/addons.md +++ b/content/it/docs/concepts/cluster-administration/addons.md @@ -1,4 +1,5 @@ --- +draft: True title: Installazione dei componenti aggiuntivi content_template: templates/concept --- diff --git a/content/it/docs/concepts/cluster-administration/certificates.md b/content/it/docs/concepts/cluster-administration/certificates.md index e6b8b05dd1..65bf22cf76 100644 --- a/content/it/docs/concepts/cluster-administration/certificates.md +++ b/content/it/docs/concepts/cluster-administration/certificates.md @@ -1,4 +1,5 @@ --- +draft: True title: Certificati content_template: templates/concept weight: 20 diff --git a/content/it/docs/concepts/cluster-administration/cloud-providers.md b/content/it/docs/concepts/cluster-administration/cloud-providers.md index 5ea917a9c5..393c7d3835 100644 --- a/content/it/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/it/docs/concepts/cluster-administration/cloud-providers.md @@ -1,4 +1,5 @@ --- +draft: True title: Cloud Providers content_template: templates/concept weight: 30 diff --git a/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md index cd160cbdcc..e3b848693f 100644 --- a/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/it/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -1,4 +1,5 @@ --- +draft: True title: Panoramica sull'amministrazione del cluster content_template: templates/concept weight: 10 diff --git a/content/it/docs/concepts/cluster-administration/controller-metrics.md b/content/it/docs/concepts/cluster-administration/controller-metrics.md index 666b6023de..ced1604da5 100644 --- a/content/it/docs/concepts/cluster-administration/controller-metrics.md +++ b/content/it/docs/concepts/cluster-administration/controller-metrics.md @@ -1,4 +1,5 @@ --- +draft: True title: Metriche del responsabile del controller content_template: templates/concept weight: 100 diff --git a/content/it/docs/concepts/cluster-administration/federation.md b/content/it/docs/concepts/cluster-administration/federation.md index 187d231f9a..80e0d10b97 100644 --- a/content/it/docs/concepts/cluster-administration/federation.md +++ b/content/it/docs/concepts/cluster-administration/federation.md @@ -1,4 +1,5 @@ --- +draft: True title: Federation content_template: templates/concept weight: 80 diff --git a/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md index 976e64cc95..1aad1b22d9 100644 --- a/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/it/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -1,5 +1,5 @@ --- - +draft: True title: Configurazione della raccolta dati kubelet content_template: templates/concept weight: 70 diff --git a/content/it/docs/concepts/cluster-administration/logging.md b/content/it/docs/concepts/cluster-administration/logging.md index 6c584d8978..179339ec4c 100644 --- a/content/it/docs/concepts/cluster-administration/logging.md +++ b/content/it/docs/concepts/cluster-administration/logging.md @@ -1,4 +1,5 @@ --- +draft: True title: Log di registrazione content_template: templates/concept weight: 60 diff --git a/content/it/docs/concepts/cluster-administration/manage-deployment.md b/content/it/docs/concepts/cluster-administration/manage-deployment.md index 4f4d3dae50..fabf9ffe35 100644 --- a/content/it/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/it/docs/concepts/cluster-administration/manage-deployment.md @@ -1,4 +1,5 @@ --- +draft: True title: Gestione delle risorse content_template: templates/concept weight: 40 diff --git a/content/it/docs/concepts/cluster-administration/networking.md b/content/it/docs/concepts/cluster-administration/networking.md index 2888511489..77829b940f 100644 --- a/content/it/docs/concepts/cluster-administration/networking.md +++ b/content/it/docs/concepts/cluster-administration/networking.md @@ -1,4 +1,5 @@ --- +draft: True title: Cluster Networking content_template: templates/concept weight: 50 diff --git a/content/it/docs/concepts/cluster-administration/proxies.md b/content/it/docs/concepts/cluster-administration/proxies.md index 62a097d096..beee7cfa8a 100644 --- a/content/it/docs/concepts/cluster-administration/proxies.md +++ b/content/it/docs/concepts/cluster-administration/proxies.md @@ -6,62 +6,61 @@ weight: 90 {{% capture overview %}} Questa pagina spiega i proxy utilizzati con Kubernetes. - {{% /capture %}} {{% capture body %}} -## Proxies +## Proxy Esistono diversi proxy che puoi incontrare quando usi Kubernetes: -1. Il [proxy kubectl](/docs/tasks/access-application-cluster/access-cluster/#direct-accessing-the-rest-api): +1. Il [kubectl proxy](/docs/tasks/access-application-cluster/access-cluster/#direct-accessing-the-rest-api): -    - Funziona sul desktop di un utente o in un pod -    - proxy da un indirizzo localhost all'apiserver di Kubernetes -    - client per proxy utilizza HTTP -    - proxy per apiserver utilizza HTTPS +    - viene eseguito sul computer di un utente o in un pod +    - collega un localhost address all'apiserver di Kubernetes +    - il client comunica con il proxy in HTTP +    - il proxy comunica con l'apiserver in HTTPS     - individua l'apiserver -    - Aggiunge le intestazioni di autenticazione +    - aggiunge gli header di autenticazione -1. Il [proxy apiserver](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): +1. L'[apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): -    - è un bastione costruito nell'apiserver +    - è un proxy presente nell'apiserver     - collega un utente al di fuori del cluster agli IP del cluster che altrimenti potrebbero non essere raggiungibili -    - funziona nei processi di apiserver -    - client per proxy utilizza HTTPS (o http se apiserver configurato in tal modo) -    - proxy to target può utilizzare HTTP o HTTPS come scelto dal proxy utilizzando le informazioni disponibili +    - è uno dei processi dell'apiserver +    - il client comunica con il proxy in HTTPS (o HTTP se l'apiserver è configurato in tal modo) +    - il proxy comunica con il target via HTTP o HTTPS come scelto dal proxy utilizzando le informazioni disponibili     - può essere utilizzato per raggiungere un nodo, un pod o un servizio     - esegue il bilanciamento del carico quando viene utilizzato per raggiungere un servizio -1. Il [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): +1. Il [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): -    - Funziona su ciascun nodo -    - proxy UDP, TCP e SCTP -    - non capisce l'HTTP -    - fornisce il bilanciamento del carico -    - è appena usato per raggiungere i servizi +    - è eseguito su ciascun nodo +    - fa da proxy per comunicazioni UDP, TCP e SCTP +    - non gestisce il protocollo HTTP +    - esegue il bilanciamento del carico +    - è usato solo per raggiungere i servizi -1. Un proxy / bilanciamento del carico di fronte agli apiserver: +1. Un proxy/bilanciatore di carico di fronte agli apiserver: -    - esistenza e implementazione variano da cluster a cluster (ad esempio nginx) -    - si trova tra tutti i client e uno o più apiserver -    - funge da bilanciamento del carico se ci sono diversi apiserver. +    - la sua esistenza e implementazione variano da cluster a cluster (ad esempio nginx) +    - si trova tra i client e uno o più apiserver +    - funge da bilanciatore di carico se ci sono più di un apiserver. -1. Cloud Load Balancer su servizi esterni: +1. Cloud Load Balancer su servizi esterni:     - sono forniti da alcuni fornitori di servizi cloud (ad es. AWS ELB, Google Cloud Load Balancer) -    - vengono creati automaticamente quando il servizio Kubernetes ha tipo "LoadBalancer" -    - Solitamente supporta solo UDP / TCP -    - Il supporto SCTP dipende dall'implementazione del servizio di bilanciamento del carico del provider cloud +    - vengono creati automaticamente quando il servizio Kubernetes ha tipo `LoadBalancer` +    - solitamente supporta solo UDP / TCP +    - il supporto SCTP dipende dall'implementazione del bilanciatore di carico del provider cloud     - l'implementazione varia a seconda del provider cloud. -Gli utenti di Kubernetes in genere non devono preoccuparsi di nulla di diverso dai primi due tipi. L'amministratore del cluster -in genere assicurerà che questi ultimi tipi siano impostati correttamente. +Gli utenti di Kubernetes in genere non devono preoccuparsi alcun proxy, se non i primi due tipi. L'amministratore del cluster +in genere assicurerà che gli altri tipi di proxy siano impostati correttamente. ## Richiedere reindirizzamenti -I proxy hanno sostituito le capacità di reindirizzamento. I reindirizzamenti sono stati deprecati. +I proxy hanno sostituito le funzioni di reindirizzamento. I reindirizzamenti sono stati deprecati. {{% /capture %}} diff --git a/content/it/docs/concepts/example-concept-template.md b/content/it/docs/concepts/example-concept-template.md index 27ec896fdc..db1bc0b960 100644 --- a/content/it/docs/concepts/example-concept-template.md +++ b/content/it/docs/concepts/example-concept-template.md @@ -16,12 +16,12 @@ Questa pagina spiega ... {{% capture body %}} -## Understanding ... +## Comprendendo ... Kubernetes fornisce ... -## Using ... +## Usando ... Usare @@ -29,7 +29,7 @@ Usare {{% capture whatsnext %}} -**[Optional Section]** +**[Sezione opzionale]** * Ulteriori informazioni su [Scrivere un nuovo argomento](/docs/home/contribuisci/scrivi-nuovo-argomento/). * Vedi [Uso dei modelli di pagina - Modello di concetto](/docs/home/contribuis/page-templates/#concept_template) su come utilizzare questo modello. diff --git a/content/it/docs/concepts/overview/_index.md b/content/it/docs/concepts/overview/_index.md new file mode 100755 index 0000000000..ec86980c4b --- /dev/null +++ b/content/it/docs/concepts/overview/_index.md @@ -0,0 +1,4 @@ +--- +title: "Overview" +weight: 20 +--- \ No newline at end of file diff --git a/content/it/docs/concepts/overview/components.md b/content/it/docs/concepts/overview/components.md new file mode 100644 index 0000000000..8156b9ab05 --- /dev/null +++ b/content/it/docs/concepts/overview/components.md @@ -0,0 +1,124 @@ +--- +title: I componenti di Kubernetes +content_template: templates/concept +weight: 20 +card: + name: concepts + weight: 20 +--- + +{{% capture overview %}} +Facendo il deployment di Kubernetes, ottieni un cluster. +{{< glossary_definition term_id="cluster" length="all" prepend="Un cluster è">}} + +Questo documento describe i diversi componenti che sono necessari per avere +un cluster Kubernetes completo e funzionante. + +Questo è un diagramma di un cluster Kubernetes con tutti i componenti e le loro relazioni. + +![I componenti di Kubernetes](/images/docs/components-of-kubernetes.png) + +{{% /capture %}} + +{{% capture body %}} +## Componenti della Control Plane + +La Control Plane è responsabile di tutte le decisioni globali sul cluster (ad esempio, lo scheduling), e l'individuazione e la risposta ad eventi derivanti dal cluster (ad esempio, l'avvio di un nuovo {{< glossary_tooltip text="pod" term_id="pod">}} quando il valore `replicas` di un deployment non è soddisfatto). + +I componenti della Control Plane possono essere eseguiti su qualsiasi nodo del cluster, ma solitamente gli script di installazione tendono a eseguire tutti i componenti della Control Plane sulla stessa macchina, separando la Control Plane dai workload dell'utente. +Vedi [creare un cluster in High-Availability](/docs/admin/high-availability/) per un esempio di un'installazione multi-master. + +### kube-apiserver + +{{< glossary_definition term_id="kube-apiserver" length="all" >}} + +### etcd + +{{< glossary_definition term_id="etcd" length="all" >}} + +### kube-scheduler + +{{< glossary_definition term_id="kube-scheduler" length="all" >}} + +### kube-controller-manager + +{{< glossary_definition term_id="kube-controller-manager" length="all" >}} + +Alcuni esempi di controller gestiti dal kube-controller-manager sono: + + * Node Controller: Responsabile del monitoraggio dei nodi del cluster, e.g. della gestione delle azioni da eseguire quando un nodo diventa non disponibile. + * Replication Controller: Responsabile per il mantenimento del corretto numero di Pod per ogni ReplicaSet presente nel sistema + * Endpoints Controller: Popola gli oggetti Endpoints (cioè, mette in relazioni i Pods con i Services). + * Service Account & Token Controllers: Creano gli account di default e i token di accesso alle API per i nuovi namespaces. + +### cloud-controller-manager + +Il [cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/) esegue i controller che interagiscono con i cloud provider responsabili per la gestione dell'infrastruttura sottostante al cluster, in caso di deployment in cloud. +Il cloud-controller-manager è una funzionalità alpha introdotta in Kubernetes 1.6. + +Il cloud-controller-manager esegue esclusivamente i cicli di controllo specifici dei cloud provider. +È possibile disabilitare questi cicli di controllo usando il kube-controller-manager. +È inoltre possibile disabilitare i cicli di controllo settando il parametro `--cloud-provider` con il valore `external` durante l'esecuzione del kube-controller-manager. + +Il cloud-controller-manager permette l'evoluzione indipendente al codice di Kubernetes e a quello dei singoli cloud vendor. +Precedentemente, il codice core di Kubernetes dipendeva da implementazioni specifiche dei cloud provider. +In futuro, implementazioni specifiche per singoli cloud provider devono essere mantenuti dai cloud provider interessati e collegati al cloud-controller-manager. + +I seguenti controller hanno dipendenze verso implementazioni di specifici cloud provider: + + * Node Controller: Per controllare se sul cloud provider i nodi che hanno smesso di rispondere sono stati cancellati + * Route Controller: Per configurare le regole di route nella sottostante infrastruttura cloud + * Service Controller: Per creare, aggiornare ed eliminare i load balancer nella infrastruttura del cloud provider + * Volume Controller: Per creare, associare e montare i volumi e per interagire con il cloud provider per orchestrare i volumi + +## Componenti dei Nodi + +I componenti di Kubernetes che girano sui Worker Node sono responsabili dell'esecuzione dei workload degli utenti. + +### kubelet + +{{< glossary_definition term_id="kubelet" length="all" >}} + +### kube-proxy + +{{< glossary_definition term_id="kube-proxy" length="all" >}} + +### Container Runtime + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## Addons + +Gli Addons usano le risorse Kubernetes ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, etc) per implementare nuove funzionalità a livello di cluster. +Dal momento che gli addons forniscono funzionalità a livello di cluster, le risorse che necessitano di un namespace, vengono collocate nel namespace `kube-system`. + +Alcuni addons sono descritti di seguito; mentre per una più estesa lista di addons, riferirsi ad [Addons](/docs/concepts/cluster-administration/addons/). + +### DNS + +Mentre gli altri addons non sono strettamente richiesti, tutti i cluster Kubernetes dovrebbero essere muniti di un [DNS del cluster](/docs/concepts/services-networking/dns-pod-service/), dal momento che molte applicazioni lo necessitano. + +Il DNS del cluster è un server DNS aggiuntivo rispetto ad altri server DNS presenti nella rete, e si occupa specificatamente dei record DNS per i servizi Kubernetes. + +I container eseguiti da Kubernetes possono utilizzare questo server per la risoluzione DNS. + +### Interfaccia web (Dashboard) + +La [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) è una interfaccia web per i cluster Kubernetes. +Permette agli utenti di gestire e fare troubleshooting delle applicazioni che girano nel cluster, e del cluster stesso. + +### Monitoraggio dei Container + +Il [Monitoraggio dei Container](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) salva serie temporali di metriche generiche dei container in un database centrale e fornisce una interfaccia in cui navigare i dati stessi. + +### Log a livello di Cluster + +Un [log a livello di cluster](/docs/concepts/cluster-administration/logging/) è responsabile per il salvataggio dei log dei container in un log centralizzato la cui interfaccia permette di cercare e navigare nei log. + +{{% /capture %}} +{{% capture whatsnext %}} +* Scopri i concetti relativi ai [Nodi](/docs/concepts/architecture/nodes/) +* Scopri i concetti relativi ai [Controller](/docs/concepts/architecture/controller/) +* Scopri i concetti relativi al [kube-scheduler](/docs/concepts/scheduling/kube-scheduler/) +* Leggi la [documentazione](https://etcd.io/docs/) ufficiale di etcd +{{% /capture %}} diff --git a/content/it/docs/concepts/overview/what-is-kubernetes.md b/content/it/docs/concepts/overview/what-is-kubernetes.md index 4d15318ed3..399b31da9c 100644 --- a/content/it/docs/concepts/overview/what-is-kubernetes.md +++ b/content/it/docs/concepts/overview/what-is-kubernetes.md @@ -1,12 +1,13 @@ --- -title: Cos'è Kubernetes +title: Cos'è Kubernetes? +description: > + Kubernetes è una piattaforma portatile, estensibile e open-source per la gestione di carichi di lavoro e servizi containerizzati, in grado di facilitare sia la configurazione dichiarativa che l'automazione. La piattaforma vanta un grande ecosistema in rapida crescita. Servizi, supporto e strumenti sono ampiamente disponibili nel mondo Kubernetes . content_template: templates/concept weight: 10 card: name: concepts weight: 10 --- - {{% capture overview %}} Questa pagina è una panoramica generale su Kubernetes. @@ -15,75 +16,77 @@ Questa pagina è una panoramica generale su Kubernetes. {{% capture body %}} Kubernetes è una piattaforma portatile, estensibile e open-source per la gestione di carichi di lavoro e servizi containerizzati, in grado di facilitare sia la configurazione dichiarativa che l'automazione. La piattaforma vanta un grande ecosistema in rapida crescita. Servizi, supporto e strumenti sono ampiamente disponibili nel mondo Kubernetes . -Il nome Kubernetes deriva dal greco, significa timoniere o pilota. Google ha aperto il progetto Kubernetes nel 2014. Kubernetes si basa su [dieci anni e mezzo di esperienza di Google nella gestione di workloads (carichi di lavoro) di produzione in scala] (https://ai.google/research/pubs/pub43438), combinata con le migliori idee e pratiche della comunità. +Il nome Kubernetes deriva dal greco, significa timoniere o pilota. Google ha reso open-source il progetto Kubernetes nel 2014. Kubernetes unisce [oltre quindici anni di esperienza di Google nella gestione di carichi di lavoro di produzione su scala mondiale](https://ai.google/research/pubs/pub43438) con le migliori idee e pratiche della comunità. -## Facciamo un piccolo passo indietro +## Facciamo un piccolo salto indietro Diamo un'occhiata alla ragione per cui Kubernetes è così utile facendo un piccolo salto indietro nel tempo. ![Deployment evolution](/images/docs/Container_Evolution.svg) **L'era del deployment tradizionale:** -All'inizio, le organizzazioni eseguivano applicazioni su server fisici. Non c'era modo di definire i limiti delle risorse per le applicazioni in un server fisico e questo ha causato non pochi problemi di allocazione delle risorse. Ad esempio, se più applicazioni vengono eseguite su di un server fisico, si possono verificare casi in cui un'applicazione assorbe la maggior parte delle risorse e, di conseguenza, le altre applicazioni non raggiungono prestazioni ottimali. Una soluzione per questo sarebbe di eseguire ogni applicazione su un server fisico diverso. Ma questo non è la soluzione ideale, perché le risorse vengono sottoutilizzate, inoltre, questa pratica risulta essere costosa per le organizzazioni, le quali devono mantenere numerosi server fisici. +All'inizio, le organizzazioni eseguivano applicazioni su server fisici. Non c'era modo di definire i limiti delle risorse per le applicazioni in un server fisico e questo ha causato non pochi problemi di allocazione delle risorse. Ad esempio, se più applicazioni vengono eseguite sullo stesso server fisico, si possono verificare casi in cui un'applicazione assorbe la maggior parte delle risorse e, di conseguenza, le altre applicazioni non hanno le prestazioni attese. Una soluzione per questo sarebbe di eseguire ogni applicazione su un server fisico diverso. Ma questa non è una soluzione ideale, dal momento che le risorse vengono sottoutilizzate, inoltre, questa pratica risulta essere costosa per le organizzazioni, le quali devono mantenere numerosi server fisici. -**L'era del deployment virtualizzato:** Come soluzione venne introdotta la virtualizzazione. Essa consente di eseguire più macchine virtuali (VM) su di una singola CPU di un server fisico. La virtualizzazione consente di isolare le applicazioni tra più macchine virtuali e fornisce un livello di sicurezza superiore, dal momento che le informazioni di un'applicazione non sono liberamente accessibili da un'altra applicazione. +**L'era del deployment virtualizzato:** +Come soluzione venne introdotta la virtualizzazione. Essa consente di eseguire più macchine virtuali (VM) su una singola CPU fisica. La virtualizzazione consente di isolare le applicazioni in più macchine virtuali e fornisce un livello di sicurezza superiore, dal momento che le informazioni di un'applicazione non sono liberamente accessibili da un'altra applicazione. -La virtualizzazione consente un migliore utilizzo delle risorse in un server fisico e permette una migliore scalabilità, perché un'applicazione può essere aggiunta o aggiornata facilmente, riduce i costi dell'hardware e molto altro ancora. +La virtualizzazione consente un migliore utilizzo delle risorse riducendo i costi per l'hardware, permette una migliore scalabilità, dato che un'applicazione può essere aggiunta o aggiornata facilmente, e ha molti altri vantaggi. -Ogni VM è una macchina completa che esegue tutti i componenti, compreso il proprio sistema operativo, oltre all'hardware virtualizzato. +Ogni VM è una macchina completa che esegue tutti i componenti, compreso il proprio sistema operativo, sopra all'hardware virtualizzato. -**L'era del deployment a container:** I container sono simili alle macchine virtuali, ma presentano proprietà di isolamento che consentono di condividere il sistema operativo (OS) tra le applicazioni. Pertanto, i container sono considerati più leggeri. Analogamente a una macchina virtuale, un contenitore dispone di un proprio filesystem, CPU, memoria, spazio di elaborazione e altro ancora. Poiché sono disaccoppiati dall'infrastruttura sottostante, risultano portatili su cloud e distribuzioni di sistemi operativi. +**L'era del deployment in container:** +I container sono simili alle macchine virtuali, ma presentano un modello di isolamento più leggero, condividendo il sistema operativo (OS) tra le applicazioni. Pertanto, i container sono considerati più leggeri. Analogamente a una macchina virtuale, un container dispone di una segregazione di filesystem, CPU, memoria, PID e altro ancora. Poiché sono disaccoppiati dall'infrastruttura sottostante, risultano portabili tra differenti cloud e diverse distribuzioni. -I container stanno diventando popolari perché offrono molteplici vantaggi. Alcuni dei vantaggi dei container sono elencati di seguito: +I container sono diventati popolari dal momento che offrono molteplici vantaggi, ad esempio: * Creazione e distribuzione di applicazioni Agile: maggiore facilità ed efficienza nella creazione di immagini container rispetto all'uso di immagini VM. -* Sviluppo, integrazione e distribuzione continuativi: consente la creazione e la distribuzione di immagini container affidabili e frequenti con rollback rapidi e semplici (a causa dell'immutabilità dell'immagine). -* Separazione delle fasi di Dev e Ops: si creano immagini contenitore di applicazioni al momento della costruzione/rilascio piuttosto che al momento della distribuzione, disaccoppiando così le applicazioni dall'infrastruttura. -* L'osservabilità non riguarda solo le informazioni e le metriche a livello di sistema operativo, ma anche lo stato di salute dell'applicazione e altri segnali. -* Coerenza ambientale tra sviluppo, test e produzione: Funziona sullo stesso modo su un computer portatile come nel cloud. -* Portabilità della distribuzione cloud e del sistema operativo: Funziona su Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine e ovunque. -* Gestione incentrata sulle applicazioni: Aumenta il livello di astrazione dall'esecuzione di un sistema operativo su hardware virtuale all'esecuzione di un'applicazione su un sistema operativo utilizzando risorse logiche. -* Microservizi liberamente abbinabili, distribuiti, elastici e liberalizzati: le applicazioni sono suddivise in pezzi più piccoli e indipendenti e possono essere distribuite e gestite dinamicamente - niente stack monolitici che girano su di una grande macchina monouso. -* Isolamento delle risorse: prestazioni prevedibili dell'applicazione. +* Adozione di pratiche per lo sviluppo/test/rilascio continuativo: consente la frequente creazione e la distribuzione di container image affidabili, dando la possibilità di fare rollback rapidi e semplici (grazie all'immutabilità dell'immagine stessa). +* Separazione delle fasi di Dev e Ops: le container image vengono prodotte al momento della compilazione dell'applicativo piuttosto che nel momento del rilascio, permettendo così di disaccoppiare le applicazioni dall'infrastruttura sottostante. +* L'osservabilità non riguarda solo le informazioni e le metriche del sistema operativo, ma anche lo stato di salute e altri segnali dalle applicazioni. +* Coerenza di ambiente tra sviluppo, test e produzione: i container funzionano allo stesso modo su un computer portatile come nel cloud. +* Portabilità tra cloud e sistemi operativi differenti: lo stesso container funziona su Ubuntu, RHEL, CoreOS, on-premise, Google Kubernetes Engine e da qualsiasi altra parte. +* Gestione incentrata sulle applicazioni: Aumenta il livello di astrazione dall'esecuzione di un sistema operativo su hardware virtualizzato all'esecuzione di un'applicazione su un sistema operativo utilizzando risorse logiche. +* Microservizi liberamente combinabili, distribuiti, ad alta scalabilità: le applicazioni sono suddivise in pezzi più piccoli e indipendenti che possono essere distribuite e gestite dinamicamente - niente stack monolitici che girano su una singola grande macchina. +* Isolamento delle risorse: le prestazioni delle applicazioni sono prevedibili. * Utilizzo delle risorse: alta efficienza e densità. ## Perché necessito di Kubernetes e cosa posso farci -I container sono un buon modo per raggruppare ed eseguire le applicazioni. In un ambiente di produzione, è necessario gestire i container che eseguono le applicazioni e garantire che non si verifichino tempi di inattività. Per esempio, se un container si guasta, un altro container necessita di essere riavviato. Non sarebbe più facile se questo comportamento fosse gestito direttamente da un sistema? +I container sono un buon modo per distribuire ed eseguire le tue applicazioni. In un ambiente di produzione, è necessario gestire i container che eseguono le applicazioni e garantire che non si verifichino interruzioni dei servizi. Per esempio, se un container si interrompe, è necessario avviare un nuovo container. Non sarebbe più facile se questo comportamento fosse gestito direttamente da un sistema? -È così che Kubernetes viene in soccorso! Kubernetes vi fornisce un framework per far funzionare i sistemi distribuiti in modo resiliente. Si prende cura delle vostre esigenze di scalabilità, failover, schemi di distribuzione, e altro ancora. Per esempio, Kubernetes può facilmente gestire un Canary deploument per il vostro sistema. +È proprio qui che Kubernetes viene in soccorso! Kubernetes ti fornisce un framework per far funzionare i sistemi distribuiti in modo resiliente. Kubernetes si occupa della scalabilità, failover, distribuzione delle tue applicazioni. Per esempio, Kubernetes può facilmente gestire i rilasci con modalità Canary deployment. -Kubernetes vi fornisce: +Kubernetes ti fornisce: -* **Scoperta del servizio e bilanciamento del carico** -Kubernetes può esporre un contenitore usando il nome DNS o il proprio indirizzo IP. Se il traffico verso un container è alto, Kubernetes è in grado di caricare e distribuire il traffico di rete in modo che la distribuzione rimanga stabile. -* **Orchestrazione dello stoccaggio** -Kubernetes vi permette di montare automaticamente un sistema di archiviazione di vostra scelta, come per esempio memoria locale, fornitori di cloud pubblici, e altro ancora. +* **Scoperta dei servizi e bilanciamento del carico** +Kubernetes può esporre un container usando un nome DNS o il suo indirizzo IP. Se il traffico verso un container è alto, Kubernetes è in grado di distribuire il traffico su più container in modo che il servizio rimanga stabile. +* **Orchestrazione dello storage** +Kubernetes ti permette di montare automaticamente un sistema di archiviazione di vostra scelta, come per esempio storage locale, dischi forniti da cloud pubblici, e altro ancora. * **Rollout e rollback automatizzati** -È possibile descrivere lo stato desiderato per i propri contenitori distribuiti utilizzando Kubernetes, e si può cambiare lo stato da quello attuale a quello desiderato ad una velocità stabilita e controllata. Per esempio, potete automatizzare Kubernetes per creare nuovi container per la vostra distribuzione, rimuovere i container esistenti e adottare tutte le loro risorse nel nuovo container. -* **Packing automatico dei file bin** -Kubernetes permette di specificare quanta CPU e memoria (RAM) ha bisogno ogni container. Quando i container dispongono di richieste di risorse specifiche, Kubernetes può prendere decisioni migliori per gestire le risorse per i container. -* **Auto risoluzione** -Kubernetes riavvia i container che si bloccano, sostituisce i container, termina i container che non rispondono al controllo di salute definito dall'utente, e non li distribuisce ai clienti finché non sono pronti per funzionare correttamente.. +Puoi utilizzare Kubernetes per descrivere lo stato desiderato per i propri container, e Kubernetes si occuperà di cambiare lo stato attuale per raggiungere quello desiderato ad una velocità controllata. Per esempio, puoi automatizzare Kubernetes per creare nuovi container per il tuo servizio, rimuovere i container esistenti e adattare le loro risorse a quelle richieste dal nuovo container. +* **Ottimizzazione dei carichi** +Fornisci a Kubernetes un cluster di nodi per eseguire i container. Puoi istruire Kubernetes su quanta CPU e memoria (RAM) ha bisogno ogni singolo container. Kubernetes allocherà i container sui nodi per massimizzare l'uso delle risorse a disposizione. +* **Self-healing** +Kubernetes riavvia i container che si bloccano, sostituisce container, termina i container che non rispondono agli health checks, e evita di far arrivare traffico ai container che non sono ancora pronti per rispondere correttamente. * **Gestione di informazioni sensibili e della configurazione** -Kubernetes consente di memorizzare e gestire informazioni sensibili, come le password, i token OAuth e le chiavi ssh. È possibile distribuire e aggiornare i segreti e la configurazione dell'applicazione senza dover ricostruire le immagini del container e senza rivelare segreti nella configurazione della pila. +Kubernetes consente di memorizzare e gestire informazioni sensibili, come le password, i token OAuth e le chiavi SSH. Puoi distribuire e aggiornare le informazioni sensibili e la configurazione dell'applicazione senza dover ricostruire le immagini dei container e senza svelare le informazioni sensibili nella configurazione del tuo sistema. ## Cosa non è Kubernetes -Kubernetes non è un sistema PaaS (Platform as a Service) tradizionale e completo. Dal momento che Kubernetes opera a livello di contenitore piuttosto che a livello hardware, esso fornisce alcune caratteristiche generalmente applicabili comuni alle offerte PaaS, come la distribuzione, il ridimensionamento, il bilanciamento del carico, la registrazione e il monitoraggio. Tuttavia, Kubernetes non è monolitico, e queste soluzioni predefinite sono opzionali e collegabili. Kubernetes fornisce gli elementi costitutivi per la costruzione di piattaforme di sviluppo, ma conserva la scelta e la flessibilità dell'utente dove è importante. +Kubernetes non è un sistema PaaS (Platform as a Service) tradizionale e completo. Dal momento che Kubernetes opera a livello di container piuttosto che che a livello hardware, esso fornisce alcune caratteristiche generalmente disponibili nelle offerte PaaS, come la distribuzione, il ridimensionamento, il bilanciamento del carico, la registrazione e il monitoraggio. Tuttavia, Kubernetes non è monolitico, e queste soluzioni predefinite sono opzionali ed estensibili. Kubernetes fornisce gli elementi base per la costruzione di piattaforme di sviluppo, ma conserva le scelte dell'utente e la flessibilità dove è importante. Kubernetes: -* Non limita i tipi di applicazioni supportate. Kubernetes mira a supportare una grande varietà di carichi di lavoro, compresi i carichi di lavoro senza stato, stateful e di elaborazione dati. Se un'applicazione può essere eseguita in un container, dovrebbe funzionare alla grande anche su Kubernetes. -* Non distribuisce il codice sorgente e non costruisce la vostra applicazione. I flussi di lavoro Continuous Integration, Delivery, and Deployment (CI/CD) sono determinati dalle culture e preferenze dell'organizzazione e dai requisiti tecnici. -* Non fornisce servizi a livello applicativo, come middleware (per esempio, bus di messaggi), framework di elaborazione dati (per esempio, Spark), database (per esempio, mysql), cache, né sistemi di archiviazione cluster (per esempio, Ceph) come servizi integrati. Tali componenti possono essere eseguiti su Kubernetes, e/o possono essere richiamati da applicazioni che girano su Kubernetes attraverso meccanismi portatili, come l'Open Service Broker. -* Non impone soluzioni di logging, monitoraggio o di allarme. Fornisce alcune integrazioni come test di un concetto, e meccanismi per raccogliere ed esportare le metriche. -* Non fornisce né rende obbligatorio un linguaggio/sistema di configurazione (per esempio, jsonnet). Fornisce un'API dichiarativa che può essere presa di mira da forme arbitrarie di specifiche dichiarative. -* Non fornisce né adotta alcuna configurazione completa della macchina, manutenzione, gestione o sistemi di autoguarigione. -* Inoltre, Kubernetes non è un semplice sistema di orchestrazione. Infatti, questo sistema elimina la necessità di orchestrazione. La definizione tecnica di orchestrazione è l'esecuzione di un flusso di lavoro definito: prima si fa A, poi B, poi C. Al contrario, Kubernetes è composto da un insieme di processi di controllo indipendenti e componibili che guidano costantemente lo stato attuale verso lo stato desiderato. Non dovrebbe importare come si passa dalla A alla C. Anche il controllo centralizzato non è richiesto. Questo si traduce in un sistema più facile da usare e più potente, robusto, resiliente ed estensibile. +* Non limita i tipi di applicazioni supportate. Kubernetes mira a supportare una grande varietà di carichi di lavoro, compresi i carichi di lavoro stateless, stateful e elaborazione di dati. Se un'applicazione può essere eseguita in un container, dovrebbe funzionare alla grande anche su Kubernetes. +* Non compila il codice sorgente e non crea i container. I flussi di Continuous Integration, Delivery, and Deployment (CI/CD) sono determinati dalla cultura e dalle preferenze dell'organizzazione e dai requisiti tecnici. +* Non fornisce servizi a livello applicativo, come middleware (per esempio, bus di messaggi), framework di elaborazione dati (per esempio, Spark), database (per esempio, mysql), cache, né sistemi di storage distribuito (per esempio, Ceph) come servizi integrati. Tali componenti possono essere eseguiti su Kubernetes, e/o possono essere richiamati da applicazioni che girano su Kubernetes attraverso meccanismi come l'[Open Service Broker](https://openservicebrokerapi.org/). +* Non impone soluzioni di logging, monitoraggio o di gestione degli alert. Fornisce alcune integrazioni come dimostrazione, e meccanismi per raccogliere ed esportare le metriche. +* Non fornisce né rende obbligatorio un linguaggio/sistema di configurazione (per esempio, Jsonnet). Fornisce un'API dichiarativa che può essere richiamata da qualsiasi sistema. +* Non fornisce né adotta alcun sistema di gestione completa della macchina, configurazione, manutenzione, gestione o sistemi di self healing. +* Inoltre, Kubernetes non è un semplice sistema di orchestrazione. Infatti, questo sistema elimina la necessità di orchestrazione. La definizione tecnica di orchestrazione è l'esecuzione di un flusso di lavoro definito: prima si fa A, poi B, poi C. Al contrario, Kubernetes è composto da un insieme di processi di controllo indipendenti e componibili che guidano costantemente lo stato attuale verso lo stato desiderato. Non dovrebbe importare come si passa dalla A alla C. Anche il controllo centralizzato non è richiesto. Questo si traduce in un sistema più facile da usare, più potente, robusto, resiliente ed estensibile. {{% /capture %}} {{% capture whatsnext %}} -* Dai un'occhiata alla pagina [Le Componenti di Kubernetes](/docs/concepts/overview/components/) +* Dai un'occhiata alla pagina [i componenti di Kubernetes](/docs/concepts/overview/components/) * Sai già [Come Iniziare](/docs/setup/)? {{% /capture %}} diff --git a/content/it/docs/home/_index.md b/content/it/docs/home/_index.md new file mode 100644 index 0000000000..3f8e3ae0f0 --- /dev/null +++ b/content/it/docs/home/_index.md @@ -0,0 +1,58 @@ +--- +approvers: +- chenopis +title: Documentazione di Kubernetes +noedit: true +cid: docsHome +layout: docsportal_home +class: gridPage +linkTitle: "Home" +main_menu: true +weight: 10 +hide_feedback: true +menu: + main: + title: "Documentazione" + weight: 20 + post: > +

Impara come usare Kubernetes con informazioni concettuali, guide e documentazione tecnica. Puoi anche contribuire alla documentazione!

+overview: > + Kubernetes è un motore open source di orchestrazione di containers che automatizza il deployment, la scalabilità e la gestione di applicazioni containerizzate. Il progetto open source è ospitato dalla Cloud Native Computing Foundation (CNCF). +cards: +- name: concepts + title: "Capire le basi" + description: "Impara Kubernetes e i suoi concetti fondamentali." + button: "Impara i concetti" + button_path: "/docs/concepts" +- name: tutorials + title: "Prova Kubernetes" + description: "Segui delle guide per imparare come fare il deployment di applicativi in Kubernetes." + button: "Vedi le guide" + button_path: "/docs/tutorials" +- name: setup + title: "Configura un cluster" + description: "Esegui Kubernetes sulla base delle tue risorse e necessità." + button: "Configura Kubernetes" + button_path: "/docs/setup" +- name: tasks + title: "Impara come usare Kubernetes" + description: "Impara quali sono le procedure principali e come eseguirle in pochi passaggi." + button: "Guarda le procedure" + button_path: "/docs/tasks" +- name: reference + title: Guarda le referenze + description: Naviga la terminologia, la sintassi della riga di comando, la documentazione delle API e degli strumenti di installazione. + button: Vedi le referenze + button_path: /docs/reference +- name: contribute + title: Contribuisci alla documentazione + description: Chiunque può contribuire, indipendentemente dal fatto che sia nuovo nel progetto o un utente esperto. + button: Contribuisci alla documentazione + button_path: /docs/contribute +- name: download + title: Scarica Kubernetes + description: Se stai installando Kubernetes o aggiornandolo all'ultima versione, controlla le note di rilascio per la versione corrente. +- name: about + title: Sulla documentazione + description: Questo sito contiene la documentazione per la versione corrente e le precedenti 4 versioni di Kubernetes. +--- diff --git a/content/it/docs/reference/glossary/cluster.md b/content/it/docs/reference/glossary/cluster.md new file mode 100755 index 0000000000..a8d918b00d --- /dev/null +++ b/content/it/docs/reference/glossary/cluster.md @@ -0,0 +1,17 @@ +--- +title: Cluster +id: cluster +date: 2019-06-15 +full_link: +short_description: > + Un'insieme di macchine, chiamate nodi, che eseguono container e gestite da Kubernetes. Un cluster ha almeno un Worker Node e un Control Plane Node. + +aka: +tags: +- fundamental +- operation +--- +Un'insieme di macchine, chiamate nodi, che eseguono container e gestite da Kubernetes. Un cluster ha almeno un Worker Node e un Control Plane Node. + + +Il/I Worker Node ospitano i Pod che eseguono i workload dell'utente. Il/I Control Plane Node gestiscono i Worker Node e tutto quanto accade all'interno del cluster. Per garantire la high-availability e la possibilità di failover del cluster, vengono utilizzati più Control Plane Node. diff --git a/content/it/docs/reference/glossary/container-runtime.md b/content/it/docs/reference/glossary/container-runtime.md new file mode 100644 index 0000000000..640b3eaa17 --- /dev/null +++ b/content/it/docs/reference/glossary/container-runtime.md @@ -0,0 +1,21 @@ +--- +title: Container Runtime +id: container-runtime +date: 2019-06-05 +full_link: /docs/reference/generated/container-runtime +short_description: > + Il container runtime è il software che è responsabile per l'esecuzione dei container. + +aka: +tags: +- fundamental +- workload +--- + Il container runtime è il software che è responsabile per l'esecuzione dei container. + + + +Kubernetes supporta diversi container runtimes: [Docker](http://www.docker.com), +[containerd](https://containerd.io), [cri-o](https://cri-o.io/), +[rktlet](https://github.com/kubernetes-incubator/rktlet) e tutte le implementazioni di +[Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). diff --git a/content/it/docs/reference/glossary/etcd.md b/content/it/docs/reference/glossary/etcd.md new file mode 100755 index 0000000000..595cffb3da --- /dev/null +++ b/content/it/docs/reference/glossary/etcd.md @@ -0,0 +1,21 @@ +--- +title: etcd +id: etcd +date: 2018-04-12 +full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ +short_description: > + È un database key-value altamente disponibile che è usato da Kubernetes per salvare tutte le informazioni del cluster. + +aka: +tags: +- architecture +- storage +--- + È un database key-value ridondato, che è usato da Kubernetes per salvare tutte le informazioni del cluster. + + + +Se il tuo cluster utilizza etcd per salvare le informazioni, assicurati di +avere una strategia di [backup](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) per questi dati. + +Puoi trovare informazioni dettagliate su etcd sulla [documentazione](https://etcd.io/docs/) ufficiale. diff --git a/content/it/docs/reference/glossary/kube-apiserver.md b/content/it/docs/reference/glossary/kube-apiserver.md new file mode 100755 index 0000000000..96f5ccbd23 --- /dev/null +++ b/content/it/docs/reference/glossary/kube-apiserver.md @@ -0,0 +1,23 @@ +--- +title: API server +id: kube-apiserver +date: 2018-04-12 +full_link: /docs/reference/generated/kube-apiserver/ +short_description: > + Componente della Control plane che serve le Kubernetes API. + +aka: +- kube-apiserver +tags: +- architecture +- fundamental +--- + L'API server è un componente di Kubernetes +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} che espone le Kubernetes API. +L'API server è il front end del control plane di Kubernetes. + + + +La principale implementazione di un server Kubernetes API è [kube-apiserver](/docs/reference/generated/kube-apiserver/). +kube-apiserver è progettato per scalare orizzontalmente, cioè scala aumentando il numero di istanze. +Puoi eseguire multiple istanze di kube-apiserver e bilanciare il traffico tra queste istanze. diff --git a/content/it/docs/reference/glossary/kube-controller-manager.md b/content/it/docs/reference/glossary/kube-controller-manager.md new file mode 100755 index 0000000000..32d75beeb1 --- /dev/null +++ b/content/it/docs/reference/glossary/kube-controller-manager.md @@ -0,0 +1,18 @@ +--- +title: kube-controller-manager +id: kube-controller-manager +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/ +short_description: > + Componente della Control Plane che gestisce i controller. + +aka: +tags: +- architecture +- fundamental +--- + Componente della Control Plane che gestisce {{< glossary_tooltip text="controllers" term_id="controller" >}}. + + + +Da un punto di vista logico, ogni {{< glossary_tooltip text="controller" term_id="controller" >}} è un processo separato, ma per ridurre la complessità, tutti i principali controller di Kubernetes vengono raggruppati in un unico container ed eseguiti in un singolo processo. diff --git a/content/it/docs/reference/glossary/kube-proxy.md b/content/it/docs/reference/glossary/kube-proxy.md new file mode 100755 index 0000000000..c82cd60c25 --- /dev/null +++ b/content/it/docs/reference/glossary/kube-proxy.md @@ -0,0 +1,23 @@ +--- +title: kube-proxy +id: kube-proxy +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-proxy/ +short_description: > + `kube-proxy` è un proxy eseguito su ogni nodo del cluster. + +aka: +tags: +- fundamental +- networking +--- + [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) è un +proxy eseguito su ogni nodo del cluster, responsabile della gestione dei +Kubernetes {{< glossary_tooltip term_id="service">}}. + + + +I kube-proxy mantengono le regole di networking sui nodi. +Queste regole permettono la comunicazione verso gli altri nodi del cluster o l'esterno. + +Il kube-proxy usa le librerie del sistema operativo quando possible; in caso contrario il kube-proxy gestisce il traffico direttamente. diff --git a/content/it/docs/reference/glossary/kube-scheduler.md b/content/it/docs/reference/glossary/kube-scheduler.md new file mode 100755 index 0000000000..c63ce0b056 --- /dev/null +++ b/content/it/docs/reference/glossary/kube-scheduler.md @@ -0,0 +1,18 @@ +--- +title: kube-scheduler +id: kube-scheduler +date: 2018-04-12 +full_link: /docs/reference/generated/kube-scheduler/ +short_description: > + Componente della Control Plane che controlla i pod appena creati che non hanno un nodo assegnato, e dopo averlo identificato glielo assegna. + +aka: +tags: +- architecture +--- + Componente della Control Plane che controlla i pod appena creati che non hanno un nodo assegnato, e dopo averlo identificato glielo assegna. + + + +I fattori presi in considerazioni nell'individuare un nodo a cui assegnare l'esecuzione di un Pod includono la richiesta di risorse del Pod stesso e degli altri workload presenti nel sistema, i vincoli delle hardware/software/policy, le indicazioni di affinity e di anti-affinity, requisiti relativi alla disponibilità di dati/Volumes, le interferenze tra diversi workload e le scadenze. + diff --git a/content/it/docs/reference/glossary/kubelet.md b/content/it/docs/reference/glossary/kubelet.md new file mode 100755 index 0000000000..23908670c6 --- /dev/null +++ b/content/it/docs/reference/glossary/kubelet.md @@ -0,0 +1,19 @@ +--- +title: Kubelet +id: kubelet +date: 2018-04-12 +full_link: /docs/reference/generated/kubelet +short_description: > + Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod. + +aka: +tags: +- fundamental +- core-object +--- + Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod. + + + +La kubelet riceve un set di PodSpecs che vengono forniti attraverso vari meccanismi, e si assicura che i container descritti in questi PodSpecs funzionino correttamente e siano sani. La kubelet non gestisce i container che non sono stati creati da Kubernetes. + diff --git a/content/it/includes/federation-deprecation-warning-note.md b/content/it/includes/federation-deprecation-warning-note.md index 27c525642c..d0783ecdab 100644 --- a/content/it/includes/federation-deprecation-warning-note.md +++ b/content/it/includes/federation-deprecation-warning-note.md @@ -1,5 +1,3 @@ -L'uso di `Federation v1` è fortemente sconsigliato. `Federation V1` ha ormai raggiunto lo stato GA e non è più in -fase di sviluppo attivo. La documentazione è solo per scopi storici. +L'uso di `Federation v1` è fortemente sconsigliato. `Federation V1` non ha mai raggiunto lo stato GA e non è più in fase di sviluppo attivo. La documentazione è solo per scopi storici. -Per ulteriori informazioni, il seguente link -[Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2). +Per ulteriori informazioni, vedi la documentazione per il suo successore [Kubernetes Federation v2](https://github.com/kubernetes-sigs/federation-v2). diff --git a/content/it/partners/_index.html b/content/it/partners/_index.html index f78d1fe734..270dabe569 100644 --- a/content/it/partners/_index.html +++ b/content/it/partners/_index.html @@ -1,134 +1,43 @@ --- -title: Partners -bigheader: Kubernetes Partners -abstract: Growing the Kubernetes ecosystem. +title: Partner +bigheader: I partner di Kubernetes +abstract: Far crescere l'ecosistema di Kubernetes. class: gridPage cid: partners ---
-
-
Kubernetes collabora con i partner per creare una base di codice forte e vivace che supporti uno spettro di piattaforme complementari.
-
-
-
- - -
-
-
Kubernetes lavora in collaborazione con diversi partner al fine di creare un codice dalla base forte e dinamica che supporti uno spettro di piattaforme complementari.
+
+
Kubernetes collabora con i partner per creare per creare un codebase che supporti uno spettro di piattaforme complementari.
- Fornitori di Servizi Certificati Kubernetes + Fornitori Certificati di Servizi su Kubernetes
-
Fornitori di servizi controllati con grande esperienza nell'aiutare le imprese ad adottare con successo Kubernetes. +
Fornitori di servizi riconosciuti e con grande esperienza nell'aiutare le imprese ad adottare con successo Kubernetes.


- -

Interessato a diventare partner KCSP? + +

Interessato a diventare un partner KCSP?
- Distribuzioni Kubernetes Certificate, Piattaforme Hosted e Installers -
La conformità del software assicura che la versione di Kubernetes di ogni fornitore supporti le API richieste. + Distribuzioni di Kubernetes Certificate, Certified Hosted Platforms and Software di installazione Certificati + La conformità del software assicura che le versioni di Kubernetes prodotte da ogni fornitore supportino coerentemente le API necessarie.


- -

Interessato a diventare partner Certificati Kubernetes? + +

Interessato a diventare un partner certificato Kubernetes?
-
Partner per la Formazione Kubernetes
-
Professionisti esperti e certificati, con solida esperienza nella formazione tecnologica Cloud Native. - -

Interessato a diventare partner KTP? -
-
-
- - - -
- - -
- -
-
- - - - -> - Fornitori di servizi certificati Kubernetes - -
Fornitori di servizi con una grande esperienza nell'aiutare le imprese ad adottare con successo Kubernetes. -


- -

Interessato a diventare un KCSP? -
-
-
-
-
- Distribuzioni certificate di Kubernetes, piattaforme hosted e installer -
La conformità del software garantisce che la versione di Kubernetes di ogni fornitore supporti le API richieste. -


- -

Interessato a diventare un Certificato Kubernetes? -
-
-
-
-
Partner di formazione di Kubernetes
-
Fornitori di formazione con esperienza che hanno una profonda esperienza nella formazione della tecnologia cloud nativa. +
Partner per la Formazione su Kubernetes
+
Professionisti riconosciuti e certificati, con solida esperienza nella formazione su tecnologie Cloud Native.



- -

Interessato a diventare un KTP? + +

Interessato a diventare un partner KTP?
@@ -166,7 +75,7 @@ cid: partners
- +
diff --git a/content/it/training/_index.html b/content/it/training/_index.html new file mode 100644 index 0000000000..9a2cd6f969 --- /dev/null +++ b/content/it/training/_index.html @@ -0,0 +1,118 @@ +--- +title: Formazione +bigheader: Formazione e Certificazioni Kubernetes +abstract: Programmi di formazioni, certificazioni e partner. +layout: basic +cid: training +class: training +--- + +
+
+
+
+ +
+
+ +
+
+

Costruisci la tua carriera nel mondo Cloud Native

+

Kubernetes è un elemento importante del mondo Cloud Native. La formazione e le certificazioni della The Linux Foundation e dei nostri partner ti permettono di investire nella tua carriera, imparare Kubernetes, e aver successo nei tuoi progetti Cloud Native.

+
+
+
+
+ +
+
+
+

Fai un corso gratuito su edX

+
+
+
+
+
+ Introduzione a Kubernetes
  +
+

Vuoi imparare Kubernetes? Ottieni delle solide fondamenta su questo potente sistema di gestione di applicazioni deployate in container.

+
+ Vai al corso +
+
+
+
+
+ Introduzione alla gestione delle infrastutture IT in Cloud +
+

Impara le basi per creare e gestire tecnologie cloud direttamente dalla The Linux Foundation, il leader nel mondo open source.

+
+ Vai al corso +
+
+
+
+
+ Introduzione a Linux +
+

Non hai mai imparato Linux? Hai bisogno di un ripasso? Sviluppa una buona conoscenza delle varie famiglie di distribuzioni Linux usando sia l'interfaccia grafica che la linea di comando.

+
+ Vai al corso +
+
+
+
+ +
+
+
+

Impara con la The Linux Foundation

+

La The Linux Foundation offre corsi con un docente e corsi da fare in autonomia per apprendere lo sviluppo di applicativi per Kubernetes e per l'amministrazione della piattaforma stessa.

+

+ Vedi i corsi +
+
+
+ +
+
+
+

Certificati Kubernetes

+
+
+
+
+
+ Certified Kubernetes Application Developer (CKAD) +
+

L'esame "Certified Kubernetes Application Developer" certifica che la persona è in grado di progettare, costruire, configurare, e rilasciare in produzione un applicativo Cloud Native su Kubernetes.

+
+ Vai alla certificazione +
+
+
+
+
+ Certified Kubernetes Administrator (CKA) +
+

Il programma "Certified Kubernetes Administrator" assicura che la persona ha le capacità, conoscenze, e competenze per operare come amministratore di Kubernets.

+
+ Vai alla certificazione +
+
+
+
+
+ +
+
+
+

Partner per la formazione Kubernetes

+

La nostra rete di Kubernetes Training Partners fornisce servizi di formazione su Kubernetes e sui progetti Cloud Native.

+
+
+
+ + +
+
diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index c143b291c5..4556752eae 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -30,7 +30,7 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ この仕組みはある問題を引き起こします。もし、あるPodのセット(ここでは"バックエンド"と呼びます)がクラスター内で他のPodのセット(ここでは"フロントエンド"と呼びます)に対して機能を提供する場合、フロントエンドのPodがワークロードにおけるバックエンドを使用するために、バックエンドのPodのIPアドレスを探し出したり、記録し続けるためにはどうすればよいでしょうか? -ここで_Service_ について説明します。 +ここで _Service_ について説明します。 ## Serviceリソース {#service-resource} diff --git a/content/ja/docs/concepts/workloads/controllers/statefulset.md b/content/ja/docs/concepts/workloads/controllers/statefulset.md index f3a5dfd394..90de9d1a40 100644 --- a/content/ja/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ja/docs/concepts/workloads/controllers/statefulset.md @@ -131,7 +131,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain 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 >}} -クラスタードメインは[その他の設定](/docs/concepts/services-networking/dns-pod-service/#how-it-works)がされない限り、`cluster.local`にセットされます。 +クラスタードメインは[その他の設定](/docs/concepts/services-networking/dns-pod-service/)がされない限り、`cluster.local`にセットされます。 {{< /note >}} ### 安定したストレージ 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 44d136f60b..60429629af 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 @@ -64,7 +64,7 @@ To deploy a Windows container on Kubernetes, you must first create an example ap - -command - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows ``` {{< note >}} @@ -113,8 +113,8 @@ Users today need to use some combination of taints and node selectors in order t 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: -* beta.kubernetes.io/os = [windows|linux] -* beta.kubernetes.io/arch = [amd64|arm64|...] +* kubernetes.io/os = [windows|linux] +* kubernetes.io/arch = [amd64|arm64|...] If a Pod specification does not specify a nodeSelector like `"beta.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. diff --git a/content/ja/docs/tutorials/hello-minikube.md b/content/ja/docs/tutorials/hello-minikube.md index 428175e21e..807d15ce77 100644 --- a/content/ja/docs/tutorials/hello-minikube.md +++ b/content/ja/docs/tutorials/hello-minikube.md @@ -70,7 +70,7 @@ Kubernetesの[*Pod*](/ja/docs/concepts/workloads/pods/pod/) は、コンテナ 1. `kubectl create` コマンドを使用してPodを管理するDeploymentを作成してください。Podは提供されたDockerイメージを元にコンテナを実行します。 ```shell - kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node + kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4 ``` 2. Deploymentを確認します: diff --git a/content/ja/examples/windows/configmap-pod.yaml b/content/ja/examples/windows/configmap-pod.yaml index e30939b367..661cb73dee 100644 --- a/content/ja/examples/windows/configmap-pod.yaml +++ b/content/ja/examples/windows/configmap-pod.yaml @@ -28,4 +28,4 @@ spec: name: example-config key: example.property.2 nodeSelector: - beta.kubernetes.io/os: windows \ No newline at end of file + kubernetes.io/os: windows \ No newline at end of file diff --git a/content/ja/examples/windows/daemonset.yaml b/content/ja/examples/windows/daemonset.yaml index d3a7bb6636..7483708fc7 100644 --- a/content/ja/examples/windows/daemonset.yaml +++ b/content/ja/examples/windows/daemonset.yaml @@ -17,5 +17,5 @@ spec: - name: foo image: microsoft/windowsservercore:1709 nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows diff --git a/content/ja/examples/windows/emptydir-pod.yaml b/content/ja/examples/windows/emptydir-pod.yaml index e164f2caeb..08d8091391 100644 --- a/content/ja/examples/windows/emptydir-pod.yaml +++ b/content/ja/examples/windows/emptydir-pod.yaml @@ -17,4 +17,4 @@ spec: - name: scratch-volume emptyDir: {} nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows diff --git a/content/ja/examples/windows/hostpath-volume-pod.yaml b/content/ja/examples/windows/hostpath-volume-pod.yaml index 843250c80c..d95e345b6c 100644 --- a/content/ja/examples/windows/hostpath-volume-pod.yaml +++ b/content/ja/examples/windows/hostpath-volume-pod.yaml @@ -11,7 +11,7 @@ spec: mountPath: "C:\\etc\\foo" readOnly: true nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows volumes: - name: foo hostPath: diff --git a/content/ja/examples/windows/secret-pod.yaml b/content/ja/examples/windows/secret-pod.yaml index f4a8122c0a..69ee9b1f1e 100644 --- a/content/ja/examples/windows/secret-pod.yaml +++ b/content/ja/examples/windows/secret-pod.yaml @@ -29,4 +29,4 @@ spec: name: mysecret key: password nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index 734a2cd1a0..83bc1d246c 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -1,20 +1,21 @@ --- -title: 클라우트 컨트롤러 매니저 기반에 관한 개념 +title: 클라우드 컨트롤러 매니저 content_template: templates/concept weight: 40 --- {{% capture overview %}} -클라우드 컨트롤러 매니저(CCM) 개념(바이너리와 혼동하지 말 것)은 본래 클라우드 벤더에 특화된 코드와 쿠버네티스 코어가 상호 독립적으로 진화할 수 있도록 해주기 위해 생성되었다. 클라우드 컨트롤러 매니저는 쿠버네티스 컨트롤러 매니저, API 서버, 그리고 스케줄러와 같은 다른 마스터 컴포넌트와 함께 동작된다. 또한 쿠버네티스 위에서 동작하는 경우에는, 쿠버네티스 애드온으로서 구동된다. +{{< feature-state state="beta" for_k8s_version="v1.11" >}} -클라우드 컨트롤러 매니저의 디자인은 새로운 클라우드 제공사업자가 플러그인을 이용하여 쉽게 쿠버네티스와 함께 통합하도록 허용해 주는 플러그인 메커니즘을 토대로 한다. 쿠버네티스에 새로운 클라우드 제공사업자를 적응시키기 위한 그리고 기존 모델에서 새로운 CCM 모델로 클라우드 제공사업자들이 전환을 이루기 위한 준비된 계획들이 있다. +클라우드 인프라스트럭쳐 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다. +쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭쳐를 +신뢰한다. -이 문서는 클라우드 컨트롤러 매니저 이면상의 개념들을 논의하고 그것과 연관된 기능들에 대한 세부적인 사항들을 제시한다. +{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="클라우드 컨트롤러 매니저는">}} -다음은 클라우드 컨트롤러 매니저가 존재하지 않는 형태의 쿠버네티스 클러스터 아키텍처이다. - -![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png) +클라우드 컨트롤러 매니저는 다양한 클라우드 공급자가 자신의 +플랫폼에 쿠버네티스를 통합할 수 있도록 하는 플러그인 메커니즘을 사용해서 구성된다. {{% /capture %}} @@ -23,91 +24,69 @@ weight: 40 ## 디자인 -이전 다이어그램에서, 쿠버네티스와 클라우드 제공사업자는 여러 상이한 컴포넌트들을 통해 통합되었다. +![쿠버네티스 컴포넌트](/images/docs/components-of-kubernetes.png) -* Kubelet -* 쿠버네티스 컨트롤러 매니저 -* 쿠버네티스 API 서버 - -CCM은 앞의 세 컴포넌트가 가진 클라우드 의존적인 로직을 한 곳에 모아서 클라우드 통합을 위한 단일 포인트를 만들었다. CCM을 활용한 새로운 아키텍처는 다음과 같다. - -![CCM Kube Arch](/images/docs/post-ccm-arch.png) - -## CCM의 컴포넌트 - -CCM은 쿠버네티스 컨트롤러 매니저(KCM)의 기능 일부를 독립시키고 분리된 프로세스로서 그것을 작동시킨다. 특히, 클라우드 종속적인 KCM 내 컨트롤러들을 독립시킨다. KCM은 다음과 같은 클라우드 종속적인 컨트롤러 루프를 가진다. - - * 노드 컨트롤러 - * 볼륨 컨트롤러 - * 라우트 컨트롤러 - * 서비스 컨트롤러 - -버전 1.9 에서, CCM은 이전 리스트로부터 다음의 컨트롤러를 작동시킨다. - -* 노드 컨트롤러 -* 라우트 컨트롤러 -* 서비스 컨트롤러 +클라우드 컨트롤러 매니저는 컨트롤 플레인에서 복제된 프로세스의 집합으로 실행된다(일반적으로, +파드의 컨테이너). 각 클라우드 컨트롤러 매니저는 단일 +프로세스에 여러 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 +구현한다. {{< note >}} -볼륨 컨트롤러는 의도적으로 CCM의 일부가 되지 않도록 선택되었다. 연관된 복잡성 때문에 그리고 벤더 특유의 볼륨 로직 개념을 일반화 하기 위한 기존의 노력때문에, 볼륨 컨트롤러는 CCM으로 이전되지 않도록 결정되었다. +또한 사용자는 클라우드 컨트롤러 매니저를 컨트롤 플레인의 일부가 아닌 쿠버네티스 +{{< glossary_tooltip text="애드온" term_id="addons" >}}으로 +실행할 수도 있다. {{< /note >}} -CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 [Flex](/ko/docs/concepts/storage/volumes/#flexVolume) 볼륨을 사용하기 위한 것이었다. 그러나, [CSI](/ko/docs/concepts/storage/volumes/#csi)라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다. +## 클라우드 컨트롤러 매니저의 기능 {#functions-of-the-ccm} -이러한 역동성을 고려하여, CSI가 준비될 때까지 차이점에 대한 측정은 도중에 중지하기로 결정하였다. - -## CCM의 기능 - -CCM은 클라우드 제공사업자에 종속적인 쿠버네티스 컴포넌트로부터 그 속성을 상속받는다. 이번 섹션은 그러한 컴포넌트를 근거로 구성되었다. - -### 1. 쿠버네티스 컨트롤러 매니저 - -CCM의 주요 기능은 KCM으로부터 파생된다. 이전 섹션에서 언급한 바와 같이, CCM은 다음의 컨트롤러 루프를 작동시킨다. - -* 노드 컨트롤러 -* 라우트 컨트롤러 -* 서비스 컨트롤러 - -#### 노드 컨트롤러 - -노드 컨트롤러는 클라우드 제공사업자의 클러스터에서 동작중인 노드에 대한 정보를 얻음으로써 노드를 초기화할 책임을 가진다. 노드 컨트롤러는 다음 기능을 수행한다. - -1. 클라우드 특유의 영역/지역 레이블을 이용한 노드를 초기화한다. -2. 클라우드 특유의 인스턴스 세부사항, 예를 들어, 타입 그리고 크기 등을 이용한 노드를 초기화한다. -3. 노드의 네트워크 주소와 호스트네임을 취득한다. -4. 노드가 무응답일 경우, 클라우드로부터 해당 노드가 삭제된 것인지 확인한다. 클라우드로부터 삭제된 것이라면, 쿠버네티스 노드 오브젝트를 삭제한다. - -#### 라우트 컨트롤러 - -라우트 컨트롤러는 클라우드에서 적합하게 경로를 구성하는 책임을 가지며 쿠버네티스 클러스터 내 상이한 노드 상의 컨테이너들이 상호 소통할 수 있도록 해준다. 라우트 컨트롤러는 오직 Google Compute Engine 클러스터에서만 적용가능 하다. - -#### 서비스 컨트롤러 - -서비스 컨트롤러는 서비스 생성, 업데이트, 그리고 이벤트 삭제에 대한 책임을 가진다. 쿠버네티스 내 서비스의 현재 상태를 근거로, 쿠버네티스 내 서비스의 상태를 나타내기 위해 클라우드 로드 밸런서(ELB, Google LB, Oracle Cloud Infrastrucuture LB와 같은)를 구성해준다. 추가적으로, 클라우드 로드 밸런서를 위한 서비스 백엔드가 최신화 되도록 보장해 준다. - -### 2. Kubelet - -노드 컨트롤러는 kubelet의 클라우드 종속적인 기능을 포함한다. CCM이 도입되기 이전에는, kubelet 이 IP 주소, 지역/영역 레이블 그리고 인스턴스 타입 정보와 같은 클라우드 특유의 세부사항으로 노드를 초기화하는 책임을 가졌다. CCM의 도입으로 kubelet에서 CCM으로 이 초기화 작업이 이전되었다. - -이 새로운 모델에서, kubelet은 클라우드 특유의 정보 없이 노드를 초기화 해준다. 그러나, kubelet은 새로 생성된 노드에 taint를 추가해서 CCM이 클라우드에 대한 정보를 가지고 노드를 초기화하기 전까지는 스케줄되지 않도록 한다. 그러고 나서 이 taint를 제거한다. - -## 플러그인 메커니즘 - -클라우드 컨트롤러 매니저는 어떠한 클라우드에서든지 플러그 인 되어 구현될 수 있도록 Go 인터페이스를 이용한다. 구체적으로, [여기](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)에 정의된 CloudProvider 인터페이스를 이용한다. - -위에서 강조되었던 4개의 공유 컨트롤러의 구현, 그리고 공유 cloudprovider 인터페이스와 더불어 일부 골격은 쿠버네티스 코어 내에 유지될 것이다. 클라우드 제공사업자 특유의 구현은 코어의 외부에 탑재되어 코어 내에 정의된 인터페이스를 구현할 것이다. - -개발 중인 플러그인에 대한 보다 자세한 정보는, [클라우드 컨트롤러 매니저 개발하기](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)를 참고한다. - -## 인가 - -이 섹션은 CCM에 의해 작업을 수행하기 위해 다양한 API 오브젝트에서 요구되는 접근에 대해 구분해 본다. +클라우드 컨틀롤러 매니저의 내부 컨트롤러에는 다음 컨트롤러들이 포함된다. ### 노드 컨트롤러 -노드 컨트롤러는 오직 노드 오브젝트와 동작한다. 노드 오브젝트를 get, list, create, update, patch, watch, 그리고 delete 하기 위한 모든 접근을 요한다. +노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 {{< glossary_tooltip text="노드" term_id="node" >}} +오브젝트를 생성하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 +테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다. -v1/Node: +1. 컨트롤러가 클라우드 공급자 API를 통해 찾아내는 각 서버에 대해 노드 오브젝트를 초기화한다. +2. 클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를 + 사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다. +3. 노드의 호스트 이름과 네트워크 주소를 가져온다. +4. 노드의 상태를 확인한다. 노드가 응답하지 않는 경우, 이 컨트롤러는 사용자가 + 이용하는 클라우드 공급자의 API를 통해 서버가 비활성화됨 / 삭제됨 / 종료됨인지 확인한다. + 노드가 클라우드에서 삭제된 경우, 컨트롤러는 사용자의 쿠버네티스 클러스터에서 노드 + 오브젝트를 삭제한다. + +일부 클라우드 공급자의 구현에서는 이를 노드 컨트롤러와 별도의 노드 +라이프사이클 컨트롤러로 분리한다. + +### 라우트 컨트롤러 + +라우트 컨트롤러는 사용자의 쿠버네티스 클러스터의 다른 노드에 +있는 각각의 컨테이너가 서로 통신할 수 있도록 클라우드에서 +라우트를 적절히 구성해야 한다. + +클라우드 공급자에 따라 라우트 컨트롤러는 파드 네트워크 +IP 주소 블록을 할당할 수도 있다. + +### 서비스 컨트롤러 + +{{< glossary_tooltip text="서비스" term_id="service" >}} 는 관리형 로드 밸런서, +IP 주소, 네트워크 패킷 필터링 그리고 대상 상태 확인과 같은 +클라우드 인프라스트럭처 컴포넌트와 통합된다. 서비스 컨트롤러는 사용자의 클라우드 +공급자 API와 상호 작용해서 필요한 서비스 리소스를 선언할 때 +로드 밸런서와 기타 인프라스트럭처 컴포넌트를 설정한다. + +## 인가 + +이 섹션에서는 클라우드 컨트롤러 매니저가 작업을 수행하기 위해 +다양한 API 오브젝트에 필요한 접근 권한을 세분화한다. + +### 노드 컨트롤러 {#authorization-node-controller} + +노드 컨트롤러는 노드 오브젝트에서만 작동한다. 노드 오브젝트를 읽고, +수정하려면 전체 접근 권한이 필요하다. + +`v1/Node`: - Get - List @@ -117,23 +96,24 @@ v1/Node: - Watch - Delete -### 라우트 컨트롤러 +### 라우트 컨트롤러 {#authorization-route-controller} -라우트 컨트롤러는 노드 오브젝트 생성에 대해 귀기울이고 적절하게 라우트를 구성한다. 노드 오브젝트에 대한 get 접근을 요한다. +라우트 컨트롤러가 노드 오브젝트의 생성을 수신하고 적절하게 +라우트를 구성한다. 노드 오브젝트에 대한 접근 권한이 필요하다. -v1/Node: +`v1/Node`: - Get -### 서비스 컨트롤러 +### 서비스 컨트롤러 {#authorization-service-controller} -서비스 컨트롤러는 서비스 오브젝트 create, update 그리고 delete에 대해 귀기울이고, 서비스를 위해 적절하게 엔드포인트를 구성한다. +서비스 컨트롤러는 서비스 오브젝트 생성, 업데이트 그리고 삭제 이벤트를 수신한 다음 해당 서비스에 대한 엔드포인트를 적절하게 구성한다. -서비스에 접근하기 위해, list, 그리고 watch 접근을 요한다. 서비스 update를 위해 patch와 update 접근을 요한다. +서비스에 접근하려면, 목록과 감시 접근 권한이 필요하다. 서비스를 업데이트하려면, 패치와 업데이트 접근 권한이 필요하다. -서비스에 대한 엔드포인트 설정을 위해, create, list, get, watch, 그리고 update를 하기위한 접근을 요한다. +서비스에 대한 엔드포인트 리소스를 설정하려면 생성, 목록, 가져오기, 감시 그리고 업데이트에 대한 접근 권한이 필요하다. -v1/Service: +`v1/Service`: - List - Get @@ -141,21 +121,22 @@ v1/Service: - Patch - Update -### 그 외의 것들 +### 그 외의 것들 {#authorization-miscellaneous} -CCM의 코어에 대한 구현은 이벤트를 create 하고, 보안 작업을 보장하기 위한 접근을 요하며, ServiceAccount를 create 하기 위한 접근을 요한다. +클라우드 컨트롤러 매니저의 핵심 구현을 위해 이벤트 오브젝트를 생성하고, 안전한 작동을 보장하기 위해 서비스어카운트(ServiceAccounts)를 생성해야 한다. -v1/Event: +`v1/Event`: - Create - Patch - Update -v1/ServiceAccount: +`v1/ServiceAccount`: - Create -CCM에 대한 RBAC ClusterRole은 다음과 같다. +클라우드 컨트롤러 매니저의 {{< glossary_tooltip term_id="rbac" text="RBAC" >}} +클러스터롤(ClusterRole)은 다음과 같다. ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -219,24 +200,16 @@ rules: - update ``` -## 벤더 구현사항 - -다음은 클라우드 제공사업자들이 구현한 CCM들이다. - -* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud) -* [AWS](https://github.com/kubernetes/cloud-provider-aws) -* [Azure](https://github.com/kubernetes/cloud-provider-azure) -* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) -* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) -* [GCP](https://github.com/kubernetes/cloud-provider-gcp) -* [Hetzner](https://github.com/hetznercloud/hcloud-cloud-controller-manager) -* [Linode](https://github.com/linode/linode-cloud-controller-manager) -* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack) -* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) -* [TencentCloud](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager) - -## 클러스터 관리 - -CCM을 구성하고 작동하기 위한 전체 안내는 [여기](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)에서 제공된다. - +{{% /capture %}} +{{% capture whatsnext %}} +[클라우드 컨트롤러 매니저 관리](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)에는 +클라우드 컨트롤러 매니저의 실행과 관리에 대한 지침이 있다. + +자체 클라우드 컨트롤러 매니저를 구현하거나 기존 프로젝트를 확장하는 방법을 알고 싶은가? + +클라우드 컨트롤러 매니저는 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` 인터페이스를 사용한다. + +이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 `CloudProvider` 인터페이스를 구현한다. + +플러그인 개발에 대한 자세한 내용은 [클라우드 컨트롤러 매니저 개발하기](/docs/tasks/administer-cluster/developing-cloud-controller-manager/)를 참조한다. {{% /capture %}} diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md new file mode 100644 index 0000000000..a037452ef3 --- /dev/null +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -0,0 +1,66 @@ +--- +title: 컨트롤 플레인-노드 간 통신 +content_template: templates/concept +weight: 20 +aliases: +- master-node-communication +--- + +{{% capture overview %}} + +이 문서는 컨트롤 플레인(실제로는 API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다. + +{{% /capture %}} + +{{% capture body %}} + +## 노드에서 컨트롤 플레인으로의 통신 +노드에서 컨트롤 플레인까지의 모든 통신 경로는 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)이 허용되는 경우, 하나 이상의 [권한 부여](/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다. + +노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다. + +API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증서와 유효한 베어러 토큰(bearer token)을 파드가 인스턴스화될 때 파드에 자동으로 주입하도록 서비스 어카운트를 활용하여 안전하게 연결할 수 있다. +`kubernetes` 서비스(모든 네임스페이스의)는 API 서버의 HTTPS 엔드포인트로 리디렉션되는 가상 IP 주소(kube-proxy를 통해)로 구성되어 있다. + +컨트롤 플레인 컴포넌트는 보안 포트를 통해 클러스터 API 서버와도 통신한다. + +결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다. + +## 컨트롤 플레인에서 노드로의 통신 +컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다. + +### API 서버에서 kubelet으로의 통신 +API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. + +* 파드에 대한 로그를 가져온다. +* 실행 중인 파드에 (kubectl을 통해) 연결한다. +* kubelet의 포트-포워딩 기능을 제공한다. + +이 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 서빙(serving) 인증서를 확인하지 않으므로, 연결이 중간자(man-in-the-middle) 공격의 대상이 되며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **안전하지 않다** . + +이 연결을 확인하려면, `--kubelet-certificate-authority` 플래그를 사용하여 API 서버에 kubelet의 서빙 인증서를 확인하는 데 사용할 루트 인증서 번들을 제공한다. + +이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](/ko/docs/concepts/architecture/control-plane-node-communication/#ssh-터널)을 +사용한다. + +마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다. + +### API 서버에서 노드, 파드 및 서비스로의 통신 + +API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않으므로 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** . + +### SSH 터널 + +쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다. +이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다. + +SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다. + +### Konnectivity 서비스 +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 연결을 유지한다. +그런 다음 컨트롤 플레인에서 노드로의 모든 트래픽은 이 연결을 통과한다. + +클러스터에서 설정하는 방법에 대해서는 [Konnectivity 서비스 설정](/docs/tasks/setup-konnectivity/)을 참조한다. diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 28bee667be..b8c6556b2a 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -52,7 +52,7 @@ weight: 30 작업을 수행한 다음 중지하는 쿠버네티스 리소스 이다. -(일단 [스케줄되면](/ko/docs/concepts/scheduling/), 파드 오브젝트는 kubelet +(일단 [스케줄되면](/ko/docs/concepts/scheduling-eviction/), 파드 오브젝트는 kubelet 의 의도한 상태 중 일부가 된다.) 잡 컨트롤러가 새로운 작업을 확인하면, 클러스터 어딘가에서 diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md new file mode 100644 index 0000000000..d4a7ebf9e1 --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -0,0 +1,57 @@ +--- +title: 애드온 설치 +content_template: templates/concept +--- + +{{% capture overview %}} + + +애드온은 쿠버네티스의 기능을 확장한다. + +이 페이지는 사용 가능한 일부 애드온과 관련 설치 지침 링크를 나열한다. + +각 섹션의 애드온은 알파벳 순으로 정렬되어 있다. 순서는 우선 순위와는 상관없다. + +{{% /capture %}} + + +{{% capture body %}} + +## 네트워킹과 네트워크 폴리시 + + +* [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다. +* [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](http://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](http://github.com/contiv)이다. [인스톨러](http://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다. +* [Contrail](http://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)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. +* [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. +* [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다. +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다. +* [Romana](http://romana.io)는 [네트워크폴리시 API](/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다. +* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다. + +## 서비스 검색 + +* [CoreDNS](https://coredns.io)는 유연하고 확장 가능한 DNS 서버로, 파드를 위한 클러스터 내 DNS로 [설치](https://github.com/coredns/deployment/tree/master/kubernetes)할 수 있다. + +## 시각화 & 제어 + +* [대시보드](https://github.com/kubernetes/dashboard#kubernetes-dashboard)는 쿠버네티스를 위한 대시보드 웹 인터페이스이다. +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s)는 컨테이너, 파드, 서비스 등을 그래픽으로 시각화하는 도구이다. [Weave Cloud 어카운트](https://cloud.weave.works/)와 함께 사용하거나 UI를 직접 호스팅한다. + +## 인프라스트럭처 + +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)는 쿠버네티스에서 가상 머신을 실행하기 위한 애드온이다. 일반적으로 베어 메탈 클러스터에서 실행한다. + +## 레거시 애드온 + +더 이상 사용되지 않는 [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) 디렉터리에 다른 여러 애드온이 문서화되어 있다. + +잘 관리된 것들이 여기에 연결되어 있어야 한다. PR을 환영한다! + +{{% /capture %}} diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md new file mode 100644 index 0000000000..7696321645 --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/cloud-providers.md @@ -0,0 +1,414 @@ +--- +title: 클라우드 제공자 +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} +이 페이지에서는 특정 클라우드 제공자에서 실행 중인 쿠버네티스를 관리하는 방법에 +대해 설명한다. +{{% /capture %}} + + +{{% capture body %}} +### kubeadm +[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)은 쿠버네티스 클러스터를 생성하는 데 많이 사용하는 옵션이다. +kubeadm에는 클라우드 제공자에 대한 구성 정보를 지정하는 구성 옵션이 있다. 예를 들어 +kubeadm을 사용하여 일반적인 인-트리(in-tree) 클라우드 제공자를 아래와 같이 구성할 수 있다. + +```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](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) +및 [kubelet](/docs/admin/kubelet/)의 커맨드 라인에 지정된 `--cloud-provider` 와 `--cloud-config` 가 모두 필요하다. +각 제공자에 대해 `--cloud-config` 에 지정된 파일의 내용도 아래에 설명되어 있다. + +모든 외부 클라우드 제공자의 경우, 아래 제공자에 대한 제목 아래에 있는 개별 리포지터리의 지침을 따르거나, +[모든 리포지터리 목록](https://github.com/kubernetes?q=cloud-provider-&type=&language=)을 볼 수 있다 + +## AWS +이 섹션에서는 Amazon Web Services에서 쿠버네티스를 실행할 때 사용할 수 있는 +모든 구성에 대해 설명한다. + +이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)이다. + +### 노드 이름 + +AWS 클라우드 제공자는 AWS 인스턴스의 프라이빗 DNS 이름을 쿠버네티스 노드 오브젝트의 이름으로 사용한다. + +### 로드 밸런서 +아래와 같이 어노테이션을 구성하여 AWS의 특정 기능을 사용하도록 +[외부 로드 밸런서](/docs/tasks/access-application-cluster/create-external-load-balancer/)를 설정할 수 있다. + +```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 #이 값을 교체한다 + 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`: 서비스에서 리스너 뒤의 백엔드(파드)가 언급한 프로토콜을 지정하는 데 사용된다. 만약 `http` (기본값) 또는 `https` 인 경우, 연결을 종료하고 헤더를 파싱하는 HTTPS 리스너가 생성된다. `ssl` 이나 `tcp` 로 설정된 경우, "원시(raw)" SSL 리스너가 사용된다. `http` 로 설정하고 `aws-load-balancer-ssl-cert` 를 사용하지 않았다면 HTTP 리스너가 사용된다. +* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: 서비스에서 보안 리스너를 요청하는 데 사용된다. 값은 유효한 인증서 ARN이다. 자세한 내용은, [ELB 리스너 구성](https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/classic/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`: 서비스에서 연결 드레이닝(draining)을 활성화하거나 비활성화하는 데 사용된다. +* `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` 로 재정의된) 호스트 이름(hostname)을 사용한다. +참고로 쿠버네티스 노드 이름은 Azure VM 이름과 일치해야 한다. + +## CloudStack + +이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)이다. + +### 노드 이름 + +CloudStack 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. +참고로 쿠버네티스 노드 이름은 CloudStack VM 이름과 일치해야 한다. + +## GCE + +이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)이다. + +### 노드 이름 + +GCE 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. +참고로 쿠버네티스 노드 이름의 첫 번째 세그먼트는 GCE 인스턴스 이름과 일치해야 한다(예: `kubernetes-node-2.c.my-proj.internal` 이름이 지정된 노드는 `kubernetes-node-2` 이름이 지정된 인스턴스에 해당해야 함). + +## OpenStack +이 섹션에서는 쿠버네티스와 함께 OpenStack을 사용할 때 사용할 수 있는 +모든 구성에 대해 설명한다. + +이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)이다. + +### 노드 이름 + +OpenStack 클라우드 제공자는 (OpenStack 메타데이터에서 결정한) 인스턴스 이름을 쿠버네티스 노드 오브젝트의 이름으로 사용한다. +참고로 kubelet이 노드 오브젝트를 성공적으로 등록하려면 인스턴스 이름이 유효한 쿠버네티스 노드 이름이어야 한다. + +### 서비스 + +쿠버네티스에 대한 +OpenStack 클라우드 제공자 구현은 사용 가능한 경우 기본 클라우드에서 +이러한 OpenStack 서비스 사용을 지원한다. + +| 서비스 | API 버전 | 필수 | +|--------------------------|----------------|----------| +| 블록 스토리지 (Cinder) | V1†, V2, V3 | 아니오 | +| 컴퓨트 (Nova) | V2 | 아니오 | +| 아이덴티티(Identity) (Keystone) | V2‡, V3 | 예 | +| 로드 밸런싱 (Neutron) | V1§, V2 | 아니오 | +| 로드 밸런싱 (Octavia) | V2 | 아니오 | + +† 블록 스토리지 V1 API 지원은 사용 중단(deprecated)되며, 쿠버네티스 1.9에서 블록 스토리지 +V3 API 지원이 추가되었다. + +‡ 아이덴티티 V2 API 지원은 사용 중단되며, 향후 릴리스에서는 제공자에서 +제거될 예정이다. "Queens" 릴리스부터 OpenStack은 더 이상 아이덴티티 V2 API를 +공개하지 않는다. + +§ 로드 밸런싱 V1 API 지원이 쿠버네티스 1.9에서 제거되었다. + +서비스 디스커버리는 제공자 구성에서 제공된 `auth-url` 을 사용하여 +OpenStack 아이덴티티(Keystone)에서 관리하는 서비스 카탈로그를 +나열하여 수행된다. Keystone 이외의 OpenStack 서비스를 사용할 수 없고 +영향을 받는 기능에 대한 지원을 거부할 경우 제공자는 기능이 +점진적으로 떨어진다. 기본 클라우드에서 Neutron이 게시한 확장 목록을 기반으로 +특정 기능을 활성화하거나 비활성화할 수도 있다. + +### cloud.conf +쿠버네티스는 cloud.conf 파일을 통해 OpenStack과 상호 작용하는 방법을 알고 있다. 쿠버네티스에 +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 제어판의 액세스 및 보안 > API 액세스 > + 자격 증명에서 찾을 수 있다. +* `username` (필수): Keystone에 설정된 유효한 사용자의 username을 나타낸다. +* `password` (필수): Keystone에 설정된 유효한 사용자의 password를 나타낸다. +* `tenant-id` (필수): 리소스를 생성하려는 프로젝트의 id를 지정하는 데 + 사용된다. +* `tenant-name` (선택): 리소스를 생성하려는 프로젝트의 이름을 + 지정하는 데 사용된다. +* `trust-id` (선택): 권한 부여에 사용할 트러스트(trust)의 식별자를 지정하는 데 + 사용된다. 트러스트는 한 사용자(트러스터(trustor))의 권한을 다른 사용자(트러스티(trustee))에게 역할을 + 위임하고, 선택적으로 트러스티가 트러스터를 가장하도록 + 허용한다. 사용 가능한 트러스트는 + Keystone API의 `/v3/OS-TRUST/trusts` 엔드포인트 아래에 있다. +* `domain-id` (선택): 사용자가 속한 도메인의 id를 지정하는 데 + 사용된다. +* `domain-name` (선택): 사용자가 속한 도메인의 이름을 지정하는 데 + 사용된다. +* `region` (선택): 멀티-리전(multi-region) OpenStack 클라우드에서 + 실행할 때 사용할 리전의 식별자를 지정하는 데 사용된다. 리전은 OpenStack 디플로이먼트의 + 일반 디비전(division)이다. 리전에 엄격한 지리적 의미는 없지만, + 디플로이먼트 시 `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 항목을 찾을 수 없는 경우, + 제공자는 폴백(fall back)하고 대신 Neutron LBaaS V2 엔드포인트를 찾으려고 + 시도한다. 기본값은 `false` 이다. +* `subnet-id` (선택): 로드 밸런서를 생성하려는 서브넷의 id를 + 지정하는 데 사용된다. Network > Networks 에서 찾을 수 있다. 해당 + 네트워크를 클릭하여 서브넷을 가져온다. +* `floating-network-id` (선택): 지정된 경우, 로드 밸런서에 대한 유동 IP를 + 생성한다. +* `lb-method` (선택): 로드 밸런서 풀(pool)의 멤버 간에 부하가 + 분산되는 알고리즘을 지정하는 데 사용된다. 값은 + `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` (선택): 로드 밸런서의 멤버에게 프로브(probe)를 + 보내는 간격의 시간이다. 유효한 시간 단위를 지정해야 한다. 유효한 시간 단위는 "ns", "us"(또는 "µs"), "ms", "s", "m", "h"이다. +* `monitor-timeout` (선택): 모니터가 타임아웃 되기 전에 핑(ping) 응답을 + 기다리는 최대 시간이다. 값은 지연 값보다 작아야 + 한다. 유효한 시간 단위를 지정해야 한다. 유효한 시간 단위는 "ns", "us"(또는 "µs"), "ms", "s", "m", "h"이다. +* `monitor-max-retries` (선택): 로드 밸런서 멤버의 상태를 INACTIVE로 + 변경하기 전에 허용되는 핑 오류 수이다. 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`)을 신뢰할 수 없다. 이 부울은 + 이 동작을 토글(toggle)한다. 이를 `true` 로 설정하면 Cinder에서 제공한 + 블록 장치 이름을 신뢰하게 된다. 기본값인 `false` 는 일련 번호와 + `/dev/disk/by-id` 를 매핑하여 장치 경로를 검색하게 하며 + 권장하는 방법이다. +* `ignore-volume-az` (선택): Cinder 볼륨을 연결할 때 가용 영역(availability zone) + 사용에 영향을 주기 위해 사용된다. Nova와 Cinder의 가용성 + 영역이 서로 다른 경우, 이 값을 `true` 로 설정해야 한다. 이는 가장 일반적인 상황으로 Nova 가용 영역은 + 많지만 Cinder는 하나의 가용 영역만 있는 경우이다. + 이전 릴리스에서 사용된 동작을 유지하기 위해 기본값은 `false` + 이지만, 나중에 변경될 수 있다. +* `node-volume-attach-limit` (선택): 노드에 연결할 수 있는 + 최대 볼륨 수이다. 기본값은 cinder의 경우 256이다. + +포트가 아닌 경로를 사용하여 엔드포인트를 구별하는 OpenStack +디플로이먼트에서 1.8 이하의 쿠버네티스 버전을 배포하는 경우 +명시적으로 `bs-version` 파라미터를 설정해야 한다. 경로 기반의 엔드포인트는 +`http://foo.bar/volume` 형식이며 포트 기반의 엔드포인트는 +`http://foo.bar:xxx` 형식이다. + +경로 기반의 엔드포인트를 사용하고 쿠버네티스가 이전 자동 감지 로직을 사용하는 환경에서는 +볼륨 분리 시도 시 `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] +쿠버네티스 네트워크 플러그인과 관련이 있으며 `cloud.conf` 파일의 `[Route]` 섹션에 +있어야 한다. + +* `router-id` (선택): 기본 클라우드의 Neutron 디플로이먼트가 + `extraroutes` 확장을 지원하는 경우 경로를 추가할 라우터를 지정하는 데 `router-id` + 를 사용한다. 선택한 라우터는 클러스터 노드를 포함하는 프라이빗 네트워크에 + 걸쳐 있어야 한다(일반적으로 하나의 노드 네트워크만 있으며, 이 값은 + 노드 네트워크의 기본 라우터여야 한다). 이 값은 OpenStack에서 [kubenet]을 사용하는 데 + 필요하다. + +[kubenet]: /ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet + +{{% /capture %}} + +## OVirt + +### 노드 이름 + +OVirt 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. +참고로 쿠버네티스 노드 이름은 VM FQDN(Ovirt의 `...` 아래에서 보고된)과 일치해야 한다. + +## Photon + +### 노드 이름 + +Photon 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. +참고로 쿠버네티스 노드 이름은 Photon VM 이름(또는 `--cloud-config` 에서 `overrideIP` 가 true로 설정된 경우, 쿠버네티스 노드 이름은 Photon VM IP 주소와 일치해야 함)과 일치해야 한다. + +## vSphere + +{{< tabs name="vSphere cloud provider" >}} +{{% tab name="vSphere 6.7U3 이상" %}} +vSphere 6.7U3 이상의 모든 vSphere 디플로이먼트의 경우, [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)와 함께 [외부 vSphere 클라우드 제공자](https://github.com/kubernetes/cloud-provider-vsphere)를 권장한다. 퀵스타트 가이드는 [CSI와 CPI를 사용하여 vSphere에 쿠버네티스 클러스터 배포하기](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html)를 참고한다. +{{% /tab %}} +{{% tab name="vSphere 6.7U3 미만" %}} +vSphere 6.7U3 미만을 사용할 경우, 인-트리 vSphere 클라우드 제공자를 권장한다. 퀵스타트 가이드는 [kubeadm을 사용하여 vSphere에 쿠버네티스 클러스터 실행하기](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 클라우드 쿠버네티스 서비스 + +### 컴퓨트 노드 +IBM 클라우드 쿠버네티스 서비스 제공자를 사용하면, 단일 영역 또는 하나의 리전에서 여러 영역에 걸쳐 가상 노드와 물리(베어 메탈) 노드가 혼합된 클러스터를 생성할 수 있다. 자세한 정보는, [클러스터와 워커(worker) 노드 설정 계획](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes)을 참고한다. + +쿠버네티스 노드 오브젝트의 이름은 IBM 클라우드 쿠버네티스 서비스 워커 노드 인스턴스의 프라이빗 IP 주소이다. + +### 네트워킹 +IBM 클라우드 쿠버네티스 서비스 제공자는 노드의 네트워크 성능 품질과 네트워크 격리를 위한 VLAN을 제공한다. 사용자 정의 방화벽 및 Calico 네트워크 폴리시를 설정하여 클러스터에 추가적인 보안 계층을 추가하거나 VPN을 통해 온-프레미스 데이터센터에 클러스터를 연결할 수 있다. 자세한 내용은 [인-클러스터(in-cluster) 및 프라이빗 네트워킹 계획](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster)을 참고한다. + +퍼블릭 또는 클러스터 내에서 앱을 노출하기 위해 노드포트(NodePort), 로드밸런서 또는 인그레스 서비스를 활용할 수 있다. 어노테이션을 사용하여 인그레스 애플리케이션 로드 밸런서를 커스터마이징 할 수도 있다. 자세한 내용은 [외부 네트워킹으로 앱 노출 계획](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)을 참고한다. + +### 스토리지 +IBM 클라우드 쿠버네티스 서비스 제공자는 쿠버네티스-네이티브 퍼시스턴트 볼륨을 활용하여 사용자가 파일, 블록 및 클라우드 오브젝트 스토리지를 앱에 마운트할 수 있도록 한다. 데이터를 지속적으로 저장하기 위해 서비스로서의-데이터베이스(database-as-a-service)와 써드파티 애드온을 사용할 수도 있다. 자세한 정보는 [고가용성 퍼시스턴트 스토리지 계획](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)을 참고한다. + +## Baidu 클라우드 컨테이너 엔진 + +### 노드 이름 + +Baidu 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 프라이빗 IP 주소를 사용한다. +참고로 쿠버네티스 노드 이름은 Baidu VM 프라이빗 IP와 일치해야 한다. + +## Tencent 쿠버네티스 엔진 +이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)이다. + +### 노드 이름 + +Tencent 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. +참고로 쿠버네티스 노드 이름은 Tencent VM 프라이빗 IP와 일치해야 한다. diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md new file mode 100644 index 0000000000..03fccd4364 --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -0,0 +1,317 @@ +--- +title: 클러스터 네트워킹 +content_template: templates/concept +weight: 50 +--- + +{{% capture overview %}} +네트워킹은 쿠버네티스의 중심적인 부분이지만, 어떻게 작동하는지 정확하게 +이해하기가 어려울 수 있다. 쿠버네티스에는 4가지 대응해야 할 네트워킹 +문제가 있다. + +1. 고도로 결합된 컨테이너 간의 통신: 이 문제는 + [파드](/ko/docs/concepts/workloads/pods/pod/)와 `localhost` 통신으로 해결된다. +2. 파드 간 통신: 이 문제가 이 문서의 주요 초점이다. +3. 파드와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다. +4. 외부와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다. + +{{% /capture %}} + + +{{% capture body %}} + +쿠버네티스는 애플리케이션 간에 머신을 공유하는 것이다. 일반적으로, +머신을 공유하려면 두 애플리케이션이 동일한 포트를 사용하지 않도록 +해야 한다. 여러 개발자 간에 포트를 조정하는 것은 대규모로 실시하기가 매우 어렵고, +사용자가 통제할 수 없는 클러스터 수준의 문제에 노출된다. + +동적 포트 할당은 시스템에 많은 복잡성을 야기한다. 모든 +애플리케이션은 포트를 플래그로 가져와야 하며, API 서버는 동적 포트 번호를 +구성 블록에 삽입하는 방법을 알아야 하고, 서비스는 서로를 +찾는 방법 등을 알아야 한다. 쿠버네티스는 이런 것들을 다루는 대신 +다른 접근법을 취한다. + +## 쿠버네티스 네트워크 모델 + +모든 `Pod` 에는 고유의 IP 주소가 있다. 즉, `Pod` 간에 링크를 명시적으로 +생성할 필요가 없으며 컨테이너 포트를 호스트 포트에 매핑할 +필요가 거의 없다. 이렇게 하면 포트 할당, 이름 지정, 서비스 검색, 로드 밸런싱, +애플리케이션 구성 및 마이그레이션 관점에서 `Pod` 를 VM 또는 +물리적 호스트처럼 취급할 수 있는 깔끔하고, 하위 호환성 +있는 모델이 생성된다. + +쿠버네티스는 모든 네트워크 구현에 다음과 같은 +기본 요구 사항을 적용한다(의도적 네트워크 세분화 정책 제외). + + * 노드의 파드는 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다. + * 노드의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든 + 파드와 통신할 수 있다. + +참고: 호스트 네트워크에서 실행되는 `Pod` 를 지원하는 리눅스와 같은 플랫폼의 경우, 다음의 요구 사항을 +적용한다. + + * 노드의 호스트 네트워크에 있는 파드는 NAT 없이 모든 노드에 있는 모든 + 파드와 통신할 수 있다. + +이 모델은 전체적으로 덜 복잡할 뿐만 아니라, 쿠버네티스를 위해 VM에서 +컨테이너로 애플리케이션을 포팅할 때 충돌이 적게 구현하려는 요구와 +주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고 +프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다. + +쿠버네티스의 IP 주소는 그것의 IP 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내 +컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두 +`localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한 +`Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도 +VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다. + +이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. + +`Pod` 로 전달하는 `Node` 자체의 포트(호스트 포트라고 함)를 +요청할 수 있지만, 이는 매우 틈새 작업이다. 전달이 구현되는 방법은 +컨테이너 런타임의 세부 사항이기도 하다. `Pod` 자체는 +호스트 포트의 존재 여부에 대해 인식하지 못한다. + +## 쿠버네티스 네트워크 모델의 구현 방법 + +이 네트워크 모델을 구현할 수 있는 방법에는 여러 가지가 있다. 이 +문서는 다양한 방법에 대한 철저한 연구는 아니지만, 다양한 기술에 대한 +소개로 활용되며 도약하는 포인트로 사용되기를 바란다. + +이 목록은 알파벳 순으로 정렬되어 있으며, 정렬된 순서가 +우선 상태를 의미하는 것은 아니다. + +### ACI + +[Cisco 애플리케이션 센트릭 인프라스트럭처(Application Centric Infrastructure)](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html)는 컨테이너, 가상 머신 및 베어메탈 서버를 지원하는 통합 오버레이 및 언더레이 SDN 솔루션을 제공한다. [ACI](https://www.github.com/noironetworks/aci-containers)는 ACI를 위한 컨테이너 네트워킹 통합을 제공한다. 통합의 개요는 [여기](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf)에서 제공된다. + +### Antrea + +프로젝트 [Antrea](https://github.com/vmware-tanzu/antrea)는 쿠버네티스 고유의 오픈소스 쿠버네티스 네트워킹 솔루션이다. 네트워킹 데이터 플레인으로 Open vSwitch를 활용한다. Open vSwitch는 리눅스와 윈도우를 모두 지원하는 고성능의 프로그래밍이 가능한 가상 스위치이다. Antrea는 Open vSwitch를 통해 쿠버네티스 네트워크 정책을 고성능의 효율적인 방식으로 구현할 수 있다. +Antrea는 Open vSwitch의 "프로그래밍이 가능한" 특성으로 인해 Open vSwitch 위에 광범위한 네트워킹 및 보안 기능과 서비스를 구현할 수 있다. + +### Apstra의 AOS + +[AOS](http://www.apstra.com/products/aos/)는 단순한 통합 플랫폼에서 복잡한 데이터센터 환경을 만들고 관리하는 의도기반(Intent-Based) 네트워킹 시스템이다. AOS는 확장성이 뛰어난 분산 설계를 활용하여 네트워크 중단을 제거하면서 비용을 최소화한다. + +AOS 레퍼런스 디자인은 현재 레거시 Layer-2 스위칭 문제를 제거하는 Layer-3 연결 호스트를 지원한다. 이 Layer-3 호스트는 리눅스 서버(Debian, Ubuntu, CentOS)일 수 있으며 랙 상단 스위치(TOR)와 직접 BGP 인접 관계를 만든다. AOS는 라우팅 인접성을 자동화한 다음 쿠버네티스 디플로이먼트에서 일반적으로 사용되는 RHI(Route Health Injection)에 대한 세밀한 제어를 제공한다. + +AOS는 쿠버네티스가 애플리케이션 요구 사항에 따라 네트워크 정책을 신속하게 변경할 수 있는 풍부한 REST API 엔드포인트 셋을 제공한다. 네트워크 설계에 사용된 AOS 그래프 모델을 워크로드 프로비저닝과 통합하여 프라이빗 클라우드와 퍼블릭 클라우드 모두에 대한 엔드-투-엔드 관리 시스템을 향상시킬 수 있다. + +AOS는 Cisco, Arista, Dell, Mellanox, HPE 그리고 Microsoft SONiC, Dell OPX 및 Cumulus Linux와 같은 개방형 네트워크 운영체제와 수많은 화이트-박스 시스템을 포함한 제조업체의 일반적인 벤더 장비 사용을 지원한다. + +AOS 시스템 작동 방식에 대한 자세한 내용은 다음을 참고한다. http://www.apstra.com/products/how-it-works/ + +### 쿠버네티스용 AWS VPC CNI + +[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s)는 쿠버네티스 클러스터를 위한 통합된 AWS 버추얼 프라이빗 클라우드(Virtual Private Cloud, VPC) 네트워킹을 제공한다. 이 CNI 플러그인은 높은 처리량과 가용성, 낮은 레이턴시(latency) 그리고 최소 네트워크 지터(jitter)를 제공한다. 또한, 사용자는 쿠버네티스 클러스터를 구축하기 위한 기존의 AWS VPC 네트워킹 및 보안 모범 사례를 적용할 수 있다. 여기에는 VPC 플로우 로그, VPC 라우팅 정책과 네트워크 트래픽 격리를 위한 보안 그룹을 사용하는 기능이 포함되어 있다. + +이 CNI 플러그인을 사용하면 쿠버네티스 파드는 VPC 네트워크와 동일한 IP 주소를 파드 내부에 가질 수 있다. CNI는 각 쿠버네티스 노드에 AWS 엘라스틱 네트워킹 인터페이스(Elastic Networking Interfaces, ENI)를 할당하고 노드의 파드에 대해 각 ENI의 보조 IP 범위를 사용한다. CNI에는 파드를 빠르게 시작하기 위해 ENI와 IP 주소의 사전 할당 제어 기능이 포함되어 있으며 최대 2,000개의 노드로 구성된 대규모 클러스터가 가능하다. + +또한, CNI는 [네트워크 폴리시 적용을 위해 캘리코(Calico)](https://docs.aws.amazon.com/eks/latest/userguide/calico.html)와 함께 실행할 수 있다. AWS VPC CNI 프로젝트는 [GitHub의 문서](https://github.com/aws/amazon-vpc-cni-k8s)와 함께 오픈소스로 공개되어 있다. + +### 쿠버네티스용 Azure CNI +[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview)는 VM과 동등한 네트워크 성능을 제공하는 Azure 버추얼 네트워크(VNet이라고도 알려진)와 쿠버네티스 파드를 통합하는 [오픈소스](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) 플러그인이다. 파드는 피어링된 VNet과 Express Route 또는 사이트 간 VPN을 통해 온-프레미스에 연결할 수 있으며 이러한 네트워크에서 직접 연결할 수도 있다. 파드는 서비스 엔드포인트 또는 프라이빗 링크로 보호되는 스토리지와 SQL과 같은 Azure 서비스에 접근할 수 있다. VNet 보안 정책과 라우팅을 사용하여 파드 트래픽을 필터링할 수 있다. 플러그인은 쿠버네티스 노드의 네트워크 인터페이스에 사전 구성된 보조 IP 풀을 활용하여 VNet IP를 파드에 할당한다. + +Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni)에서 기본적으로 사용할 수 있다. + + +### Big Switch Networks의 빅 클라우드 패브릭(Big Cloud Fabric) + +[빅 클라우드 패브릭](https://www.bigswitch.com/container-network-automation)은 클라우드 네이티브 네트워킹 아키텍처로, 프라이빗 클라우드/온-프레미스 환경에서 쿠버네티스를 실행하도록 디자인되었다. 통합된 물리 및 가상 SDN을 사용하여, 빅 클라우드 패브릭은 로드 밸런싱, 가시성, 문제 해결, 보안 정책 및 컨테이너 트래픽 모니터링과 같은 내재한 컨테이너 네트워킹 문제를 해결한다. + +빅 클라우드 패브릭의 가상 파드 멀티 테넌트 아키텍처를 통해 쿠버네티스, RedHat OpenShift, Mesosphere DC/OS 및 Docker Swarm과 같은 컨테이너 오케스트레이션 시스템은 VMware, OpenStack 및 Nutanix와 같은 VM 오케스트레이션 시스템과 함께 네이티브로 통합된다. 고객은 원하는 수의 클러스터를 안전하게 상호 연결할 수 있으며 필요한 경우 이들 사이의 테넌트 간 통신을 활성화할 수 있다. + +가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다. + +### 실리움(Cilium) + +[실리움](https://github.com/cilium/cilium)은 애플리케이션 컨테이너 간에 +네트워크 연결을 제공하고 투명하게 보호하기 위한 오픈소스 소프트웨어이다. +실리움은 L7/HTTP를 인식하며 네트워크 주소 지정에서 분리된 ID 기반 보안 모델을 사용하여 L3-L7에서 +네트워크 정책을 적용할 수 있으며, +다른 CNI 플러그인과 함께 사용할 수 있다. + +### 화웨이의 CNI-Genie + +[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)는 쿠버네티스가 런타임 시 [쿠버네티스 네트워크 모델](https://github.com/kubernetes/website/blob/master/content/en/docs/concepts/cluster-administration/networking.md#the-kubernetes-network-model)의 [서로 다른 구현에 동시에 접근](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)할 수 있는 CNI 플러그인이다. 여기에는 [플라넬(Flannel)](https://github.com/coreos/flannel#flannel), [캘리코](http://docs.projectcalico.org/), [로마나(Romana)](http://romana.io), [위브넷(Weave-net)](https://www.weave.works/products/weave-net/)과 같은 [CNI 플러그인](https://github.com/containernetworking/cni#3rd-party-plugins)으로 실행되는 모든 구현이 포함된다. + +CNI-Genie는 각각 다른 CNI 플러그인에서 [하나의 파드에 여러 IP 주소를 할당](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)하는 것도 지원한다. + +### cni-ipvlan-vpc-k8s +[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s)는 +L2 모드에서 리눅스 커널의 IPvlan 드라이버를 사용하여 Amazon 엘라스틱 네트워크 인터페이스(ENI)를 +사용하고 AWS 매니지드 IP를 파드에 바인딩하는 +Amazon 버추얼 프라이빗 클라우드(VPC) 환경 내에서 쿠버네티스를 위한 +간단하고, 호스트 로컬, 낮은 레이턴시, 높은 처리량 및 호환 네트워킹 스택을 제공하는 +CNI와 IPAM 플러그인 셋을 포함한다. + +플러그인은 VPC 내에서 구성하고 배포할 수 있도록 간단하게 설계되었다. +Kubelets는 오버레이 네트워크 관리, BGP 관리, 소스/대상 확인 비활성화 또는 +VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스별 서브넷을 +제공(VPC별 50-100개 항목으로 제한)하는 등의 자주 권장되는 복잡성을 요구하지 않고 +부팅한 다음 필요에 따라 IP 사용량을 자체 구성하고 확장할 +수 있다. 즉, cni-ipvlan-vpc-k8s는 AWS 내에서 쿠버네티스를 +대규모로 배포하는 데 필요한 네트워크 복잡성을 크게 줄인다. + +### 콘티브(Contiv) + +[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](http://contiv.io)는 모두 오픈소스이다. + +### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric) + +[텅스텐 패브릭](https://tungsten.io)을 기반으로 하는 [콘트레일](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 진정한 개방형 멀티 클라우드 네트워크 가상화 및 정책 관리 플랫폼이다. 콘트레일 및 텅스텐 패브릭은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 다양한 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어메탈 워크로드에 대해 서로 다른 격리 모드를 제공한다. + +### DANM + +[DANM](https://github.com/nokia/danm)은 쿠버네티스 클러스터에서 실행되는 통신사 워크로드를 위한 네트워킹 솔루션이다. 다음의 컴포넌트로 구성된다. + + * 고급 기능들로 IPVLAN 인터페이스를 프로비저닝할 수 있는 CNI 플러그인 + * 여러 클러스터 전체의 불연속 L3 네트워크를 관리하고 요청 시 동적, 정적 또는 IP를 할당하지 않는 방식을 제공하는 내장 IPAM 모듈 + * 자체 CNI를 통해서, 또는 SRI-OV나 플라넬과 같은 널리 사용되는 CNI 솔루션에 잡을 동시에 위임하여 여러 네트워크 인터페이스를 컨테이너에 연결할 수 있는 CNI 메타플러그인 + * 모든 쿠버네티스 호스트의 VxLAN 및 VLAN 인터페이스를 중앙에서 관리할 수 있는 쿠버네티스 컨트롤러 + * 쿠버네티스의 서비스 기반의 서비스 검색 개념을 확장하여 파드의 모든 네트워크 인터페이스에서 작동하는 다른 쿠버네티스 컨트롤러 + +이 도구 셋을 통해 DANM은 여러 개의 분리된 네트워크 인터페이스를 제공할 수 있으며, 파드에 다른 네트워킹 백엔드 및 고급 IPAM 기능을 사용할 수 있다. + +### 플라넬 + +[플라넬](https://github.com/coreos/flannel#flannel)은 쿠버네티스 요구 사항을 +충족하는 매우 간단한 오버레이 네트워크이다. 많은 +경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다. + +### Google 컴퓨트 엔진(GCE) + +Google 컴퓨트 엔진 클러스터 구성 스크립트의 경우, [고급 +라우팅](https://cloud.google.com/vpc/docs/routes)을 사용하여 +각 VM에 서브넷을 할당한다(기본값은 `/24` - 254개 IP). 해당 서브넷에 바인딩된 +모든 트래픽은 GCE 네트워크 패브릭에 의해 VM으로 직접 라우팅된다. 이는 +아웃 바운드 인터넷 접근을 위해 NAT로 구성된 VM에 할당된 "기본" +IP 주소에 추가된다. 리눅스 브릿지(`cbr0`)는 해당 서브넷에 존재하도록 +구성되며, 도커의 `--bridge` 플래그로 전달된다. + +도커는 다음의 설정으로 시작한다. + +```shell +DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" +``` + +이 브릿지는 노드의 `.spec.podCIDR`에 따라 Kubelet(`--network-plugin=kubenet` +플래그로 제어되는)에 의해 생성된다. + +도커는 이제 `cbr-cidr` 블록에서 IP를 할당한다. 컨테이너는 `cbr0` 브릿지를 +통해 서로 `Node` 에 도달할 수 있다. 이러한 IP는 모두 GCE 프로젝트 네트워크 +내에서 라우팅할 수 있다. + +그러나, GCE 자체는 이러한 IP에 대해 전혀 알지 못하므로, 아웃 바운드 인터넷 트래픽을 위해 +IP를 NAT하지 않는다. 그것을 달성하기 위해 iptables 규칙을 사용하여 +GCE 프로젝트 네트워크(10.0.0.0/8) 외부의 IP에 바인딩된 트래픽을 +마스커레이드(일명 SNAT - 마치 패킷이 `Node` 자체에서 온 것처럼 +보이게 함)한다. + +```shell +iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE +``` + +마지막으로 커널에서 IP 포워딩이 활성화되어 있으므로, 커널은 브릿지된 컨테이너에 +대한 패킷을 처리한다. + +```shell +sysctl net.ipv4.ip_forward=1 +``` + +이 모든 것의 결과는 모든 `Pod` 가 서로에게 도달할 수 있고 인터넷으로 트래픽을 +송신할 수 있다는 것이다. + +### 재규어(Jaguar) + +[재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다. + +### k-vswitch + +[k-vswitch](https://github.com/k-vswitch/k-vswitch)는 [Open vSwitch](https://www.openvswitch.org/) 기반의 간단한 쿠버네티스 네트워킹 플러그인이다. Open vSwitch의 기존 기능을 활용하여 운영하기 쉽고, 성능이 뛰어나고 안전한 강력한 네트워킹 플러그인을 제공한다. + +### Knitter + +[Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스에서 여러 네트워킹을 지원하는 네트워크 솔루션이다. 테넌트 관리 및 네트워크 관리 기능을 제공한다. Knitter에는 애플리케이션의 IP 주소 유지, IP 주소 마이그레이션 등과 같은 여러 네트워크 플레인 외에 엔드-투-엔드 NFV 컨테이너 네트워킹 솔루션 셋이 포함되어 있다. + +### Kube-OVN + +[Kube-OVN](https://github.com/alauda/kube-ovn)은 기업을 위한 OVN 기반 쿠버네티스 네트워크 패브릭이다. OVN/OVS의 도움으로, 서브넷, QoS, 고정 IP 할당, 트래픽 미러링, 게이트웨이, 오픈플로우 기반 네트워크 정책 및 서비스 프록시와 같은 고급 오버레이 네트워크 기능을 제공한다. + +### Kube-router + +[kube-router](https://github.com/cloudnativelabs/kube-router)는 쿠버네티스를 위한 특수 목적의 네트워킹 솔루션으로 고성능 및 운영 단순성을 제공한다. 큐브 라우터는 리눅스 [LVS/IPVS](http://www.linuxvirtualserver.org/software/ipvs.html) 기반 서비스 프록시, 오버레이가 없는 리눅스 커널 포워딩 기반의 파드 간 네트워킹 솔루션 그리고 iptables/ipset 기반 네트워크 정책 집행도구를 제공한다. + +### L2 네트워크 및 리눅스 브릿지 + +"베어메탈" 환경의 간단한 스위치와 같은 "더미(dumb)" L2 네트워크가 있는 경우, +위의 GCE 설정과 비슷한 작업을 수행할 수 있어야 한다. +이 방법은 매우 우연히 시도되었고 작동하는 것으로 보이지만 +철저히 테스트되지 않았다. 이 기술을 사용하여 +프로세스를 완료한 경우, 알려주길 바란다. + +Lars Kellogg-Stedman이 제공하는 [이 훌륭한 +튜토리얼](http://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/)의 +"With Linux Bridge devices" 섹션을 참고한다. + +### Multus(멀티 네트워크 플러그인) + +[Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스의 CRD 기반 네트워크 오브젝트를 사용하여 쿠버네티스에서 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다. + +Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://github.com/containernetworking/plugins)(예: [플라넬](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)) 및 써드파티 플러그인(예: [캘리코](https://github.com/projectcalico/cni-plugin), [위브(Weave)](https://github.com/weaveworks/weave), [실리움](https://github.com/cilium/cilium), [콘티브](https://github.com/contiv/netplugin))을 지원한다. 또한, Multus는 쿠버네티스의 클라우드 네이티브 애플리케이션과 NFV 기반 애플리케이션을 통해 쿠버네티스의 [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) 워크로드를 지원한다. + +### NSX-T + +[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html)는 네트워크 가상화 및 보안 플랫폼이다. NSX-T는 멀티 클라우드 및 멀티 하이퍼바이저 환경에 네트워크 가상화를 제공할 수 있으며 이기종 엔드포인트와 기술 스택이 있는 새로운 애플리케이션 프레임워크 및 아키텍처에 중점을 둔다. vSphere 하이퍼바이저 외에도, 이러한 환경에는 KVM, 컨테이너 및 베어메탈과 같은 다른 하이퍼바이저가 포함된다. + +[NSX-T 컨테이너 플러그인(NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. + +### Nuage Networks VCS(가상 클라우드 서비스) + +[Nuage](http://www.nuagenetworks.net)는 확장성이 뛰어난 정책 기반의 소프트웨어 정의 네트워킹(SDN) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로 구축된 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인용 오픈소스 Open vSwitch를 사용한다. + +Nuage 플랫폼은 오버레이를 사용하여 쿠버네티스 파드와 쿠버네티스가 아닌 환경(VM 및 베어메탈 서버) 간에 완벽한 정책 기반의 네트워킹을 제공한다. Nuage의 정책 추상화 모델은 애플리케이션을 염두에 두고 설계되었으며 애플리케이션에 대한 세분화된 정책을 쉽게 선언할 수 있도록 한다. 플랫폼의 실시간 분석 엔진을 통해 쿠버네티스 애플리케이션에 대한 가시성과 보안 모니터링이 가능하다. + +### OpenVSwitch + +[OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만 +오버레이 네트워크를 구축하는 복잡한 방법이다. 이것은 네트워킹 분야의 몇몇 +"대형 벤더"에 의해 승인되었다. + +### OVN(오픈 버추얼 네트워킹) + +OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 +가상화 솔루션이다. 논리적 스위치, 논리적 라우터, 스테이트풀 ACL, 로드 밸런서 등을 생성하여 +서로 다른 가상 네트워킹 토폴로지를 구축할 수 있다. 이 프로젝트에는 +[ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)에 +특정 쿠버네티스 플러그인 및 문서가 있다. + +### 프로젝트 캘리코 + +[프로젝트 캘리코](http://docs.projectcalico.org/)는 오픈소스 컨테이너 네트워킹 공급자 및 네트워크 정책 엔진이다. + +캘리코는 리눅스(오픈소스)와 윈도우(독점 - [Tigera](https://www.tigera.io/essentials/)에서 사용 가능) 모두에서 인터넷과 동일한 IP 네트워킹 원칙을 기반으로 쿠버네티스 파드를 연결하기 위한 확장성이 뛰어난 네트워킹 및 네트워크 정책 솔루션을 제공한다. 캘리코는 캡슐화나 오버레이 없이 구축되어 고성능의 대규모 데이터센터 네트워킹을 제공할 수 있다. 또한 캘리코는 분산 방화벽을 통해 쿠버네티스 파드에 대해 세분화된 의도기반의 네트워크 보안 정책을 제공한다. + +캘리코는 플라넬, 일명 [canal](https://github.com/tigera/canal) 또는 네이티브 GCE, AWS나 Azure 네트워킹과 같은 다른 네트워킹 솔루션과 함께 정책 적용 모드로 실행될 수도 있다. + +### 로마나 + +[로마나](http://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다. + +### Weaveworks의 위브넷 + +[위브넷](https://www.weave.works/products/weave-net/)은 +쿠버네티스 및 호스팅된 애플리케이션을 위한 탄력적이고 사용하기 쉬운 네트워크이다. +위브넷은 [CNI 플러그인](https://www.weave.works/docs/net/latest/cni-plugin/) 또는 +독립형으로 실행된다. 두 버전에서, 실행하기 위해 구성이나 추가 코드가 필요하지 않으며, +두 경우 모두, 쿠버네티스의 표준과 같이 네트워크에서 파드별로 하나의 IP 주소를 제공한다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은 +[네트워킹 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)에 +자세히 설명되어 있다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/configuration/assign-pod-node.md b/content/ko/docs/concepts/configuration/assign-pod-node.md index 5136fddeeb..1d13f2b412 100644 --- a/content/ko/docs/concepts/configuration/assign-pod-node.md +++ b/content/ko/docs/concepts/configuration/assign-pod-node.md @@ -1,7 +1,7 @@ --- title: 노드에 파드 할당하기 content_template: templates/concept -weight: 30 +weight: 50 --- diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md new file mode 100644 index 0000000000..8f7292d61c --- /dev/null +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -0,0 +1,169 @@ +--- +title: 컨피그맵(ConfigMap) +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +{{< glossary_definition term_id="configmap" prepend="컨피그맵은" length="all" >}} + +{{< caution >}} +컨피그맵은 보안 또는 암호화를 제공하지 않는다. +저장하려는 데이터가 기밀인 경우, 컨피그맵 +대신 {{< glossary_tooltip text="시크릿(Secret)" term_id="secret" >}} 또는 추가(써드파티) 도구를 +사용하여 데이터를 비공개로 유지하자. +{{< /caution >}} + +{{% /capture %}} + +{{% capture body %}} +## 사용 동기 + +애플리케이션 코드와 별도로 구성 데이터를 설정하려면 컨피그맵을 사용하자. + +예를 들어, 자신의 컴퓨터(개발용)와 클라우드(실제 트래픽 처리)에서 +실행할 수 있는 애플리케이션을 개발한다고 가정해보자. +`DATABASE_HOST` 라는 +환경 변수를 찾기 위해 코드를 작성한다. 로컬에서는 해당 변수를 +`localhost` 로 설정한다. 클라우드에서는, 데이터베이스 +컴포넌트를 클러스터에 노출하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}를 참조하도록 +설정한다. + +이를 통해 클라우드에서 실행 중인 컨테이너 이미지를 가져와 +필요한 경우 정확히 동일한 코드를 로컬에서 디버깅할 수 있다. + +## 컨피그맵 오브젝트 + +컨피그맵은 다른 오브젝트가 사용할 구성을 저장할 수 있는 +API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)이다. +`spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리, +컨피그맵에는 항목(키)과 해당 값을 저장하는 `data` 섹션이 있다. + +컨피그맵의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. + +## 컨피그맵과 파드(Pod) + +컨피그맵을 참조하는 파드 `spec` 을 작성하고 컨피그맵의 데이터를 +기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은 +동일한 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에 있어야 한다. + +다음은 단일 값을 가진 키와, +값이 구성 형식의 일부처럼 보이는 키를 가진 컨피그맵의 +예시이다. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + Name: game-demo +data: + # 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨 + player_initial_lives: 3 + ui_properties_file_name: "user-interface.properties" + # + # 파일과 비슷한 키 + game.properties: | + enemy.types=aliens,monsters + player.maximum-lives=5 + user-interface.properties: | + color.good=purple + color.bad=yellow + allow.textmode=true +``` + +컨피그맵을 사용하여 파드 내부에 컨테이너를 구성할 수 있는 +네 가지 방법이 있다. + +1. 컨테이너의 엔트리포인트에 대한 커맨드 라인 인수 +1. 컨테이너에 대한 환경 변수 +1. 애플리케이션이 읽을 수 있도록 읽기 전용 볼륨에 파일 추가 +1. 쿠버네티스 API를 사용하여 컨피그맵을 읽는 파드 내에서 실행할 코드 작성 + +이러한 방법들은 소비되는 데이터를 모델링하는 +방식에 따라 다르게 쓰인다. +처음 세 가지 방법의 경우, +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}은 파드의 컨테이너를 시작할 때 +시크릿의 데이터를 사용한다. + +네 번째 방법은 시크릿과 데이터를 읽기 위해 코드를 작성해야 한다는 것을 의미한다. +그러나, 쿠버네티스 API를 직접 사용하기 때문에, 애플리케이션은 +컨피그맵이 변경될 때마다 업데이트를 받기 위해 구독할 수 있고, 업데이트가 +있으면 반응한다. 쿠버네티스 API에 직접 접근하면, 이 +기술을 사용하여 다른 네임스페이스의 컨피그맵에 접근할 수도 있다. + +다음은 `game-demo` 의 값을 사용하여 파드를 구성하는 파드 예시이다. +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-demo-pod +spec: + containers: + - name: demo + image: game.example/demo-game + env: + # 환경 변수 정의 + - name: PLAYER_INITIAL_LIVES # 참고로 여기서는 컨피그맵의 키 이름과 + # 대소문자가 다르다. + valueFrom: + configMapKeyRef: + name: game-demo # 이 값의 컨피그맵. + key: player_initial_lives # 가져올 키. + - name: UI_PROPERTIES_FILE_NAME + valueFrom: + configMapKeyRef: + name: game-demo + key: ui_properties_file_name + volumeMounts: + - name: config + mountPath: "/config" + readOnly: true + volumes: + # 파드 레벨에서 볼륨을 설정한 다음, 해당 파드 내의 컨테이너에 마운트한다. + - name: config + configMap: + # 마운트하려는 컨피그맵의 이름을 제공한다. + name: game-demo +``` + + +컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을 +구분하지 않는다. +더 중요한 것은 파드와 다른 오브젝트가 이러한 값을 소비하는 방식이다. +이 예제에서, 볼륨을 정의하고 `demo` 컨테이너에 +`/config` 로 마운트하면 4개의 파일이 생성된다. + +- `/config/player_initial_lives` +- `/config/ui_properties_file_name` +- `/config/game.properties` +- `/config/user-interface.properties` + +`/config` 에 `.properties` 확장자를 가진 파일만 +포함시키려면, 두 개의 다른 컨피그맵을 사용하고, 파드에 +대해서는 `spec` 의 두 컨피그맵을 참조한다. 첫 번째 컨피그맵은 +`player_initial_lives` 와 `ui_properties_file_name` 을 정의한다. 두 번째 +컨피그맵은 kubelet이 `/config` 에 넣는 파일을 정의한다. + +{{< note >}} +컨피그맵을 사용하는 가장 일반적인 방법은 동일한 네임스페이스의 +파드에서 실행되는 컨테이너에 대한 설정을 구성하는 것이다. 컨피그맵을 +별도로 사용할 수도 있다. + +예를 들어, +컨피그맵에 기반한 동작을 조정하는 {{< glossary_tooltip text="애드온" term_id="addons" >}}이나 +{{< glossary_tooltip text="오퍼레이터" term_id="operator-pattern" >}}를 +사용할 수도 있다. +{{< /note >}} + + +{{% /capture %}} +{{% capture whatsnext %}} + +* [시크릿](/docs/concepts/configuration/secret/)에 대해 읽어본다. +* [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다. +* 코드를 구성에서 분리하려는 동기를 이해하려면 + [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md new file mode 100644 index 0000000000..525414a7a9 --- /dev/null +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -0,0 +1,761 @@ +--- +title: 컨테이너 리소스 관리 +content_template: templates/concept +weight: 40 +feature: + title: 자동 빈 패킹(bin packing) + description: > + 리소스 요구 사항과 기타 제약 조건에 따라 컨테이너를 자동으로 배치하지만, 가용성은 그대로 유지한다. 활용도를 높이고 더 많은 리소스를 절약하기 위해 중요한(critical) 워크로드와 최선의(best-effort) 워크로드를 혼합한다. +--- + +{{% capture overview %}} + +{{< glossary_tooltip text="파드" term_id="pod" >}}를 지정할 때, +{{< glossary_tooltip text="컨테이너" term_id="container" >}}에 필요한 각 리소스의 양을 선택적으로 지정할 수 있다. +지정할 가장 일반적인 리소스는 CPU와 메모리(RAM) 그리고 다른 것들이 있다. + +파드에서 컨테이너에 대한 리소스 _요청(request)_ 을 지정하면, 스케줄러는 이 정보를 +사용하여 파드가 배치될 노드를 결정한다. 컨테이너에 대한 리소스 _제한(limit)_ 을 +지정하면, kubelet은 실행 중인 컨테이너가 설정한 제한보다 많은 리소스를 +사용할 수 없도록 해당 제한을 적용한다. 또한 kubelet은 +컨테이너가 사용할 수 있도록 해당 시스템 리소스의 최소 _요청_ 량을 +예약한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 요청 및 제한 + +파드가 실행 중인 노드에 사용 가능한 리소스가 충분하면, 컨테이너가 해당 +리소스에 지정한 `request` 보다 더 많은 리소스를 사용할 수 있도록 허용된다. +그러나, 컨테이너는 리소스 `limit` 보다 더 많은 리소스를 사용할 수는 없다. + +예를 들어, 컨테이너에 대해 256MiB의 `memory` 요청을 설정하고, 해당 컨테이너가 +8GiB의 메모리를 가진 노드로 스케줄된 파드에 있고 다른 파드는 없는 경우, 컨테이너는 더 많은 RAM을 +사용할 수 있다. + +해당 컨테이너에 대해 4GiB의 `memory` 제한을 설정하면, kubelet(그리고 +{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}})이 제한을 적용한다. +런타임은 컨테이너가 구성된 리소스 제한을 초과하여 사용하지 못하게 한다. 예를 들어, +컨테이너의 프로세스가 허용된 양보다 많은 메모리를 사용하려고 하면, +시스템 커널은 메모리 부족(out of memory, OOM) 오류와 함께 할당을 시도한 프로세스를 +종료한다. + +제한은 반응적(시스템이 위반을 감지한 후에 개입)으로 +또는 강제적(시스템이 컨테이너가 제한을 초과하지 않도록 방지)으로 구현할 수 있다. 런타임마다 +다른 방식으로 동일한 제약을 구현할 수 있다. + +## 리소스 타입 + +*CPU* 와 *메모리* 는 각각 *리소스 타입* 이다. 리소스 타입에는 기본 단위가 있다. +CPU는 컴퓨팅 처리를 나타내며 [쿠버네티스 CPU](#cpu의-의미) 단위로 지정된다. +메모리는 바이트 단위로 지정된다. +쿠버네티스 v1.14 이상을 사용하는 경우, _huge page_ 리소스를 지정할 수 있다. +Huge page는 노드 커널이 기본 페이지 크기보다 훨씬 큰 메모리 +블록을 할당하는 리눅스 관련 기능이다. + +예를 들어, 기본 페이지 크기가 4KiB인 시스템에서, `hugepages-2Mi: 80Mi` 제한을 +지정할 수 있다. 컨테이너가 40개 이상의 2MiB huge page(총 80MiB)를 +할당하려고 하면 해당 할당이 실패한다. + +{{< note >}} +`hugepages-*` 리소스를 오버커밋할 수 없다. +이것은 `memory` 및 `cpu` 리소스와는 다르다. +{{< /note >}} + +CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 그냥 *리소스* 라고 한다. 컴퓨트 +리소스는 요청, 할당 및 소비될 수 있는 측정 가능한 +수량이다. 이것은 +[API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및 +[서비스](/ko/docs/concepts/services-networking/service/)와 같은 API 리소스는 +쿠버네티스 API 서버를 통해 읽고 수정할 수 +있는 오브젝트이다. + +## 파드와 컨테이너의 리소스 요청 및 제한 + +파드의 각 컨테이너는 다음 중 하나 이상을 지정할 수 있다. + +* `spec.containers[].resources.limits.cpu` +* `spec.containers[].resources.limits.memory` +* `spec.containers[].resources.limits.hugepages-` +* `spec.containers[].resources.requests.cpu` +* `spec.containers[].resources.requests.memory` +* `spec.containers[].resources.requests.hugepages-` + +요청과 제한은 개별 컨테이너에서만 지정할 수 있지만, +파드 리소스 요청 및 제한에 대해 이야기하는 것이 편리하다. +특정 리소스 타입에 대한 *파드 리소스 요청/제한* 은 파드의 각 컨테이너에 대한 +해당 타입의 리소스 요청/제한의 합이다. + +## 쿠버네티스의 리소스 단위 + +### CPU의 의미 + +CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다. +쿠버네티스의 CPU 1개는 클라우드 공급자용 **vCPU/Core 1개** 와 베어메탈 인텔 프로세서에서의 **1개 하이퍼스레드** 에 해당한다. + +분수의 요청이 허용된다. +`0.5` 의 `spec.containers[].resources.requests.cpu` 요청을 가진 +컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은 +"백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은 +"백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다. +`0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 로 변환되며, +`1m` 도 허용되지 않게 정밀하다. 이러한 이유로, `100m` 형식이 +선호될 수 있다. + +CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다. +0.1은 단일 코어, 이중 코어 또는 48코어 시스템에서 동일한 양의 CPU이다. + +### 메모리의 의미 + +`memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다. +E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를 +일반 정수 또는 고정 소수점 정수로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 +같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다. + +```shell +128974848, 129e6, 129M, 123Mi +``` + +다음은 예제이다. +다음 파드에는 두 개의 컨테이너가 있다. 각 컨테이너에는 0.25 cpu와 +64MiB(226 바이트)의 메모리 요청이 있다. 각 컨테이너는 0.5 +cpu와 128MiB 메모리로 제한된다. 파드에 0.5 cpu와 128 MiB +메모리, 1 cpu와 256MiB 메모리 제한이 있다고 말할 수 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" + - name: wp + image: wordpress + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" +``` + +## 리소스 요청이 포함된 파드를 스케줄링하는 방법 + +파드를 생성할 때, 쿠버네티스 스케줄러는 파드를 실행할 노드를 +선택한다. 각 노드는 파드에 제공할 수 있는 CPU와 메모리 양과 같은 각 리소스 타입에 대해 +최대 용량을 갖는다. 스케줄러는 각 리소스 타입마다 +스케줄된 컨테이너의 리소스 요청 합계가 +노드 용량보다 작도록 한다. 참고로 노드의 실제 메모리나 +CPU 리소스 사용량은 매우 적지만, 용량 확인에 실패한 경우 +스케줄러는 여전히 노드에 파드를 배치하지 않는다. 이는 리소스 사용량이 +나중에 증가할 때, 예를 들어, 일일 요청 비율이 +최대일 때 노드의 리소스 부족을 방지한다. + +## 리소스 제한이 있는 파드가 실행되는 방법 + +kubelet은 파드의 컨테이너를 시작할 때, CPU와 메모리 제한을 +컨테이너 런타임으로 전달한다. + +도커를 사용하는 경우에는 다음과 같다. + +- `spec.containers[].resources.requests.cpu` 는 잠재적인 분수이며, + 1024를 곱한 값인 코어 값으로 변환된다. 이 숫자 또는 2보다 + 큰 값은 `docker run` 명령에서 + [`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint) + 플래그의 값으로 사용된다. + +- 이 `spec.containers[].resources.limits.cpu` 값은 밀리코어 값으로 변환되고 + 100을 곱한 값이다. 그 결과 값은 컨테이너가 100ms마다 사용할 수 있는 총 CPU + 시간이다. 이 간격 동안 컨테이너는 CPU 시간을 초과하여 사용할 수 없다. + + {{< note >}} + 기본 쿼터 기간은 100ms이다. 최소 CPU 쿼터는 1ms이다. + {{}} + +- `spec.containers[].resources.limits.memory` 는 정수로 변환되어, + `docker run` 명령에서 + [`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints) + 플래그의 값으로 사용된다. + +컨테이너가 메모리 제한을 초과하면, 컨테이너는 종료될 수 있다. 다시 +시작할 수 있으면, 다른 타입의 런타임 오류와 마찬가지로, kubelet이 다시 +시작한다. + +컨테이너가 메모리 요청을 초과하면, 노드에 메모리가 +부족할 때마다 파드가 축출될 수 있다. + +컨테이너가 오랫동안 CPU 제한을 초과하는 것은 허용되거나 허용되지 +않을 수 있다. 그러나, 과도한 CPU 사용으로 인해 종료되지는 않는다. + +리소스 제한으로 인해 컨테이너를 스케줄할 수 없는지 또는 +종료 중인지 확인하려면, +[문제 해결](#문제-해결) 섹션을 참조한다. + +### 컴퓨트 및 메모리 리소스 사용량 모니터링 + +파드의 리소스 사용량은 파드 상태의 일부로 보고된다. + +클러스터에서 선택적인 모니터링 도구를 +사용할 수 있다면, [메트릭 API](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-api)에서 +직접 또는 모니터링 도구에서 파드 리소스 +사용량을 검색할 수 있다. + +## 로컬 임시(ephemeral) 스토리지 + + +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +노드에는 로컬에 연결된 쓰기 가능 장치 또는, 때로는 RAM에 의해 +지원되는 로컬 임시 스토리지가 있다. +"임시"는 내구성에 대한 장기간의 보증이 없음을 의미한다. + +파드는 스크래치 공간, 캐싱 및 로그에 대해 임시 로컬 스토리지를 사용한다. +kubelet은 로컬 임시 스토리지를 사용하여 컨테이너에 +[`emptyDir`](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) +{{< glossary_tooltip term_id="volume" text="볼륨" >}}을 마운트하기 위해 파드에 스크래치 공간을 제공할 수 있다. + +kubelet은 이러한 종류의 스토리지를 사용하여 +[노드-레벨 컨테이너 로그](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅), +컨테이너 이미지 및 실행 중인 컨테이너의 쓰기 가능 계층을 보유한다. + +{{< caution >}} +노드가 실패하면, 임시 스토리지의 데이터가 손실될 수 있다. +애플리케이션은 로컬 임시 스토리지에서 성능에 대한 SLA(예: 디스크 IOPS)를 +기대할 수 없다. +{{< /caution >}} + +베타 기능에서, 쿠버네티스는 파드가 사용할 수 있는 임시 로컬 스토리지의 양을 +추적, 예약 및 제한할 수 있도록 해준다. + +### 로컬 임시 스토리지 구성 + +쿠버네티스는 노드에서 로컬 임시 스토리지를 구성하는 두 가지 방법을 지원한다. +{{< tabs name="local_storage_configurations" >}} +{{% tab name="단일 파일시스템" %}} +이 구성에서, 모든 종류의 임시 로컬 데이터(`emptyDir` 볼륨, +쓰기 가능 계층, 컨테이너 이미지, 로그)를 하나의 파일시스템에 배치한다. +kubelet을 구성하는 가장 효과적인 방법은 이 파일시스템을 쿠버네티스(kubelet) 데이터 전용으로 +하는 것이다. + +kubelet은 또한 +[노드-레벨 컨테이너 로그](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)를 +작성하고 임시 로컬 스토리지와 유사하게 처리한다. + +kubelet은 구성된 로그 디렉터리 내의 파일에 로그를 기록한다(기본적으로 +`/var/log`). 그리고 로컬에 저장된 다른 데이터에 대한 기본 디렉터리가 있다(기본적으로 +`/var/lib/kubelet`). + +일반적으로, `/var/lib/kubelet` 와 `/var/log` 모두 시스템 루트 파일시스템에 위치하고, +그리고 kubelet은 이런 레이아웃을 염두에 두고 설계되었다. + +노드는 쿠버네티스에서 사용하지 않는 다른 많은 파일시스템을 +가질 수 있다. +{{% /tab %}} +{{% tab name="두 개의 파일시스템" %}} +사용하고 있는 노드에 실행 중인 파드에서 발생하는 임시 데이터를 +위한 파일시스템을 가진다(로그와 `emptyDir` 볼륨). 이 파일시스템을 +다른 데이터(예를 들어, 쿠버네티스와 관련없는 시스템 로그)를 위해 사용할 수 있다. 이 파일시스템은 +루트 파일시스템일 수도 있다. + +kubelet은 또한 +[노드-레벨 컨테이너 로그](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)를 +첫 번째 파일시스템에 기록하고, 임시 로컬 스토리지와 유사하게 처리한다. + +또한 다른 논리 스토리지 장치가 지원하는 별도의 파일시스템을 사용한다. +이 구성에서, 컨테이너 이미지 계층과 쓰기 가능한 계층을 배치하도록 +kubelet에 지시하는 디렉터리는 이 두 번째 파일시스템에 있다. + +첫 번째 파일시스템에는 이미지 계층이나 쓰기 가능한 계층이 없다. + +노드는 쿠버네티스에서 사용하지 않는 다른 많은 파일시스템을 +가질 수 있다. +{{% /tab %}} +{{< /tabs >}} + +kubelet은 사용 중인 로컬 스토리지 양을 측정할 수 있다. 이것은 다음을 +제공한다. + +- `LocalStorageCapacityIsolation` + [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)(이 + 기능이 기본적으로 설정되어 있음)를 활성화하고, +- 로컬 임시 스토리지에 대한 지원되는 구성 중 하나를 + 사용하여 노드를 설정한다. + +다른 구성을 사용하는 경우, kubelet은 임시 로컬 스토리지에 대한 리소스 +제한을 적용하지 않는다. + +{{< note >}} +kubelet은 로컬 임시 스토리지가 아닌 컨테이너 메모리 사용으로 +`tmpfs` emptyDir 볼륨을 추적한다. +{{< /note >}} + +### 로컬 임시 스토리지에 대한 요청 및 제한 설정 + +_임시-스토리지_ 를 사용하여 로컬 임시 저장소를 관리할 수 있다. 파드의 각 컨테이너는 다음 중 하나 이상을 지정할 수 있다. + +* `spec.containers[].resources.limits.ephemeral-storage` +* `spec.containers[].resources.requests.ephemeral-storage` + +`ephemeral-storage` 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, K와 +같은 접미사 중 하나를 사용하여 스토리지를 일반 정수 또는 고정 소수점 정수로 표현할 수 있다. +Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. +예를 들어, 다음은 대략 동일한 값을 나타낸다. + +```shell +128974848, 129e6, 129M, 123Mi +``` + +다음 예에서, 파드에 두 개의 컨테이너가 있다. 각 컨테이너에는 2GiB의 로컬 임시 스토리지 요청이 있다. 각 컨테이너에는 4GiB의 로컬 임시 스토리지 제한이 있다. 따라서, 파드는 4GiB의 로컬 임시 스토리지 요청과 8GiB 스토리지 제한을 가진다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: db + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "password" + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + - name: wp + image: wordpress + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" +``` + +### 임시-스토리지 요청이 있는 파드의 스케줄링 방법 + +파드를 생성할 때, 쿠버네티스 스케줄러는 파드를 실행할 노드를 +선택한다. 각 노드에는 파드에 제공할 수 있는 최대 임시 스토리지 공간이 있다. 자세한 정보는, [노드 할당 가능](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)을 참조한다. + +스케줄러는 스케줄된 컨테이너의 리소스 요청 합계가 노드 용량보다 작도록 한다. + +### 임시 스토리지 소비 관리 {#resource-emphemeralstorage-consumption} + +kubelet이 로컬 임시 스토리지를 리소스로 관리하는 경우, +kubelet은 다음에서 스토리지 사용을 측정한다. + +- _tmpfs_ `emptyDir` 볼륨을 제외한 `emptyDir` 볼륨 +- 노드-레벨 로그가 있는 디렉터리 +- 쓰기 가능한 컨테이너 계층 + +허용하는 것보다 더 많은 임시 스토리지를 파드가 사용하는 경우, kubelet은 +파드 축출을 트리거하는 축출 신호를 설정한다. + +컨테이너-레벨 격리의 경우, 컨테이너의 쓰기 가능한 계층과 로그 +사용량이 스토리지 제한을 초과하면, kubelet은 파드를 축출하도록 표시한다. + +파드-레벨 격리에 대해 kubelet은 해당 파드의 컨테이너에 대한 제한을 합하여 +전체 파드 스토리지 제한을 해결한다. 이 경우, 모든 +컨테이너와 파드의 `emptyDir` 볼륨의 로컬 임시 스토리지 사용량 합계가 +전체 파드 스토리지 제한을 초과하면, kubelet은 파드를 축출 대상으로 +표시한다. + +{{< caution >}} +kubelet이 로컬 임시 스토리지를 측정하지 않는 경우, +로컬 스토리지 제한을 초과하는 파드는 로컬 스토리지 리소스 제한을 +위반해도 축출되지 않는다. + +그러나, 쓰기 가능한 컨테이너 계층, 노드-레벨 로그 +또는 `emptyDir` 볼륨의 파일 시스템 공간이 부족하면, 로컬 +스토리지가 부족하다고 노드 자체에 {{< glossary_tooltip text="테인트" term_id="taint" >}}되고 +이로인해 특별히 이 테인트를 허용하지 않는 모든 파드를 축출하도록 트리거한다. + +임시 로컬 스토리지에 대해 지원되는 [구성](#로컬-임시-스토리지-구성)을 +참조한다. +{{< /caution >}} + +kubelet은 파드 스토리지 사용을 측정하는 다양한 방법을 지원한다. + +{{< tabs name="resource-emphemeralstorage-measurement" >}} +{{% tab name="주기적 스캐닝" %}} +kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기 가능한 컨테이너 계층을 +스캔하는 정기적인 스케줄 검사를 수행한다. + +스캔은 사용된 공간의 양을 측정한다. + +{{< note >}} +이 모드에서, kubelet은 삭제된 파일의 열린 파일 디스크립터를 +추적하지 않는다. + +여러분(또는 컨테이너)이 `emptyDir` 볼륨 안에 파일을 생성하면, +그 파일이 열리고, 파일이 열려있는 동안 파일을 +삭제하면, 삭제된 파일의 inode는 해당 파일을 닫을 때까지 +유지되지만 kubelet은 사용 중인 공간으로 분류하지 않는다. +{{< /note >}} +{{% /tab %}} +{{% tab name="파일시스템 프로젝트 쿼터" %}} + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +프로젝트 쿼터는 파일시스템에서 스토리지 사용을 관리하기 위한 +운영체제 레벨의 기능이다. 쿠버네티스를 사용하면, 스토리지 사용을 +모니터링하기 위해 프로젝트 쿼터를 사용할 수 있다. 노드에서 'emptyDir' 볼륨을 +지원하는 파일시스템이 프로젝트 쿼터 지원을 제공하는지 확인한다. +예를 들어, XFS와 ext4fs는 프로젝트 쿼터를 지원한다. + +{{< note >}} +프로젝트 쿼터를 통해 스토리지 사용을 모니터링할 수 있다. 이는 제한을 강제하지 않는다. +{{< /note >}} + +쿠버네티스는 `1048576` 부터 프로젝트 ID를 사용한다. 사용 중인 ID는 +`/etc/projects` 와 `/etc/projid` 에 등록되어 있다. 이 범위의 프로젝트 ID가 +시스템에서 다른 목적으로 사용되는 경우, 쿠버네티스가 +이를 사용하지 않도록 해당 프로젝트 ID를 `/etc/projects` 와 `/etc/projid` 에 +등록해야 한다. + +쿼터는 디렉터리 검색보다 빠르고 정확하다. 디렉터리가 +프로젝트에 할당되면, 디렉터리 아래에 생성된 +모든 파일이 해당 프로젝트에 생성되며, 커널은 해당 프로젝트의 +파일에서 사용 중인 블록 수를 추적하기만 하면 된다. +파일이 생성되고 삭제되었지만, 열린 파일 디스크립터가 있으면, +계속 공간을 소비한다. 쿼터 추적은 공간을 정확하게 기록하는 반면 +디렉터리 스캔은 삭제된 파일이 사용한 스토리지를 간과한다. + +프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다. + +* kubelet 구성에서 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` + [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 + 활성화한다. + +* 루트 파일시스템(또는 선택적인 런타임 파일시스템)에 + 프로젝트 쿼터가 활성화되어 있는지 확인한다. 모든 XFS 파일시스템은 프로젝트 쿼터를 지원한다. + ext4 파일시스템의 경우, 파일시스템이 마운트되지 않은 상태에서 프로젝트 쿼터 + 추적 기능을 활성화해야 한다. + ```bash + # ext4인 /dev/block-device가 마운트되지 않은 경우 + sudo tune2fs -O project -Q prjquota /dev/block-device + ``` + +* 루트 파일시스템(또는 선택적인 런타임 파일시스템)은 프로젝트 쿼터를 + 활성화한 상태에서 마운트해야 힌다. XFS와 ext4fs 모두에서, + 마운트 옵션의 이름은 `prjquota` 이다. + +{{% /tab %}} +{{< /tabs >}} + +## 확장된 리소스 + +확장된 리소스는 `kubernetes.io` 도메인 외부의 전체 주소(fully-qualified) +리소스 이름이다. 쿠버네티스에 내장되지 않은 리소스를 클러스터 운영자가 알리고 +사용자는 사용할 수 있다. + +확장된 리소스를 사용하려면 두 단계가 필요한다. 먼저, 클러스터 +운영자는 확장된 리소스를 알려야 한다. 둘째, 사용자는 파드의 +확장된 리소스를 요청해야 한다. + +### 확장된 리소스 관리 + +#### 노드-레벨의 확장된 리소스 + +노드-레벨의 확장된 리소스는 노드에 연결된다. + +##### 장치 플러그인 관리 리소스 +각 노드에서 +장치 플러그인 관리 리소스를 알리는 방법은 +[장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 참조한다. + +##### 기타 리소스 +새로운 노드-레벨의 확장된 리소스를 알리기 위해, 클러스터 운영자는 +API 서버에 `PATCH` HTTP 요청을 제출하여 클러스터의 +노드에 대해 `status.capacity` 에서 사용할 수 있는 수량을 지정할 수 있다. 이 작업 +후에는, 노드의 `status.capacity` 에 새로운 리소스가 포함된다. 이 +`status.allocatable` 필드는 kubelet에 의해 비동기적으로 새로운 +리소스로 자동 업데이트된다. 참고로 스케줄러가 파드 적합성을 평가할 때 노드 +`status.allocatable` 값을 사용하므로, 노드 용량을 +새 리소스로 패치하는 것과 해당 노드에서 리소스를 스케줄하도록 요청하는 첫 번째 파드 +사이에 약간의 지연이 있을 수 있다. + +**예제:** + +다음은 `curl` 을 사용하여 마스터가 `k8s-master` 인 노드 `k8s-node-1` 에 +5개의 "example.com/foo" 리소스를 알리는 HTTP 요청을 구성하는 방법을 +보여주는 예이다. + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ +http://k8s-master:8080/api/v1/nodes/k8s-node-1/status +``` + +{{< note >}} +앞의 요청에서, `~1` 은 패치 경로에서 문자 `/` 의 +인코딩이다. JSON-Patch의 작업 경로 값은 +JSON-Pointer로 해석된다. 더 자세한 내용은, +[IETF RFC 6901, 섹션 3](https://tools.ietf.org/html/rfc6901#section-3)을 참조한다. +{{< /note >}} + +#### 클러스터-레벨의 확장된 리소스 + +클러스터-레벨의 확장된 리소스는 노드에 연결되지 않는다. 이들은 일반적으로 +리소스 소비와 리소스 쿼터를 처리하는 스케줄러 익스텐더(extender)에 의해 관리된다. + +[스케줄러 정책 구성](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)에서 +스케줄러 익스텐더가 +처리하는 확장된 리소스를 지정할 수 있다. + +**예제:** + +스케줄러 정책에 대한 다음의 구성은 클러스터-레벨의 확장된 리소스 +"example.com/foo"가 스케줄러 익스텐더에 의해 처리됨을 +나타낸다. + +- 파드가 "example.com/foo"를 요청하는 경우에만 스케줄러가 파드를 스케줄러 + 익스텐더로 보낸다. +- 이 `ignoredByScheduler` 필드는 스케줄러가 `PodFitsResources` 속성에서 + "example.com/foo" 리소스를 확인하지 않도록 지정한다. + +```json +{ + "kind": "Policy", + "apiVersion": "v1", + "extenders": [ + { + "urlPrefix":"", + "bindVerb": "bind", + "managedResources": [ + { + "name": "example.com/foo", + "ignoredByScheduler": true + } + ] + } + ] +} +``` + +### 확장된 리소스 소비 + +사용자는 CPU와 메모리 같은 파드 스펙의 확장된 리소스를 사용할 수 있다. +스케줄러는 리소스 어카운팅(resource accounting)을 관리하여 사용 가능한 양보다 +많은 양의 리소스가 여러 파드에 동시에 할당되지 않도록 한다. + +API 서버는 확장된 리소스의 수량을 정수로 제한한다. +_유효한_ 수량의 예로는 `3`, `3000m` 그리고 `3Ki` 를 들 수 있다. _유효하지 않은_ +수량의 예는 `0.5` 와 `1500m` 이다. + +{{< note >}} +확장된 리소스는 불명확한 정수 리소스를 대체한다. +사용자는 예약된 `kubernetes.io` 이외의 모든 도메인 이름 접두사를 사용할 수 있다. +{{< /note >}} + +파드에서 확장된 리소스를 사용하려면, 컨테이너 사양에서 `spec.containers[].resources.limits` +맵에 리소스 이름을 키로 포함한다. + +{{< note >}} +확장된 리소스는 오버커밋할 수 없으므로, 컨테이너 사양에 +둘 다 있으면 요청과 제한이 동일해야 한다. +{{< /note >}} + +파드는 CPU, 메모리 및 확장된 리소스를 포함하여 모든 리소스 요청이 +충족되는 경우에만 예약된다. 리소스 요청을 충족할 수 없다면 +파드는 `PENDING` 상태를 유지한다. + +**예제:** + +아래의 파드는 2개의 CPU와 1개의 "example.com/foo"(확장된 리소스)를 요청한다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + containers: + - name: my-container + image: myimage + resources: + requests: + cpu: 2 + example.com/foo: 1 + limits: + example.com/foo: 1 +``` + +## 문제 해결 + +### 내 파드가 failedScheduling 이벤트 메시지로 보류 중이다 + +파드가 배치될 수 있는 노드를 스케줄러가 찾을 수 없으면, 노드를 +찾을 수 있을 때까지 파드는 스케줄되지 않은 상태로 유지한다. 스케줄러가 다음과 같이 +파드의 위치를 ​​찾지 못하면 이벤트가 생성된다. + +```shell +kubectl describe pod frontend | grep -A 3 Events +``` +``` +Events: + FirstSeen LastSeen Count From Subobject PathReason Message + 36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others +``` + +위의 예에서, 노드의 CPU 리소스가 충분하지 않아 이름이 +"frontend"인 파드를 스케줄하지 못했다. 비슷한 메시지로 +메모리 부족(PodExceedsFreeMemory)으로 인한 장애도 알릴 수 있다. 일반적으로, 파드가 +이 타입의 메시지로 보류 중인 경우, 몇 가지 시도해 볼 것들이 있다. + +- 클러스터에 더 많은 노드를 추가한다. +- 불필요한 파드를 종료하여 보류 중인 파드를 위한 공간을 확보한다. +- 파드가 모든 노드보다 크지 않은지 확인한다. 예를 들어, 모든 + 노드의 용량이 `cpu: 1` 인 경우, `cpu: 1.1` 요청이 있는 파드는 + 절대 스케줄되지 않는다. + +`kubectl describe nodes` 명령으로 노드 용량과 할당된 양을 +확인할 수 있다. 예를 들면, 다음과 같다. + +```shell +kubectl describe nodes e2e-test-node-pool-4lw4 +``` +``` +Name: e2e-test-node-pool-4lw4 +[ ... 명확하게 하기 위해 라인들을 제거함 ...] +Capacity: + cpu: 2 + memory: 7679792Ki + pods: 110 +Allocatable: + cpu: 1800m + memory: 7474992Ki + pods: 110 +[ ... 명확하게 하기 위해 라인들을 제거함 ...] +Non-terminated Pods: (5 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- + kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) + kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) + kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) + kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) + kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 680m (34%) 400m (20%) 920Mi (12%) 1070Mi (14%) +``` + +위의 출력에서, ​파드가 1120m 이상의 CPU 또는 6.23Gi의 메모리를 +요청하는 것은 노드에 맞지 않음을 알 수 있다. + +`Pods` 섹션을 살펴보면, 파드가 노드에서 공간을 차지하는 것을 +볼 수 있다. + +시스템 데몬이 사용 가능한 리소스의 일부를 사용하기 때문에, 파드에 +사용 가능한 리소스의 양이 노드 용량보다 적다. `allocatable` 필드 +[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)는 +파드가 사용할 수 있는 리소스의 양을 제공한다. 자세한 정보는 +[노드 할당 가능 리소스](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md)를 참조한다. + +[리소스 쿼터](/ko/docs/concepts/policy/resource-quotas/) 기능은 +소비될 수 있는 리소스의 총량을 제한하도록 구성할 수 있다. 네임스페이스와 +함께 사용하면, 한 팀이 모든 리소스를 사용하는 경우를 방지할 수 있다. + +### 내 컨테이너가 종료되었다 + +리소스가 부족하여 컨테이너가 종료될 수 있다. 리소스 +제한에 도달하여 컨테이너가 종료되고 있는지 확인하려면, +관심있는 파드에 대해 `kubectl describe pod` 를 호출한다. + +```shell +kubectl describe pod simmemleak-hra99 +``` +``` +Name: simmemleak-hra99 +Namespace: default +Image(s): saadali/simmemleak +Node: kubernetes-node-tf0f/10.240.216.66 +Labels: name=simmemleak +Status: Running +Reason: +Message: +IP: 10.244.2.75 +Replication Controllers: simmemleak (1/1 replicas created) +Containers: + simmemleak: + Image: saadali/simmemleak + Limits: + cpu: 100m + memory: 50Mi + State: Running + Started: Tue, 07 Jul 2015 12:54:41 -0700 + Last Termination State: Terminated + Exit Code: 1 + Started: Fri, 07 Jul 2015 12:54:30 -0700 + Finished: Fri, 07 Jul 2015 12:54:33 -0700 + Ready: False + Restart Count: 5 +Conditions: + Type Status + Ready False +Events: + FirstSeen LastSeen Count From SubobjectPath Reason Message + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d + Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a +``` + +앞의 예제에서, `Restart Count: 5` 표시는 파드의 `simmemleak` +컨테이너가 종료되고 5번 다시 시작되었음을 나타낸다. + +이전에 종료된 컨테이너의 상태를 가져오기 위해 `-o go-template=...` 옵션을 사용해서 +`kubectl get pod` 를 호출할 수 있다. + +```shell +kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99 +``` +``` +Container Name: simmemleak +LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]] +``` + +컨테이너가 `reason:OOM Killed`(`OOM` 은 메모리 부족(Out Of Memory)의 약자) 때문에 종료된 것을 알 수 있다. + + + +{{% /capture %}} + + +{{% capture 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의 [프로젝트 쿼터](http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기 + +{{% /capture %}} diff --git a/content/ko/docs/concepts/configuration/pod-overhead.md b/content/ko/docs/concepts/configuration/pod-overhead.md new file mode 100644 index 0000000000..c5efc58c1e --- /dev/null +++ b/content/ko/docs/concepts/configuration/pod-overhead.md @@ -0,0 +1,193 @@ +--- +title: 파드 오버헤드 +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다. +이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다. +_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 +소비되는 리소스를 계산하는 기능이다. + + +{{% /capture %}} + + +{{% capture body %}} + +쿠버네티스에서 파드의 오버헤드는 파드의 +[런타임클래스](/ko/docs/concepts/containers/runtime-class/) 와 관련된 오버헤드에 따라 +[어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) +이 수행될 때 지정된다. + +파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에 +파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, Kubelet은 파드의 cgroups 크기를 변경하거나 +파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다. + +## 파드 오버헤드 활성화하기 {#set-up} + +기능 활성화를 위해 클러스터에서 +`PodOverhead` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 가 활성화 되어 있고 (1.18 버전에서는 기본적으로 활성화), +`overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다. + +## 사용 예제 + +파드 오버헤드 기능을 사용하기 위하여, `overhead` 필드를 정의하는 런타임클래스가 필요하다. +예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는 +가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다. + +```yaml +--- +kind: RuntimeClass +apiVersion: node.k8s.io/v1beta1 +metadata: + name: kata-fc +handler: kata-fc +overhead: + podFixed: + memory: "120Mi" + cpu: "250m" +``` + +`kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산, +노드 스케줄링 및 파드 cgroup 크기 조정을 위하여 메모리와 CPU 오버헤드를 고려한다. + +주어진 예제 워크로드 test-pod의 구동을 고려해보자. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + runtimeClassName: kata-fc + containers: + - name: busybox-ctr + image: busybox + stdin: true + tty: true + resources: + limits: + cpu: 500m + memory: 100Mi + - name: nginx-ctr + image: nginx + resources: + limits: + cpu: 1500m + memory: 100Mi +``` + +어드미션 수행 시에, [어드미션 컨트롤러](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)는 +런타임클래스에 기술된 `overhead` 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면, +파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가 +`overhead` 를 포함하도록 변경한다. + +런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다. + +```bash +kubectl get pod test-pod -o jsonpath='{.spec.overhead}' +``` + +명령 실행 결과는 다음과 같다. +``` +map[cpu:250m memory:120Mi] +``` + +만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는 +`overhead` 필드도 추가된다. + +kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와 +해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는 +리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다. + +일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다. +기본 컨테이너 런타임이 만들어내는 컨테이너들은 이 파드 안에 존재한다. + +만약 각 컨테이너에 대하여 QoS가 보장되었거나 향상이 가능하도록 QoS 의 리소스 상한 제한이 걸려있으면, +kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의 +cgroup 의 상한선을 설정한다. 이 상한선은 컨테이너 리소스 상한과 PodSpec에 +정의된 `overhead` 의 합에 기반한다. + +CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의 +리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다. + +다음의 예제를 참고하여, 워크로드에 대하여 컨테이너의 리소스 요청을 확인하자. +```bash +kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' +``` + +컨테이너 리소스 요청의 합은 각각 CPU 2000m 와 메모리 200MiB 이다. +``` +map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] +``` + +노드에서 측정된 내용과 비교하여 확인해보자. + +```bash +kubectl describe node | grep test-pod -B2 +``` + +CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는 파드의 오버헤드를 포함한다. +``` + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE + --------- ---- ------------ ---------- --------------- ------------- --- + default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m +``` + +## 파드 cgroup 상한 확인하기 + +워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, +CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다. +파드의 오버헤드 동작을 보여주는 좋은 예이며, +사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다. + +먼저 특정 노드에서 파드의 식별자를 확인해 보자. + +```bash +# 파드가 스케줄 된 노드에서 이것을 실행 +POD_ID="$(sudo crictl pods --name test-pod -q)" +``` + +여기에서, 파드의 cgroup 경로를 확인할 수 있다. +```bash +# 파드가 스케줄 된 노드에서 이것을 실행 +sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath +``` + +명령의 결과로 나온 cgroup 경로는 파드의 `pause` 컨테이너를 포함한다. 파드 레벨의 cgroup은 하나의 디렉터리이다. +``` + "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" +``` + +아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. 메모리의 파드 레벨 cgroup 설정을 확인하자. +```bash +# 파드가 스케줄 된 노드에서 이것을 실행. +# 또한 사용자의 파드에 할당된 cgroup 이름에 맞춰 해당 이름을 수정. + cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes +``` + +예상대로 320 MiB 이다. +``` +335544320 +``` + +### 관찰성 +`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) +에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고, +정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다. +이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다. +그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [런타임클래스](/ko/docs/concepts/containers/runtime-class/) +* [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) + +{{% /capture %}} diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/configuration/pod-priority-preemption.md new file mode 100644 index 0000000000..a69013f5bd --- /dev/null +++ b/content/ko/docs/concepts/configuration/pod-priority-preemption.md @@ -0,0 +1,417 @@ +--- +title: 파드 우선순위(priority)와 선점(preemption) +content_template: templates/concept +weight: 70 +--- + +{{% capture overview %}} + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +[파드](/ko/docs/concepts/workloads/pods/pod/)는 _우선순위_ 를 가질 수 있다. 우선순위는 +다른 파드에 대한 상대적인 파드의 중요성을 나타낸다. 파드를 스케줄링할 수 없는 경우, +스케줄러는 우선순위가 낮은 파드를 선점(축출)하여 보류 중인 파드를 +스케줄링할 수 있게 한다. + +{{% /capture %}} + +{{% capture body %}} + + +{{< warning >}} +모든 사용자를 신뢰할 수 없는 클러스터에서, 악의적인 사용자가 우선순위가 +가장 높은 파드를 생성하여 다른 파드가 축출되거나 스케줄링되지 +않을 수 있다. +관리자는 리소스쿼터를 사용하여 사용자가 우선순위가 높은 파드를 생성하지 +못하게 할 수 있다. + +자세한 내용은 [기본적으로 프라이어리티 클래스(Priority Class) 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 +참고한다. +{{< /warning >}} + +## 우선순위와 선점을 사용하는 방법 + +우선순위와 선점을 사용하려면 다음을 참고한다. + +1. 하나 이상의 [프라이어리티클래스](#프라이어리티클래스)를 추가한다. + +1. 추가된 프라이어리티클래스 중 하나에 [`priorityClassName`](#파드-우선순위)이 설정된 + 파드를 생성한다. 물론 파드를 직접 생성할 필요는 없다. + 일반적으로 디플로이먼트와 같은 컬렉션 오브젝트의 파드 템플릿에 `priorityClassName` + 을 추가한다. + +이 단계에 대한 자세한 내용은 계속 읽어보자. + +{{< note >}} +쿠버네티스는 이미 `system-cluster-critical` 과 `system-node-critical`, +두 개의 프라이어리티클래스를 제공한다. +이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다. +{{< /note >}} + +기능을 사용해 본 후 사용하지 않기로 했다면, PodPriority +커맨드-라인 플래그를 제거하거나 `false` 로 설정한 후, API 서버와 +스케줄러를 다시 시작해야 한다. 기능이 비활성화된 후, 기존 파드는 +우선순위 필드를 유지하지만, 선점은 비활성화되며, 우선순위 필드는 +무시된다. 이 기능이 비활성화되면, 새로운 파드에서 `priorityClassName` 을 설정할 수 +없다. + +## 선점을 비활성화하는 방법 + +{{< caution >}} +중요 파드는 클러스터에 리소스 압박(resource pressure)이 가해지면 +스케줄러 선점에 따라 스케줄링된다. 이런 이유로, 선점을 비활성화하지 +않는 것을 권장한다. +{{< /caution >}} + +{{< note >}} +쿠버네티스 1.15 이상에서, `NonPreemptingPriority` 기능이 활성화된 경우, +프라이어리티클래스는 옵션을 `preemptionPolicy: Never` 로 설정할 수 있다. +이렇게 하면 해당 프라이어리티클래스의 파드가 다른 파드를 축출할 수 없다. +{{< /note >}} + +선점은 기본값이 `false`로 설정된 `disablePreemption` kube-scheduler +플래그에 의해 제어된다. +위의 주의에도 불구하고 선점을 비활성화하려는 경우, +`disablePreemption` 을 `true` 로 설정할 수 있다. + +이 옵션은 컴포넌트 구성에서만 사용할 수 있으며 +이전 스타일의 커맨드 라인 옵션에서는 사용할 수 없다. 다음은 선점을 비활성화하는 샘플 컴포넌트 +구성이다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1alpha1 +kind: KubeSchedulerConfiguration +algorithmSource: + provider: DefaultProvider + +... + +disablePreemption: true +``` + +## 프라이어리티클래스 + +프라이어리티클래스는 프라이어리티 클래스 이름에서 우선순위의 정수 값으로의 매핑을 +정의하는 네임스페이스가 아닌(non-namespaced) 오브젝트이다. 이름은 +프라이어리티클래스 오브젝트의 메타데이터의 `name` 필드에 지정된다. 값은 +필수 `value` 필드에 지정되어 있다. 값이 클수록, 우선순위가 +높다. +프라이어리티클래스 오브젝트의 이름은 유효한 +[DNS 서브 도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 하며, +`system-` 접두사를 붙일 수 없다. + +프라이어리티클래스 오브젝트는 10억 이하의 32비트 정수 값을 가질 +수 있다. 일반적으로 선점하거나 축출해서는 안되는 중요한 시스템 파드에는 더 큰 숫자가 +예약되어 있다. 클러스터 관리자는 원하는 각 매핑에 대해 프라이어리티클래스 오브젝트를 +하나씩 생성해야 한다. + +프라이어리티클래스에는 `globalDefault` 와 `description` 두 개의 선택적인 필드도 있다. +`globalDefault` 필드는 이 프라이어리티클래스의 값을 `priorityClassName` 이 없는 +파드에 사용해야 함을 나타낸다. 시스템에서 `globalDefault` 가 `true` 로 설정된 +프라이어리티클래스는 하나만 존재할 수 있다. `globalDefault` 가 설정된 +프라이어리티클래스가 없을 경우, `priorityClassName` 이 없는 파드의 +우선순위는 0이다. + +`description` 필드는 임의의 문자열이다. 이 필드는 이 프라이어리티클래스를 언제 +사용해야 하는지를 클러스터 사용자에게 알려주기 위한 것이다. + +### PodPriority와 기존 클러스터에 대한 참고 사항 + +- 기존 클러스터를 업그레이드하고 이 기능을 활성화하면, 기존 파드의 + 우선순위는 사실상 0이다. + +- `globalDefault` 가 `true` 로 설정된 프라이어리티클래스를 추가해도 기존 파드의 + 우선순위는 변경되지 않는다. 이러한 프라이어리티클래스의 값은 + 프라이어리티클래스를 추가한 후 생성된 파드에만 사용된다. + +- 프라이어리티클래스를 삭제하면, 삭제된 프라이어리티클래스의 이름을 사용하는 + 기존 파드는 변경되지 않고 남아있지만, 삭제된 프라이어리티클래스의 이름을 + 사용하는 파드는 더 이상 생성할 수 없다. + +### 프라이어리티클래스 예제 + +```yaml +apiVersion: scheduling.k8s.io/v1 +kind: PriorityClass +metadata: + name: high-priority +value: 1000000 +globalDefault: false +description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사용해야 한다." +``` + +## 비-선점 프라이어리티클래스 {#non-preempting-priority-class} + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +`PreemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의 +앞쪽에 배치되지만, +그 파드는 다른 파드를 축출할 수 없다. +스케줄링 대기 중인 비-선점 파드는 충분한 리소스가 확보되고 +스케줄링될 수 있을 때까지 +스케줄링 대기열에 대기한다. +다른 파드와 마찬가지로, +비-선점 파드는 +스케줄러 백오프(back-off)에 종속된다. +이는 스케줄러가 이러한 파드를 스케줄링하려고 시도하고 스케줄링할 수 없는 경우, +더 적은 횟수로 재시도하여, +우선순위가 낮은 다른 파드를 미리 스케줄링할 수 있음을 의미한다. + +비-선점 파드는 다른 우선순위가 높은 파드에 의해 +축출될 수 있다. + +`PreemptionPolicy` 는 기본값으로 `PreemptLowerPriority` 로 설정되어, +해당 프라이어리티클래스의 파드가 우선순위가 낮은 파드를 축출할 수 +있다(기존의 기본 동작과 동일). +`PreemptionPolicy` 가 `Never` 로 설정된 경우, +해당 프라이어리티클래스의 파드는 비-선점될 것이다. + +`PreemptionPolicy` 필드를 사용하려면 `NonPreemptingPriority` +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 +활성화되어야 한다. + +예제 유스케이스는 데이터 과학 관련 워크로드이다. +사용자는 다른 워크로드보다 우선순위가 높은 잡(job)을 제출할 수 있지만, +실행 중인 파드를 축출하여 기존의 작업을 삭제하지는 않을 것이다. +클러스터 리소스가 "자연스럽게" 충분히 사용할 수 있게 되면, +`PreemptionPolicy: Never` 의 우선순위가 높은 잡이 +다른 대기 중인 파드보다 먼저 스케줄링된다. + +### 비-선점 프라이어리티클래스 예제 + +```yaml +apiVersion: scheduling.k8s.io/v1 +kind: PriorityClass +metadata: + name: high-priority-nonpreempting +value: 1000000 +preemptionPolicy: Never +globalDefault: false +description: "이 프라이어리티 클래스는 다른 파드를 축출하지 않는다." +``` + +## 파드 우선순위 + +프라이어리티클래스가 하나 이상 있으면, 그것의 명세에서 이들 프라이어리티클래스 이름 중 하나를 +지정하는 파드를 생성할 수 있다. 우선순위 어드미션 +컨트롤러는 `priorityClassName` 필드를 사용하고 우선순위의 정수 값을 +채운다. 프라이어리티 클래스를 찾을 수 없으면, 파드가 거부된다. + +다음의 YAML은 이전 예제에서 생성된 프라이어리티클래스를 +사용하는 파드 구성의 예이다. 우선순위 어드미션 컨트롤러는 +명세를 확인하고 파드의 우선순위를 1000000으로 +해석한다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + priorityClassName: high-priority +``` + +### 스케줄링 순서에 대한 파드 우선순위의 영향 + +파드 우선순위가 활성화되면, 스케줄러가 우선순위에 따라 보류 중인 +파드를 주문하고 보류 중인 파드는 스케줄링 대기열에서 +우선순위가 낮은 다른 보류 중인 파드보다 우선한다. 결과적으로, 스케줄링 +요구 사항이 충족되는 경우 우선순위가 더 낮은 파드보다 우선순위가 높은 파드가 +더 빨리 스케줄링될 수 있다. 이러한 파드를 스케줄링할 수 없는 경우, +스케줄러는 계속 진행하고 우선순위가 낮은 다른 파드를 스케줄링하려고 한다. + +## 선점 + +파드가 생성되면, 대기열로 이동하여 스케줄링을 기다린다. +스케줄러가 대기열에서 파드를 선택하여 노드에 스케줄링하려고 한다. +파드의 지정된 모든 요구 사항을 충족하는 노드가 없으면, +보류 중인 파드에 대해 선점 로직이 트리거된다. 보류 중인 파드를 P라 하자. +선점 로직은 P보다 우선순위가 낮은 하나 이상의 파드를 제거하면 +해당 노드에서 P를 스케줄링할 수 있는 노드를 찾는다. 이러한 +노드가 발견되면, 하나 이상의 우선순위가 낮은 파드가 노드에서 축출된다. +파드가 축출된 후, P는 노드에 스케줄링될 수 있다. + +### 사용자 노출 정보 + +파드 P가 노드 N에서 하나 이상의 파드를 축출할 경우, 파드 P의 상태 `nominatedNodeName` +필드는 노드 N의 이름으로 설정된다. 이 필드는 스케줄러가 파드 P에 +예약된 리소스를 추적하는 데 도움이 되고 사용자에게 클러스터의 선점에 대한 +정보를 제공한다. + +파드 P는 반드시 "지정된 노드"로 스케줄링되지는 않는다. +피해자 파드가 축출된 후, 그것은 정상적(graceful)으로 종료되는 기간을 갖는다. +스케줄러가 종료될 피해자 파드를 기다리는 동안 다른 노드를 사용할 수 +있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용한다. 그 결과, +파드 스펙의 `nominatedNodeName` 과 `nodeName` 은 항상 동일하지 않다. 또한, +스케줄러가 노드 N에서 파드를 축출했지만, 파드 P보다 우선순위가 높은 파드가 +도착하면, 스케줄러가 노드 N에 새로운 우선순위가 높은 파드를 제공할 수 있다. 이러한 +경우, 스케줄러는 파드 P의 `nominatedNodeName` 을 지운다. 이렇게하면, 스케줄러는 +파드 P가 다른 노드에서 파드를 축출할 수 있도록 한다. + +### 선점의 한계 + +#### 선점 피해자의 정상적인 종료 + +파드가 축출되면, 축출된 피해자 파드는 +[정상적인 종료 기간](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)을 가진다. +피해자 파드는 작업을 종료하고 빠져나가는 데(exit) 많은 시간을 가진다. 그렇지 않으면, +파드는 강제종료(kill) 된다. 이 정상적인 종료 기간은 스케줄러가 파드를 축출하는 +지점과 보류 중인 파드(P)를 노드(N)에서 스케줄링할 수 있는 시점 사이의 +시간 간격을 만든다. 그 동안, 스케줄러는 보류 중인 다른 파드를 +계속 스케줄링한다. 피해자 파드가 빠져나가거나 종료되면, 스케줄러는 보류 대기열에서 +파드를 스케줄하려고 한다. 따라서, 일반적으로 스케줄러가 피해자 파드를 축출하는 시점과 +파드 P가 스케줄링된 시점 사이에 시간 간격이 있다. +이러한 차이를 최소화하기 위해, 우선순위가 낮은 파드의 정상적인 종료 기간을 0 또는 +작은 수로 설정할 수 있다. + +#### PodDisruptionBudget을 지원하지만, 보장하지 않음 + +[Pod Disruption Budget(PDB)](/ko/docs/concepts/workloads/pods/disruptions/)은 +애플리케이션 소유자가 자발적 중단에서 동시에 다운된 복제된 +애플리케이션의 파드 수를 제한할 수 있다. 쿠버네티스는 파드를 +선점할 때 PDB를 지원하지만, PDB를 따르는 것이 최선의 노력이다. 스케줄러는 +선점에 의해 PDB를 위반하지 않은 피해자 파드를 찾으려고 하지만, 그러한 피해자 파드가 +발견되지 않으면, 선점은 여전히 발생하며, PDB를 위반하더라도 우선순위가 +낮은 파드는 제거된다. + +#### 우선순위가 낮은 파드에 대한 파드-간 어피니티 + +이 질문에 대한 답변이 '예'인 경우에만 노드가 선점 대상으로 간주된다. +"대기 중인 파드보다 우선순위가 낮은 모든 파드가 노드에서 +제거되면, 보류 중인 파드를 노드에 스케줄링할 수 있습니까?" + +{{< note >}} +선점으로 우선순위가 낮은 모든 파드를 반드시 제거할 필요는 +없다. 우선순위가 낮은 모든 파드보다 적은 수를 제거하여 보류 중인 파드를 +스케줄링할 수 있는 경우, 우선순위가 낮은 파드의 일부만 제거된다. +그럼에도 불구하고, 앞의 질문에 대한 대답은 '예'여야 한다. 답변이 '아니오'인 경우, +노드가 선점 대상으로 간주되지 않는다. +{{< /note >}} + +보류 중인 파드가 노드에 있는 하나 이상의 우선순위가 낮은 파드에 대한 파드-간 어피니티를 +가진 경우에, 우선순위가 낮은 파드가 없을 때 파드-간 어피니티 규칙을 +충족할 수 없다. 이 경우, 스케줄러는 노드의 파드를 축출하지 +않는다. 대신, 다른 노드를 찾는다. 스케줄러가 +적합한 노드를 찾거나 찾지 못할 수 있다. 보류 중인 파드를 스케줄링할 수 있다는 +보장은 없다. + +이 문제에 대한 권장 솔루션은 우선순위가 같거나 높은 파드에 대해서만 파드-간 어피니티를 +생성하는 것이다. + +#### 교차 노드 선점 + +보류 중인 파드 P가 노드 N에 스케줄링될 수 있도록 노드 N이 선점 대상으로 고려되고 +있다고 가정한다. 다른 노드의 파드가 축출된 경우에만 P가 N에서 실행 가능해질 수 +있다. 예를 들면 다음과 같다. + +* 파드 P는 노드 N에 대해 고려된다. +* 파드 Q는 노드 N과 동일한 영역의 다른 노드에서 실행 중이다. +* 파드 P는 파드 Q(`topologyKey: + failure-domain.beta.kubernetes.io/zone`)와 영역(zone) 전체의 안티-어피니티를 갖는다. +* 영역에서 파드 P와 다른 파드 간의 안티-어피니티에 대한 다른 경우는 + 없다. +* 노드 N에서 파드 P를 스케줄링하기 위해, 파드 Q를 축출할 수 있지만, 스케줄러는 + 교차-노드 선점을 수행하지 않는다. 따라서, 파드 P가 노드 N에서 + 스케줄링할 수 없는 것으로 간주된다. + +파드 Q가 노드에서 제거되면, 파드 안티-어피니티 위반이 +사라지고, 파드 P는 노드 N에서 스케줄링될 수 있다. + +수요가 충분하고 합리적인 성능의 알고리즘을 찾을 경우 +향후 버전에서 교차 노드 선점의 추가를 고려할 수 있다. + +## 문제 해결 + +파드 우선순위와 선점은 원하지 않는 부작용을 가질 수 있다. 다음은 +잠재적 문제의 예시와 이를 해결하는 방법이다. + +### 파드가 불필요하게 선점(축출)됨 + +선점은 우선순위가 높은 보류 중인 파드를 위한 공간을 만들기 위해 리소스 압박을 받고 있는 +클러스터에서 기존 파드를 제거한다. 실수로 특정 파드에 높은 우선순위를 +부여하면, 의도하지 않은 높은 우선순위 파드가 클러스터에서 +선점을 유발할 수 있다. 파드 우선순위는 파드 명세에서 +`priorityClassName` 필드를 설정하여 지정한다. 그런 다음 +우선순위의 정수 값이 분석되어 `podSpec` 의 `priority` 필드에 채워진다. + +문제를 해결하기 위해, 해당 파드가 우선순위가 낮은 클래스를 사용하도록 `priorityClassName` 을 +변경하거나, 해당 필드를 비워둘 수 있다. 빈 +`priorityClassName` 은 기본값이 0으로 해석된다. + +파드가 축출되면, 축출된 파드에 대한 이벤트가 기록된다. +선점은 클러스터가 파드에 대한 리소스를 충분히 가지지 못한 경우에만 +발생한다. 이러한 경우, 선점은 보류 중인 파드(선점자)의 우선순위가 +피해자 파드보다 높은 경우에만 발생한다. 보류 중인 파드가 없거나, +보류 중인 파드의 우선순위가 피해자 파드와 같거나 낮은 경우 +선점이 발생하지 않아야 한다. 그러한 시나리오에서 선점이 발생하면, 이슈를 올리기 바란다. + +### 파드가 축출되었지만, 선점자는 스케줄링되지 않음 + +파드가 축출되면, 요청된 정상적인 종료 +기간(기본적으로 30초)이 주어진다. 이 기간 내에 대상 파드가 +종료되지 않으면, 강제 종료된다. 모든 피해자 파드가 사라지면, +선점자 파드를 스케줄링할 수 있다. + +선점자 파드가 피해자 파드가 없어지기를 기다리는 동안, 동일한 노드에 +적합한 우선순위가 높은 파드가 생성될 수 있다. 이 경우, 스케줄러는 +선점자 대신 우선순위가 높은 파드를 스케줄링한다. + +이것은 예상된 동작이다. 우선순위가 높은 파드는 우선순위가 낮은 파드를 +대체해야 한다. [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)과 +같은 다른 컨트롤러 작업은, +결국 보류 중인 파드를 스케줄링할 수 있는 용량을 제공할 수 있다. + +### 우선순위가 높은 파드는 우선순위가 낮은 파드보다 우선함 + +스케줄러가 보류 중인 파드를 실행할 수 있는 노드를 찾으려고 한다. 노드를 찾지 +못하면, 스케줄러는 임의의 노드에서 우선순위가 낮은 파드를 제거하여 +보류 중인 파드를 위한 공간을 만든다. +우선순위가 낮은 파드가 있는 노드가 보류 중인 파드를 실행할 수 없는 경우, 스케줄러는 +선점을 위해 우선순위가 높은 다른 노드(다른 노드의 파드와 비교)를 +선택할 수 있다. 피해자 파드는 여전히 선점자 파드보다 우선순위가 +낮아야 한다. + +선점할 수 있는 여러 노드가 있는 경우, 스케줄러는 +우선순위가 가장 낮은 파드 세트를 가진 노드를 선택하려고 한다. 그러나, +이러한 파드가 위반될 PodDisruptionBudget을 가지고 있고 축출된 경우 +스케줄러는 우선순위가 높은 파드를 가진 다른 노드를 선택할 수 있다. + +선점을 위해 여러 개의 노드가 존재하고 위의 시나리오 중 어느 것도 적용되지 않는 경우, +스케줄러는 우선순위가 가장 낮은 노드를 선택한다. + +## 파드 우선순위와 서비스 품질 간의 상호 작용 {#interactions-of-pod-priority-and-qos} + +파드 우선순위와 {{< glossary_tooltip text="QoS 클래스" term_id="qos-class" >}}는 +상호 작용이 거의 없고 QoS 클래스를 기반으로 파드 우선순위를 설정하는 데 대한 +기본 제한이 없는 두 개의 직교(orthogonal) 기능이다. 스케줄러의 +선점 로직은 선점 대상을 선택할 때 QoS를 고려하지 않는다. +선점은 파드 우선순위를 고려하고 우선순위가 가장 낮은 대상 세트를 +선택하려고 한다. 우선순위가 가장 높은 파드는 스케줄러가 +선점자 파드를 스케줄링할 수 없거나 우선순위가 가장 낮은 파드가 +`PodDisruptionBudget` 으로 보호되는 경우에만, 우선순위가 가장 낮은 파드를 +축출 대상으로 고려한다. + +QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는 +[kubelet 리소스 부족 축출](/docs/tasks/administer-cluster/out-of-resource/)이다. +kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라, +파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해 +먼저 축출 대상 파드의 순위를 매긴다. +더 자세한 내용은 +[엔드유저 파드 축출](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)을 +참조한다. + +kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우 +파드를 축출하지 않는다. 우선순위가 낮은 파드가 요청을 +초과하지 않으면, 축출되지 않는다. 요청을 초과하는 우선순위가 +더 높은 다른 파드가 축출될 수 있다. + +{{% /capture %}} +{{% capture whatsnext %}} +* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자. +{{% /capture %}} diff --git a/content/ko/docs/concepts/configuration/resource-bin-packing.md b/content/ko/docs/concepts/configuration/resource-bin-packing.md index 976e2ec837..5b6af1c661 100644 --- a/content/ko/docs/concepts/configuration/resource-bin-packing.md +++ b/content/ko/docs/concepts/configuration/resource-bin-packing.md @@ -1,7 +1,7 @@ --- title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing) content_template: templates/concept -weight: 10 +weight: 50 --- {{% capture overview %}} diff --git a/content/ko/docs/concepts/configuration/taint-and-toleration.md b/content/ko/docs/concepts/configuration/taint-and-toleration.md index 012924c75d..ed59926d17 100644 --- a/content/ko/docs/concepts/configuration/taint-and-toleration.md +++ b/content/ko/docs/concepts/configuration/taint-and-toleration.md @@ -198,7 +198,7 @@ tolerations: ## 테인트 기반 축출 -{{< feature-state for_k8s_version="1.18" state="stable" >}} +{{< feature-state for_k8s_version="v1.18" state="stable" >}} 앞에서 우리는 노드에서 이미 실행 중인 파드에 영향을 주는 `NoExecute` 테인트 이펙트를 다음과 같이 언급했다. 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 e7e380d6ba..84481bdec7 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 @@ -78,7 +78,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트 - 클라이언트는 "이 작업을 수행한다"라고 말하고 완료되면 동기(synchronous) 응답을 받는다. - 클라이언트는 "이 작업을 수행한다"라고 말한 다음 작업 ID를 다시 가져오고 별도의 오퍼레이션(operation) 오브젝트를 확인하여 요청의 완료 여부를 결정해야 한다. - RPC(원격 프로시저 호출)에 대해 얘기한다. - - 대량의 데이터를 직접 저장한다(예: > 오브젝트별 몇 kB 또는 >1000개의 오브젝트). + - 대량의 데이터를 직접 저장한다. 예: > 오브젝트별 몇 kB 또는 > 1000개의 오브젝트. - 높은 대역폭 접근(초당 10개의 지속적인 요청)이 필요하다. - 최종 사용자 데이터(예: 이미지, PII 등) 또는 애플리케이션에서 처리한 기타 대규모 데이터를 저장한다. - 오브젝트에 대한 자연스러운 조작은 CRUD-y가 아니다. @@ -102,7 +102,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트 다음 중 대부분이 적용되는 경우 커스텀 리소스(CRD 또는 애그리게이트 API(aggregated API))를 사용하자. * 쿠버네티스 클라이언트 라이브러리 및 CLI를 사용하여 새 리소스를 만들고 업데이트하려고 한다. -* kubectl의 최상위 지원을 원한다(예: `kubectl get my-object object-name`). +* `kubectl` 의 최상위 지원을 원한다. 예: `kubectl get my-object object-name`. * 새 오브젝트에 대한 업데이트를 감시한 다음 다른 오브젝트를 CRUD하거나 그 반대로 하는 새로운 자동화를 구축하려고 한다. * 오브젝트의 업데이트를 처리하는 자동화를 작성하려고 한다. * `.spec`, `.status` 및 `.metadata`와 같은 쿠버네티스 API 규칙을 사용하려고 한다. @@ -214,7 +214,7 @@ CRD 또는 AA를 통해 커스텀 리소스를 생성하면 쿠버네티스 플 ### 써드파티 코드 및 새로운 장애 포인트 -CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는 CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는 써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다. +CRD를 생성해도 새로운 장애 포인트(예를 들어, API 서버에서 장애를 유발하는 써드파티 코드가 실행됨)가 자동으로 추가되지는 않지만, 패키지(예: 차트(Charts)) 또는 기타 설치 번들에는 CRD 및 새로운 커스텀 리소스에 대한 비즈니스 로직을 구현하는 써드파티 코드의 디플로이먼트가 포함되는 경우가 종종 있다. 애그리게이트 API 서버를 설치하려면 항상 새 디플로이먼트를 실행해야 한다. @@ -234,11 +234,11 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부 ## 커스텀 리소스에 접근 -쿠버네티스 [클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. Go와 python 클라이언트 라이브러리가 지원한다. +쿠버네티스 [클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다. 커스텀 리소스를 추가하면 다음을 사용하여 접근할 수 있다. -- kubectl +- `kubectl` - 쿠버네티스 동적 클라이언트 - 작성한 REST 클라이언트 - [쿠버네티스 클라이언트 생성 도구](https://github.com/kubernetes/code-generator)를 사용하여 생성된 클라이언트(하나를 생성하는 것은 고급 기능이지만, 일부 프로젝트는 CRD 또는 AA와 함께 클라이언트를 제공할 수 있다). diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 6fc04ab7bf..9db222e271 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -56,18 +56,19 @@ card: ### cloud-controller-manager -[cloud-controller-manager](/docs/tasks/administer-cluster/running-cloud-controller/)는 바탕을 이루는 클라우드 제공사업자와 상호작용하는 컨트롤러를 작동시킨다. cloud-controller-manager 바이너리는 쿠버네티스 릴리스 1.6에서 도입된 알파 기능이다. +cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. +자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 +클러스터에는 클라우드 컨트롤러 매니저가 없다. -cloud-controller-manager는 클라우드-제공사업자-특유 컨트롤러 루프만을 동작시킨다. 이 컨트롤러 루프는 kube-controller-manager에서 비활성 시켜야만 한다. kube-controller-manager를 구동시킬 때 `--cloud-provider` 플래그를 `external`로 설정함으로써 이 컨트롤러 루프를 비활성 시킬 수 있다. +kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적으로 +독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합한다. +수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애를 견딜 수 있다. -cloud-controller-manager는 클라우드 벤더 코드와 쿠버네티스 코드가 서로 독립적으로 발전시켜 나갈 수 있도록 해준다. 이전 릴리스에서는 코어 쿠버네티스 코드가 기능상으로 클라우드-제공사업자-특유 코드에 대해 의존적이었다. 향후 릴리스에서 클라우드 벤더만의 코드는 클라우드 벤더가 유지해야 하며, 쿠버네티스가 동작하는 동안 cloud-controller-manager에 연계되도록 해야 한다. +다음 컨트롤러들은 클라우드 제공 사업자의 의존성을 가질 수 있다. -다음 컨트롤러들은 클라우드 제공사업자의 의존성을 갖는다. - - * 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공사업자에게 확인하는 것 + * 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하는 것 * 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하는 것 - * 서비스 컨트롤러: 클라우드 제공사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것 - * 볼륨 컨트롤러: 볼륨의 생성, 연결 그리고 마운트 하는 것과 오케스트레이션하기 위해 클라우드 제공사업자와 상호작용하는 것 + * 서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제하는 것 ## 노드 컴포넌트 @@ -121,6 +122,6 @@ cloud-controller-manager는 클라우드 벤더 코드와 쿠버네티스 코드 {{% capture whatsnext %}} * [노드](/ko/docs/concepts/architecture/nodes/)에 대해 더 배우기 * [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 더 배우기 -* [kube-scheduler](/ko/docs/concepts/scheduling/kube-scheduler/)에 대해 더 배우기 +* [kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 더 배우기 * etcd의 공식 [문서](https://etcd.io/docs/) 읽기 {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index c62ae41b87..3028155e22 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -32,8 +32,8 @@ card: 원하는 특징(_의도한 상태_)에 대한 설명을 제공해서 설정한다. -`status`는 오브젝트의 _현재 상태_ 를 기술하고, 쿠버네티스 -컴포넌트에 의해 제공되고 업데이트 된다. 쿠버네티스 +`status` 는 쿠버네티스 시스템과 컴포넌트에 의해 제공되고 +업데이트된 오브젝트의 _현재 상태_ 를 설명한다. 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 모든 오브젝트의 실제 상태를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 그리고 능동적으로 관리한다. @@ -44,8 +44,8 @@ spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 -(상태 변경에) 실패한다면, 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해 -spec과 status 간의 차이에 대응한다. +어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해 +spec과 status간의 차이에 대응한다. 오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다. @@ -53,7 +53,7 @@ spec과 status 간의 차이에 대응한다. 쿠버네티스에서 오브젝트를 생성할 때, (이름과 같은)오브젝트에 대한 기본적인 정보와 더불어, 의도한 상태를 기술한 오브젝트 spec을 제시해 줘야만 한다. 오브젝트를 생성하기 위해(직접이든 또는 `kubectl`을 통해서든) 쿠버네티스 API를 이용할 때, API 요청은 요청 내용 안에 JSON 형식으로 정보를 포함시켜 줘야만 한다. **대부분의 경우 정보를 .yaml 파일로 `kubectl`에 제공한다.** `kubectl`은 API 요청이 이루어질 때, JSON 형식으로 정보를 변환시켜 준다. -여기 쿠버네티스 디플로이먼트를 위한 요청 필드와 오브젝트 spec을 보여주는 `.yaml` 파일 예시가 있다. +여기 쿠버네티스 디플로이먼트를 위한 필수 필드와 오브젝트 spec을 보여주는 `.yaml` 파일 예시가 있다. {{< codenew file="application/deployment.yaml" >}} @@ -93,4 +93,3 @@ deployment.apps/nginx-deployment created * [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. {{% /capture %}} - diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md index e2588b33af..11356ed3ee 100644 --- a/content/ko/docs/concepts/policy/limit-range.md +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -7,7 +7,7 @@ weight: 10 {{% capture overview %}} 기본적으로 컨테이너는 쿠버네티스 클러스터에서 무제한 [컴퓨팅 리소스](/docs/user-guide/compute-resources)로 실행된다. -리소스 쿼터을 사용하면 클러스터 관리자는 네임스페이스별로 리소스 사용과 생성을 제한할 수 있다. +리소스 쿼터을 사용하면 클러스터 관리자는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}별로 리소스 사용과 생성을 제한할 수 있다. 네임스페이스 내에서 파드나 컨테이너는 네임스페이스의 리소스 쿼터에 정의된 만큼의 CPU와 메모리를 사용할 수 있다. 하나의 파드 또는 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있다. 리밋레인지는 네임스페이스에서 리소스 할당(파드 또는 컨테이너)을 제한하는 정책이다. {{% /capture %}} @@ -30,16 +30,16 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. 리밋레인지 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야한다. -### 범위 제한의 개요 +### 리밋 레인지 개요 -- 관리자는 하나의 네임스페이스에 하나의 `LimitRange`를 만든다. +- 관리자는 하나의 네임스페이스에 하나의 리밋레인지를 만든다. - 사용자는 네임스페이스에서 파드, 컨테이너 및 퍼시스턴트볼륨클레임과 같은 리소스를 생성한다. - `LimitRanger` 어드미션 컨트롤러는 컴퓨팅 리소스 요청 사항을 설정하지 않은 모든 파드와 컨테이너에 대한 기본값과 제한을 지정하고 네임스페이스의 리밋레인지에 정의된 리소스의 최소, 최대 및 비율을 초과하지 않도록 사용량을 추적한다. - 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하는 경우 HTTP 상태 코드 `403 FORBIDDEN` 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다. - `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다. - 리밋레인지 유효성 검사는 파드 실행 단계가 아닌 파드 어드미션 단계에서만 발생한다. -범위 제한을 사용하여 생성할 수 있는 정책의 예는 다음과 같다. +리밋 레인지를 사용하여 생성할 수 있는 정책의 예는 다음과 같다. - 용량이 8GiB RAM과 16 코어인 2 노드 클러스터에서 네임스페이스의 파드를 제한하여 CPU의 최대 제한이 500m인 CPU 100m를 요청하고 메모리의 최대 제한이 600M인 메모리 200Mi를 요청하라. - 스펙에 CPU 및 메모리 요청없이 시작된 컨테이너에 대해 기본 CPU 제한 및 요청을 150m로, 메모리 기본 요청을 300Mi로 정의하라. @@ -49,19 +49,20 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. 경합이나 리밋레인지 변경은 이미 생성된 리소스에 영향을 미치지 않는다. -## 예제 - -- [네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)을 본다. -- [네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)을 본다. -- [네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)을 본다. -- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)을 본다. -- [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)을 확인한다. -- [네임스페이스당 할당량을 설정하는 자세한 예시](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)를 본다. - {{% /capture %}} {{% capture whatsnext %}} -보다 자세한 내용은 [LimitRanger 설계 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)를 참고하길 바란다. +자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)를 참조한다. + +제한의 사용에 대한 예시는 다음을 참조한다. + +- [네임스페이스당 최소 및 최대 CPU 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/). +- [네임스페이스당 최소 및 최대 메모리 제약 조건을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/). +- [네임스페이스당 기본 CPU 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/). +- [네임스페이스당 기본 메모리 요청과 제한을 설정하는 방법](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). +- [네임스페이스당 최소 및 최대 스토리지 사용량을 설정하는 방법](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage). +- [네임스페이스당 할당량을 설정하는 자세한 예시](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). + {{% /capture %}} diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index d86685d986..4eeb59b510 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -193,7 +193,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. ### PriorityClass별 리소스 쿼터 -{{< feature-state for_k8s_version="1.12" state="beta" >}} +{{< feature-state for_k8s_version="v1.12" state="beta" >}} 특정 [우선 순위](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)로 파드를 생성할 수 있다. 쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을 diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md new file mode 100644 index 0000000000..d368e230d7 --- /dev/null +++ b/content/ko/docs/concepts/scheduling-eviction/_index.md @@ -0,0 +1,4 @@ +--- +title: "스케줄링과 축출(eviction)" +weight: 90 +--- diff --git a/content/ko/docs/concepts/scheduling/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md similarity index 100% rename from content/ko/docs/concepts/scheduling/kube-scheduler.md rename to content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md diff --git a/content/ko/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md similarity index 100% rename from content/ko/docs/concepts/scheduling/scheduler-perf-tuning.md rename to content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md diff --git a/content/ko/docs/concepts/scheduling/_index.md b/content/ko/docs/concepts/scheduling/_index.md deleted file mode 100644 index 0ffab2ef77..0000000000 --- a/content/ko/docs/concepts/scheduling/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "스케줄링" -weight: 90 ---- - diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index fda1f15984..6dcbe57d58 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -140,8 +140,8 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이언트와 먼저 TLS 핸드 셰이크를 수행하는 것이 이상적이다. 몇 가지 경우를 제외하고, 기본 동작은 전송 중인 모든 것을 암호화하는 것이다. 한걸음 더 나아가, VPC의 "방화벽 뒤"에서도 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. 이것을 수행하기 위해 쿠버네티스에는 [Linkerd](https://linkerd.io/) 및 [Istio](https://istio.io/)와 같은 수많은 도구가 있다. | 통신 포트 범위 제한 | 이 권장사항은 당연할 수도 있지만, 가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다. | 타사 종속성 보안 | 애플리케이션은 자체 코드베이스의 외부에 종속적인 경향이 있기 때문에, 코드의 종속성을 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. | -정적 코드 분석 | 대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다: https://www.owasp.org/index.php/Source_Code_Analysis_Tools | -동적 탐지 공격 | 일반적으로 서비스에서 발생할 수 있는 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 이런 잘 알려진 공격에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 OWASP Zed Attack 프록시다. https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project | +정적 코드 분석 | 대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다. https://owasp.org/www-community/Source_Code_Analysis_Tools | +동적 탐지 공격 | 일반적으로 서비스에서 발생할 수 있는 잘 알려진 공격 중 일부를 서비스에 테스트할 수 있는 자동화된 몇 가지 도구가 있다. 이런 잘 알려진 공격에는 SQL 인젝션, CSRF 및 XSS가 포함된다. 가장 널리 사용되는 동적 분석 도구는 OWASP Zed Attack 프록시다. https://owasp.org/www-project-zap/ | ## 강력한(robust) 자동화 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 91fbc782d7..db0abf1ede 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -164,7 +164,7 @@ DNS 정책은 파드별로 설정할 수 있다. 현재 쿠버네티스는 다 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 - [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods) + [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods) 에서 확인할 수 있다. - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 85b6742b5f..5f6fbac267 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -652,6 +652,16 @@ metadata: [...] ``` {{% /tab %}} +{{% tab name="IBM Cloud" %}} +```yaml +[...] +metadata: + name: my-service + annotations: + service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" +[...] +``` +{{% /tab %}} {{% tab name="OpenStack" %}} ```yaml [...] diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 66dd33d941..9f38f9f46c 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -296,12 +296,13 @@ parameters: `replication-type` 이 `regional-pd` 로 설정되면, [지역 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) -가 프로비전된다. 이 경우, 사용자는 `zone` 대신 `zones` 를 사용해서 원하는 -복제 영역을 지정해야 한다. 정확히 두 개의 영역이 지정된 경우, 해당 -영역에서 지역 PD가 프로비전된다. 둘 이상의 영역이 지정되면 -쿠버네티스는 지정된 영역 중에서 임의로 선택한다. `zones` 파라미터가 생략되면, -쿠버네티스는 클러스터가 관리하는 영역 중에서 -임의로 선택한다. +가 프로비전된다. 이는 퍼시스턴트볼륨클레임과 스토리지클래스를 소모하는 파드를 +생성할 때 지역 퍼시스턴트 디스크는 두개의 영역으로 +프로비전되기에 `volumeBindingMode: WaitForFirstConsumer` 를 +설정하는 것을 강력히 권장한다. 하나의 영역은 파드가 스케줄된 +영역과 동일하다. 다른 영역은 클러스터에서 사용할 수 +있는 영역에서 임의로 선택된다. 디스크 영역은 `allowedTopologies` 를 +사용하면 더 제한할 수 있다. {{< note >}} `zone` 과 `zones` 파라미터는 사용 중단 되었으며, diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index 534f3cf88b..60ad22c7cc 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -6,7 +6,7 @@ weight: 20 {{% capture overview %}} -{{< feature-state for_k8s_version="1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.17" state="beta" >}} 쿠버네티스에서 스토리지 시스템 볼륨 스냅샷은 _VolumeSnapshot_ 을 나타낸다. 이 문서는 이미 쿠버네티스 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)에 대해 잘 알고 있다고 가정한다. {{% /capture %}} @@ -55,7 +55,9 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 ### 스냅샷 소스 보호로서의 퍼시스턴트 볼륨 클레임 -이 보호의 목적은 스냅샷이 생성되는 동안 사용 중인 퍼시스턴트볼륨클레임 API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에). +이 보호의 목적은 스냅샷이 생성되는 동안 사용 중인 +{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}} +API 오브젝트가 시스템에서 지워지지 않게 하는 것이다(데이터 손실이 발생할 수 있기 때문에). 퍼시스턴트볼륨클레임이 스냅샷을 생성할 동안에는 해당 퍼시스턴트볼륨클레임은 사용중인 상태이다. 스냅샷 소스로 사용 중인 퍼시스턴트볼륨클레임 API 객체를 삭제한다면, 퍼시스턴트볼륨클레임 객체는 즉시 삭제되지 않는다. 대신, 퍼시스턴트볼륨클레임 객체 삭제는 스냅샷이 준비(readyTouse) 혹은 중단(aborted) 상태가 될 때까지 연기된다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 0ad7755031..035b7bade7 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -9,7 +9,7 @@ weight: 10 컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 첫째, 컨테이너가 충돌되면, kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상태로 -시작되기 때문에 기존 파일이 유실된다. 둘째, `파드` 에서 컨테이너를 함께 실행할 때 +시작되기 때문에 기존 파일이 유실된다. 둘째, `파드` 에서 컨테이너를 함께 실행할 때 컨테이너 사이에 파일을 공유해야 하는 경우가 자주 발생한다. 쿠버네티스의 `볼륨` 추상화는 이 두 가지 문제를 모두 해결한다. @@ -22,7 +22,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 ## 배경 -도커는 다소 느슨하고, 덜 관리되지만 +도커는 다소 느슨하고, 덜 관리되지만 [볼륨](https://docs.docker.com/engine/admin/volumes/)이라는 개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는 다른 컨테이너에 있는 디렉터리다. 수명은 관리되지 않으며 최근까지는 @@ -70,7 +70,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 * [csi](#csi) * [downwardAPI](#downwardapi) * [emptyDir](#emptydir) - * [fc (파이버 채널))](#fc) + * [fc (파이버 채널)](#fc) * [flexVolume](#flexVolume) * [flocker](#flocker) * [gcePersistentDisk](#gcepersistentdisk) @@ -496,7 +496,7 @@ gitRepo 볼륨 유형은 사용 중단(deprecated)되었다. git repo가 있는 `gitRepo` 볼륨은 볼륨 플러그인으로 할 수 있는 예시이다. 빈 디렉터리를 마운트하고 파드가 사용할 수 있도록 해당 디렉터리에 git 리포지트리를 -복제한다. 미래에는 모든 이용 사례에 대해 쿠버네티스 API를 확장하는 대신에 +복제한다. 미래에는 모든 이용 사례에 대해 쿠버네티스 API를 확장하는 대신에 이런 볼륨은 훨씬 더 분리된 모델로 이동될 수 있다. 여기 gitRepo 볼륨의 예시가 있다. @@ -1031,7 +1031,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토 ### storageOS {#storageos} -`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com) +`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com) 볼륨을 파드에 마운트할 수 있다. StorageOS 는 쿠버네티스 환경에서 컨테이너로 실행되므로 diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index b72607d41a..b06881c53f 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -8,13 +8,17 @@ weight: 80 {{< feature-state for_k8s_version="v1.8" state="beta" >}} -_크론 잡은_ 시간 기반의 일정에 따라 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 만든다. +_크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="잡" >}}을 만든다. 하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. {{< caution >}} -모든 **크론잡** `일정:` 시간은 UTC로 표시된다. +모든 **크론잡** `일정:` 시간은 +{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다. + +컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를 실행하는 경우, +kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트롤러가 사용하는 시간대로 결정한다. {{< /caution >}} 크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이 @@ -23,14 +27,26 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/ko/docs/concepts/worklo 11자를 자동으로 추가하고, 작업 이름의 최대 길이는 63자라는 제약 조건이 있기 때문이다. -크론 잡을 생성하고 작동하는 방법은 크론 잡의 스펙 파일을 확안한다. 내용은 [크론 잡으로 자동 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs)를 참조한다. {{% /capture %}} - - {{% capture body %}} -## 크론 잡의 한계 +## 크론잡 + +크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인 +작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을 +스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다. + +### 예제 + +이 크론잡 매니페스트 예제는 현재 시간과 hello 메시지를 1분마다 출력한다. + +{{< codenew file="application/job/cronjob.yaml" >}} + +([크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)는 +이 예시를 더 자세히 설명한다.) + +## 크론 잡의 한계 {#cron-job-limitations} 크론 잡은 일정의 실행시간 마다 _약_ 한 번의 잡을 생성한다. "약" 이라고 하는 이유는 특정 환경에서는 두 개의 잡이 만들어지거나, 잡이 생성되지 않기도 하기 때문이다. 보통 이렇게 하지 @@ -62,3 +78,11 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). 잡은 그 잡이 대표하는 파드 관리에 책임이 있다. {{% /capture %}} +{{% capture whatsnext %}} +[크론 표현 포맷](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)은 +크론잡 `schedule` 필드의 포맷을 문서화 한다. + +크론 잡 생성과 작업에 대한 지침과 크론잡 매니페스트의 +예는 [크론 잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 5afb68b9bc..268175c200 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -46,24 +46,24 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 이 예시에 대한 설명은 다음과 같다. * `.metadata.name` 필드에 따라 `nginx-deployment` 이름으로 디플로이먼트가 생성된다. -* `replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다. -* `selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다. +* `.spec.replicas` 필드에 따라 디플로이먼트는 3개의 레플리카 파드를 생성한다. +* `.spec.selector` 필드는 디플로이먼트가 관리할 파드를 찾는 방법을 정의한다. 이 사례에서는 간단하게 파드 템플릿에 정의된 레이블(`app: nginx`)을 선택한다. 그러나 파드 템플릿 자체의 규칙이 만족되는 한, 보다 정교한 선택 규칙의 적용이 가능하다. {{< note >}} - `matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 + `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며 값 배열은 "value"만 포함한다. 매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다. {{< /note >}} * `template` 필드에는 다음 하위 필드가 포함되어있다. - * 파드는 `labels` 필드를 사용해서 `app: nginx` 이라는 레이블을 붙인다. + * 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다. * 파드 템플릿의 사양 또는 `.template.spec` 필드는 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는 `nginx` 컨테이너 1개를 실행하는 것을 나타낸다. - * 컨테이너 1개를 생성하고, `name` 필드를 사용해서 `nginx` 이름을 붙인다. + * 컨테이너 1개를 생성하고, `.spec.template.spec.containers[0].name` 필드를 사용해서 `nginx` 이름을 붙인다. 위의 디플로이먼트를 생성하려면 다음 단계를 따른다. @@ -87,9 +87,8 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 ``` 클러스터에서 디플로이먼트를 점검할 때 다음 필드가 표시된다. - * `NAME` 은 클러스터에 있는 디플로이먼트 이름의 목록이다. - * `DESIRED` 는 디플로이먼트의 생성시 정의된 의도한 애플리케이션 _레플리카_ 의 수를 표시한다. 이것이 _의도한 상태_ 이다. - * `CURRENT` 는 현재 실행 중인 레플리카의 수를 표시한다. + * `NAME` 은 네임스페이스에 있는 디플로이먼트 이름의 목록이다. + * `READY` 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다. ready/desired 패턴을 따른다. * `UP-TO-DATE` 는 의도한 상태를 얻기위해 업데이트 된 레플리카의 수를 표시한다. * `AVAILABLE` 은 사용자가 사용 가능한 애플리케이션 레플리카의 수를 표시한다. * `AGE` 는 애플리케이션의 실행 된 시간을 표시한다. @@ -114,8 +113,16 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 NAME DESIRED CURRENT READY AGE nginx-deployment-75675f5897 3 3 3 18s ``` + 레플리카셋의 출력에는 다음 필드가 표시된다. + + * `NAME` 은 네임스페이스에 있는 레플리카셋 이름의 목록이다. + * `DESIRED` 는 디플로이먼트의 생성 시 정의된 의도한 애플리케이션 _레플리카_ 의 수를 표시한다. 이것이 _의도한 상태_ 이다. + * `CURRENT` 는 현재 실행 중인 레플리카의 수를 표시한다. + * `READY` 는 사용자가 사용할 수 있는 애플리케이션의 레플리카의 수를 표시한다. + * `AGE` 는 애플리케이션의 실행된 시간을 표시한다. + 레플리카셋의 이름은 항상 `[DEPLOYMENT-NAME]-[RANDOM-STRING]` 형식으로 된 것을 알 수 있다. 무작위 문자열은 - 무작위로 생성되며, Pod-template-hash를 시드(seed)로 사용한다. + 무작위로 생성되며, `pod-template-hash` 를 시드(seed)로 사용한다. 6. 각 파드에 자동으로 생성된 레이블을 보려면 `kubectl get pods --show-labels` 를 실행한다. 다음과 유사하게 출력된다. ```shell @@ -508,7 +515,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 이와 유사하게 출력된다. ``` - deployment.apps/nginx-deployment + deployment.apps/nginx-deployment rolled back ``` Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`: @@ -518,7 +525,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 이와 유사하게 출력된다. ``` - deployment.apps/nginx-deployment + deployment.apps/nginx-deployment rolled back ``` 롤아웃 관련 명령에 대한 자세한 내용은 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)을 참조한다. @@ -1015,7 +1022,7 @@ $ echo $? ## 디플로이먼트 사양 작성 -다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. +다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다. 설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), 컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다. 디플로이먼트 오브젝트의 이름은 유효한 diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index e373984219..e83c02b50d 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -147,7 +147,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 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 >}} -클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/#how-it-works)가 +클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/)가 아니라면 `cluster.local`로 설정된다. {{< /note >}} diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 42f86781c5..e29e358d97 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -181,7 +181,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 ... State: Waiting Reason: ErrImagePull - ... + ... ``` * `Running`: 컨테이너가 이슈 없이 구동된다는 뜻이다. `postStart` 훅(있는 경우)은 컨테이너가 Running 상태가 되기 전에 실행된다. 이 상태는 컨테이너가 언제 Running 상태에 돌입한 시간도 함께 출력된다. @@ -206,31 +206,34 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 ... ``` -## 파드의 준비성 게이트(readiness gate) +## 파드의 준비성(readiness) {#pod-readiness-gate} {{< feature-state for_k8s_version="v1.14" state="stable" >}} -파드의 준비성에 대한 확장성을 추가하기 위해서 -추가적인 피드백이나 신호를 `PodStatus`에 주입하는 방법인, -[파드 준비++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md)라는 특징이 쿠버네티스 1.11에서 소개되었다. -파드의 준비성을 평가하기 위한 추가적인 조건들을 `PodSpec` 내의 새로운 `ReadinessGate` 필드를 -통해서 지정할 수 있다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 +애플리케이션은 추가 피드백 또는 신호를 PodStatus: _Pod readiness_ +와 같이 주입할 수 있다. 이를 사용하기 위해, 파드의 준비성을 평가하기 +위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다. + +준비성 게이트는 파드에 대한 `status.condition` 필드의 현재 +상태에 따라 결정된다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 조건을 찾지 못한다면, 그 조건의 상태는 기본 값인 "`False`"가 된다. 아래는 한 예제를 보여준다. +여기 예제가 있다. + ```yaml -Kind: Pod +kind: Pod ... spec: readinessGates: - conditionType: "www.example.com/feature-1" status: conditions: - - type: Ready # 이것은 내장된 PodCondition이다 + - type: Ready # 내장된 PodCondition이다 status: "False" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:00Z - - type: "www.example.com/feature-1" # 추가적인 PodCondition + - type: "www.example.com/feature-1" # 추가적인 PodCondition status: "False" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:00Z @@ -240,19 +243,23 @@ status: ... ``` -파드의 새로운 조건들은 -쿠버네티스의 [레이블 키 포멧](/ko/docs/concepts/overview/working-with-objects/labels/#구문과-캐릭터-셋)을 준수해야 한다. -`kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에, -새로운 파드 조건들은 [KubeClient 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 통한 `PATCH` 액션을 통해서 주입되어야 한다. +추가하는 파드 상태에는 쿠버네티스 [레이블 키 포맷](/ko/docs/concepts/overview/working-with-objects/labels/#구문과-캐릭터-셋)을 충족하는 이름이 있어야 한다. -새로운 파드 조건들이 적용된 경우, 파드는 **오직** -다음 두 문장이 모두 참일 때만 준비 상태로 평가된다. + +### 파드 준비성 상태 {#pod-readiness-status} + +`kubectl patch` 명령어는 아직 오브젝트 상태 패치(patching)를 지원하지 않는다. +이러한 `status.conditions` 을 파드에 설정하려면 애플리케이션과 +{{< glossary_tooltip term_id="operator-pattern" text="오퍼레이터">}}의 +`PATCH` 액션을 필요로 한다. +[쿠버네티스 클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 +사용해서 파드 준비성에 대한 사용자 지정 파드 조건을 설정하는 코드를 작성할 수 있다. + +사용자 지정 조건을 사용하는 파드의 경우, 다음 두 조건이 모두 적용되는 +경우에 **만** 해당 파드가 준비된 것으로 평가된다. * 파드 내의 모든 컨테이너들이 준비 상태이다. -* `ReadinessGates`에 지정된 모든 조건들이 "`True`"이다. - -파드 준비성 평가에 대한 변경을 촉진하기 위해서, -이전 파드 조건인 `Ready`를 포착하기 위한 새로운 파드 조건 `ContainersReady`가 소개되었다. +* `ReadinessGates`에 지정된 모든 조건들이 `True` 이다. ## 재시작 정책 @@ -269,32 +276,31 @@ kubelet에 의해서 재시작되는 종료된 컨테이너는 ## 파드의 일생(lifetime) -일반적으로, 파드는 사람 혹은 컨트롤러의 프로세스가 명시적으로 파드를 삭제할 때까지 남아 있다. +일반적으로, 파드는 사람 혹은 +{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}의 +프로세스가 명시적으로 파드를 삭제할 때까지 남아 있다. 컨트롤 플레인은 파드의 수가 설정된 임계치(kube-controller-manager에서 `terminated-pod-gc-threshold`에 의해 결정)를 초과할 때, 종료된 파드들(`Succeeded` 또는 `Failed` 단계)을 정리한다. 이로써 시간이 지남에 따라 파드들이 생성 및 종료되며 발생하는 리소스 누수를 피할 수 있다. -세 가지 유형의 컨트롤러를 사용할 수 있다. +파드에는 다음과 같은 다양한 종류의 리소스가 있다. -- 배치 연산과 같이, 종료가 예상되는 파드를 위해서는 [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 +- 예를 들어 웹 서버와 같이 종료되지 않을 것으로 예상되는 파드용 + {{< glossary_tooltip term_id="deployment" >}}, {{< glossary_tooltip term_id="replica-set" >}} 또는 + {{< glossary_tooltip term_id="statefulset" >}}을 사용한다. + +- 배치 연산과 같이, 종료가 예상되는 파드를 위해서는 + {{< glossary_tooltip term_id="job" >}}을 사용하길 바란다. 잡은 `restartPolicy`가 실패 시(OnFailure) 또는 절대 안 함(Never)으로 지정된 경우에 적합하다. -- 웹 서버와 같이, 종료가 예상되지 않는 파드에 대해서는 - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/), - [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/), 또는 - [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다. - 레플리케이션 컨트롤러는 `restartPolicy`가 항상(Always)으로 지정된 - 경우에만 적합하다. +- 적합한 노드 당 하나씩 실행해야 하는 파드에는 + {{< glossary_tooltip term_id="daemonset" >}}을 사용한다. -- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)을 사용하길 - 바란다. 왜냐하면 데몬 셋은 특정 머신 전용 시스템 서비스(machine-specific system service)를 제공하기 때문이다. - -세 가지 모든 컨트롤러 유형은 PodTemplate을 가지고 있다. 파드를 -직접적으로 생성하는 것 보다는, 적절한 컨트롤러를 생성하고 컨트롤러가 파드를 -생성하도록 하는 것이 추천된다. 그 이유는 파드 -혼자서는 머신의 실패에 탄력적(resilient)이지 않지만, 컨트롤러는 탄력적이기 때문이다. +모든 워크로드 리소스에는 파드명세가 포함된다. 사용자가 직접적으로 파드를 생성하는 +것보다 적절한 워크로드 리소스를 생성하고 리소스 컨트롤러가 +사용자를 위한 파드를 생성하도록 하는 것을 권장한다. 만약 노드가 죽거나 다른 클러스터의 다른 노드들로부터 연결이 끊기면, 쿠버네티스는 잃어버린 노드에 있는 모든 파드의 `phase`를 실패된(Failed)으로 설정하는 정책을 적용한다. @@ -398,4 +404,3 @@ spec: {{% /capture %}} - diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 1902594c33..e1239a817e 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -15,9 +15,9 @@ card: {{% capture body %}} ## 파드에 대해 이해하기 -*파드* 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" >}} 에서의 Running 프로세스를 나타낸다. +*파드* 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" text="클러스터" >}} 에서의 Running 프로세스를 나타낸다. -파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함. +파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 정체성(IP 주소) 및 컨테이너가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 {{< glossary_tooltip text="컨테이너" term_id="container" >}}로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미한다. [도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/) 역시 지원한다. @@ -26,12 +26,9 @@ card: * **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다. * **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다. -[쿠버네티스 블로그](https://kubernetes.io/blog)에는 파드 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참조하길 바란다. - - * [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) - * [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns) - -각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다. +각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(더 많은 인스턴스를 실행해서 더 많은 전체 리소스를 제공하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. +복제된 파드는 일반적으로 워크로드 리소스와 해당 {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해 그룹으로 생성과 관리된다. +쿠버네티스가 컨트롤러를 사용해서 워크로드의 확장과 복구를 구현하는 방법에 대한 자세한 내용은 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다. ## 어떻게 파드가 다중 컨테이너를 관리하는가 @@ -47,7 +44,7 @@ card: #### 네트워킹 -각각의 파드는 유일한 IP주소를 할당 받는다. 한 파드 내부의 모든 컨테이너는 네트워크 네임스페이스와 IP주소 및 네트워크 포트를 공유한다. *파드 안에 있는* 컨테이너는 다른 컨테이너와 `localhost`를 통해서 통신할 수 있다. 특정 파드 안에 있는 컨테이너가 *파드 밖의* 요소들과 통신하기 위해서는, 네트워크 리소스를 어떻게 쓰고 있는지 공유 해야 한다(예를 들어 포트 등). +각각의 파드는 각 주소 패밀리의 고유한 IP 주소를 할당 받는다. 한 파드 내부의 모든 컨테이너는 네트워크 네임스페이스와 IP주소 및 네트워크 포트를 공유한다. *파드 안에 있는* 컨테이너는 다른 컨테이너와 `localhost` 를 통해서 통신할 수 있다. 특정 파드 안에 있는 컨테이너가 *파드 밖의* 요소들과 통신하기 위해서는, 네트워크 리소스를 어떻게 쓰고 있는지 공유해야 한다(예를 들어 포트 등). #### 저장소 @@ -55,54 +52,63 @@ card: ## 파드 작업 -직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}} 에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다. +직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들 일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}}에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 오브젝트가 삭제되거나, 파드가 리소스의 부족으로 인해 *축출되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있다. {{< note >}} -파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다. +파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 프로세스가 아니라, 컨테이너를 실행하는 환경이다. 파드는 삭제될 때까지 유지된다. {{< /note >}} -파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#파드와-컨트롤러)를 참고하길 바란다. +파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 축출되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용할 수 있지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서는 훨씬 더 보편적이다. ### 파드와 컨트롤러 -컨트롤러는 다중 파드를 생성하고 관리해 주는데, 클러스터 범위 내에서의 레플리케이션 핸들링, 롤아웃 그리고 셀프힐링 기능 제공을 한다. 예를 들어, 만약 노드가 고장났을 때, 컨트롤러는 다른 노드에 파드를 스케줄링 함으로써 자동으로 교체할 것이다. +워크로드 리소스를 사용해서 여러 파드를 생성하고 관리할 수 있다. 리소스 컨트롤러는 파드 장애 발생 시 복제, 롤아웃, 자동 복구를 처리한다. 예를 들어, 노드에 장애가 발생하면, 컨트롤러는 해당 노드의 파드는 작동을 멈추고 교체용 파드를 생성한다는 것을 알게 된다. 스케줄러는 교체용 파드를 정상적인 노드에 배치하게 된다. -한 가지 또는 그 이상의 파드를 보유한 컨트롤러의 몇 가지 예시. - -* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) -* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/) -* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/) - -일반적으로, 컨트롤러는 책임을 지고 제공한 파드 템플릿을 사용한다. +* {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} +* {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} +* {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}} ## 파드 템플릿 -파드 템플릿은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/), -[잡](/docs/concepts/jobs/run-to-completion-finite-workloads/), -[데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다. -컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다. -아래 예시는 메시지를 출력하는 컨테이너를 포함하는 파드에 대한 간단한 매니페스트이다. +워크로드 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고 +사용자를 대신해서 이러한 파드를 관리한다. + +파드템플릿은 파드를 생성하기 위한 명세이며 +[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/), +[잡](/ko/docs/concepts/jobs/run-to-completion-finite-workloads/) 그리고 +[데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/)과 같은 워크로드 리소스에 포함되어 있다. + +워크로드 리소스의 각 컨트롤러는 워크로드 오브젝트 내부의 파드템플릿을 사용해서 실제 파드를 만든다. 파드템플릿은 앱을 실행하는 데 사용되는 모든 워크로드 리소스의 의도하는 상태의 일부이다. + +아래 샘플은 하나의 컨테이너를 시작하는 `template` 이 있는 간단한 잡에 대한 매니페스트이다. 파드의 컨테이너가 메시지를 출력한 후 일시 중지하게 된다. ```yaml -apiVersion: v1 -kind: Pod +apiVersion: batch/v1 +kind: Job metadata: - name: myapp-pod - labels: - app: myapp -spec: - containers: - - name: myapp-container - image: busybox - command: ['sh', '-c', 'echo 안녕하세요 쿠버네티스! && sleep 3600'] + name: hello + template: + # 이것이 파드 템플릿이다. + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # 여기가 파드 템플릿의 끝이다. ``` -모든 레플리카의 현재 원하는 상태를 지정하는 대신, 파드 템플릿은 쿠키 틀과 같다. 쿠키가 한 번 잘리면, 그 쿠키는 쿠키 틀과 더이상 관련이 없다. 양자 얽힘이 없는 것이다. 그 이후 템플릿을 변경하거나 새로운 템플릿으로 바꿔도 이미 만들어진 파드에는 직접적인 영향이 없다. 마찬가지로, 레플리케이션 컨트롤러에 의해 만들어진 파드는 아마 그 이후 직접 업데이트될 수 있다. 이것은 모든 컨테이너가 속해있는 파드에서 현재 원하는 상태를 명시하는 것과 의도적으로 대비가 된다. 이러한 접근은 시스템의 의미를 철저히 단순화하고 유연성을 증가시킨다. +파드 템플릿을 수정하거나 새 파드 템플릿으로 전환해도 이미 존재하는 파드에는 영향을 미치지 않는다. 파드는 템플릿 업데이트를 직접 수신하지 않지만, 대신에 수정된 파드 템플릿과 일치하는 새 파드가 생성된다. + +예를 들어, 디플로이먼트 컨트롤러는 실행 중인 파드가 현재 파드 템플릿과 일치하는지 확인한다. 템플릿이 업데이트되면, 컨트롤러는 업데이트된 템플릿을 기반으로 기존 파드를 제거하고 새 파드를 생성한다. 각 워크로드 컨트롤러는 파드 템플릿의 변경사항을 처리하기 위해 자체 규칙을 구현한다. + +노드에서 "kubelet"이 파드 템플릿과 업데이트에 관련된 세부 정보를 직접 관찰하거나 관리하지 않으며, 이러한 세부 정보는 추상화되지 않는다. 이러한 추상화와 분리는 시스템 시맨틱을 단순화하며, 기존 코드를 변경하지 않고 클러스터의 동작을 확장할 수 있도록 한다. {{% /capture %}} {{% capture whatsnext %}} * [파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자. +* [분산 시스템 툴킷: 복합 컨테이너의 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)은 둘 이상의 컨테이너가 있는 파드의 공통 레이아웃에 대해 설명한다. * 파드의 동작에 대해 더 알아보자. * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료) * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 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 7bde7139a9..4bb95789d3 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 @@ -62,10 +62,10 @@ metadata: name: mypod spec: topologySpreadConstraints: - - maxSkew: - topologyKey: - whenUnsatisfiable: - labelSelector: + - maxSkew: + topologyKey: + whenUnsatisfiable: + labelSelector: ``` 사용자는 하나 또는 다중 `topologySpreadConstraint` 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다. @@ -73,8 +73,8 @@ spec: - **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다. 이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는 파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야 한다. - **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다. - **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다. - - `DoNotSchedule` (기본값)은 스케줄러에 스케줄을 하지 말라고 알려준다. - - `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선순위를 부여하면서, 스케줄을 계속하도록 지시한다. + - `DoNotSchedule` (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다. + - `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다. - **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다. 사용자는 `kubectl explain Pod.spec.topologySpreadConstraints` 를 실행해서 이 필드에 대한 자세한 내용을 알 수 있다. @@ -160,8 +160,8 @@ spec: - 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다. - `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다. - 1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone"레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다. - 2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다. + 1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다. + 2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다. - 들어오는 파드의 `topologySpreadConstraints[*].labelSelector` 와 자체 레이블과 일치하지 않을 경우 어떻게 되는지 알고 있어야 한다. 위의 예시에서, 만약 들어오는 파드의 레이블을 제거하더라도 여전히 제약 조건이 충족하기 때문에 "zoneB"에 배치할 수 있다. 그러나, 배치 이후에도 클러스터의 불균형 정도는 변경되지 않는다. - 여전히 zoneA는 {foo:bar} 레이블을 가지고 있는 2개의 파드를 가지고 있고, zoneB 도 {foo:bar}를 레이블로 가지는 파드 1개를 가지고 있다. 따라서 만약 예상과 다르면, 워크로드의 `topologySpreadConstraints[*].labelSelector` 가 자체 레이블과 일치하도록 하는 것을 권장한다. @@ -207,12 +207,12 @@ kind: KubeSchedulerConfiguration profiles: pluginConfig: - - name: PodTopologySpread - args: - defaultConstraints: - - maxSkew: 1 - topologyKey: failure-domain.beta.kubernetes.io/zone - whenUnsatisfiable: ScheduleAnyway + - name: PodTopologySpread + args: + defaultConstraints: + - maxSkew: 1 + topologyKey: failure-domain.beta.kubernetes.io/zone + whenUnsatisfiable: ScheduleAnyway ``` {{< note >}} @@ -229,14 +229,14 @@ profiles: 더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다. - `PodAffinity` 는, 사용자가 자격이 충족되는 토폴로지 도메인에 -원하는 수의 파드를 얼마든지 채울 수 있다. + 원하는 수의 파드를 얼마든지 채울 수 있다. - `PodAntiAffinity` 로는, 단일 토폴로지 도메인에 -단 하나의 파드만 스케줄 될 수 있다. + 단 하나의 파드만 스케줄 될 수 있다. "EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서 고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다. -더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-even-pods-spreading.md#motivation)를 참조한다. +더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)를 참조한다. ## 알려진 제한사항 diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 18958c7531..f059747769 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -35,7 +35,7 @@ card: 1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다. 2. [문서 리포지터리](https://github.com/kubernetes/website) 와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지합니다. -3. [풀 리퀘스트 열기](/docs/contribute/new-content/open-a-pr/)와 [변경 검토](/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다. +3. [풀 리퀘스트 열기](/docs/contribute/new-content/new-content/)와 [변경 검토](/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다. 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다. 역할과 권한에 대한 자세한 내용은 @@ -44,6 +44,7 @@ card: ## 첫 번째 기여 - [기여 개요](/docs/contribute/new-content/overview/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. +- [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. - 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/docs/contribute/new-content/new-content/#changes-using-github) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. - 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/docs/contribute/review/reviewing-prs/)를 합니다. - 쿠버네티스 [컨텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index 2ff7e51cdb..9b56a46dfa 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -166,11 +166,13 @@ boilerplate | 상용구 | Boot | 부트 | Build | 빌드 | Cache | 캐시 | +Calico | 캘리코(Calico) | canary | 카나리(canary) | 릴리스 방식에 관련한 용어인 경우에 한함 cascading | 캐스케이딩(cascading) | character set | 캐릭터 셋 | Charts | 차트 | checkpoint | 체크포인트 | +Cilium | 실리움(Cilium) | CLI | CLI | Cluster | 클러스터 | Command Line Tool | 커맨드라인 툴 | @@ -200,19 +202,22 @@ disruption | 중단(disruption) | distros | 배포판 | Docker | 도커 | Dockerfile | Dockerfile | +Docker Swarm | Docker Swarm | Downward API | 다운워드(Downward) API | draining | 드레이닝(draining) | egress | 이그레스, 송신(egress) | Endpoint | 엔드포인트 | entry point | 진입점 | Event | 이벤트 | +evict | 축출하다 | +eviction | 축출 | Exec | Exec | expose | 노출시키다 | extension | 익스텐션(extension) | Failed | Failed | 파드의 상태에 한함 Federation | 페더레이션 | field | 필드 | -Flannel | Flannel | +Flannel | 플란넬(Flannel) | form | 형식 | Google Compute Engine | Google Compute Engine | hash | 해시 | @@ -239,6 +244,7 @@ Job | 잡 | kube-proxy | kube-proxy | Kubelet | Kubelet | Kubernetes | 쿠버네티스 | +Kube-router | Kube-router | label | 레이블 | lifecycle | 라이프사이클 | Linux | 리눅스 | @@ -273,7 +279,7 @@ Persistent Volume | 퍼시스턴트 볼륨 | Persistent Volume Claim | 퍼시스턴트 볼륨 클레임 | pipeline | 파이프라인 | placeholder pod | 플레이스홀더(placeholder) 파드 | -Pod(파드) | 파드 | +Pod | 파드 | Pod Preset | 파드 프리셋 | PodAntiAffinity | 파드안티어피니티(PodAntiAffinity) | PodDisruptionBudget | PodDisruptionBudget | @@ -307,6 +313,7 @@ Role | 롤 | rollback | 롤백 | rolling update | 롤링 업데이트 | rollout | 롤아웃 | +Romana | 로마나(Romana) | Running | Running | 파드의 상태에 한함 runtime | 런타임 | Scale | 스케일 | @@ -325,6 +332,7 @@ Shell | 셸 | Sign In | 로그인 | Sign Out | 로그아웃 | skew | 차이(skew) | +snippet | 스니펫(snippet) | spec | 명세, 스펙, 사양 | specification | 명세 | Stateful Set | 스테이트풀 셋 | @@ -352,6 +360,7 @@ virtualization | 가상화 | Volume | 볼륨 | Waiting | Waiting | 파드의 상태에 한함 Walkthrough | 연습 | +Weave-net | 위브넷(Weave Net) | Weaveworks 사의 솔루션 공식 명칭은 'Weave Net'이므로 한영병기 시 공식 명칭 사용 Windows | 윈도우 | Worker | 워커 | 노드의 형태에 한함 Workload | 워크로드 | diff --git a/content/ko/docs/contribute/new-content/_index.md b/content/ko/docs/contribute/new-content/_index.md new file mode 100644 index 0000000000..2a97dcca2c --- /dev/null +++ b/content/ko/docs/contribute/new-content/_index.md @@ -0,0 +1,4 @@ +--- +title: 새로운 콘텐츠 기여하기 +weight: 20 +--- diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md new file mode 100644 index 0000000000..17ea3342c1 --- /dev/null +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -0,0 +1,484 @@ +--- +title: 풀 리퀘스트 열기 +slug: new-content +content_template: templates/concept +weight: 10 +card: + name: contribute + weight: 40 +--- + +{{% capture overview %}} + +{{< note >}} +**코드 개발자**: 향후 쿠버네티스 릴리스의 +새로운 기능을 문서화하는 경우, +[새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다. +{{< /note >}} + +새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/overview/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다. + +변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자. + +변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 컴퓨터에서 로컬로 변경하는 방법을 배운다. + +{{% /capture %}} + +{{% capture body %}} + +## GitHub을 사용하여 변경하기 + +git 워크플로에 익숙하지 않은 경우, 풀 리퀘스트를 +여는 쉬운 방법이 있다. + +1. 이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다. + 페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다. + +2. GitHub 마크다운 편집기에서 수정한다. + +3. 편집기 아래에서, **Propose file change** 양식을 + 작성한다. 첫 번째 필드에서, 커밋 메시지 제목을 지정한다. + 두 번째 필드에는, 설명을 제공한다. + + {{< note >}} + 커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 않는다. 나중에 풀 리퀘스트 설명에 + 추가할 수 있다. + {{< /note >}} + +4. **Propose file change** 를 선택한다. + +5. **Create pull requests** 를 선택한다. + +6. **Open a pull request** 화면이 나타난다. 양식을 작성한다. + + - 풀 리퀘스트의 **Subject** 필드는 기본적으로 커밋의 요약으로 설정한다. + 필요한 경우 변경할 수 있다. + - **Body** 는 만약 내용이 있다면, 확장된 커밋 메시지를 포함한다. + 그리고 일부 템플릿 텍스트를 포함한다. + 템플릿 텍스트에 필요한 세부 정보를 추가한 다음, 추가 템플릿 텍스트를 삭제한다. + - **Allow edits from maintainers** 체크박스는 선택된 상태로 둔다. + + {{< note >}} + PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다. 자세한 내용은 [PR 열기](#open-a-pr)를 참고한다. + {{}} + +7. **Create pull request** 를 선택한다. + +### GitHub에서 피드백 해결 + +풀 리퀘스트를 병합하기 전에, 쿠버네티스 커뮤니티 회원은 이를 리뷰하고 +승인한다. `k8s-ci-robot` 은 이 페이지에 나와있는 가까운 +멤버에게 리뷰를 제안한다. 특정한 사람을 염두에 두고 있다면, +GitHub 사용자 이름을 코멘트로 남긴다. + +리뷰어가 변경을 요청하는 경우, 다음과 같이 한다. + +1. **Files changed** 탭으로 이동 한다. +2. 풀 리퀘스트에 의해 변경된 파일에서 연필(편집) 아이콘을 +선택한다. +3. 요청된 변경에 대한 수정을 한다. +4. 변경 사항을 커밋한다. + +리뷰어를 기다리고 있는 경우, 7일마다 한 번씩 연락한다. 슬랙 채널 `#sig-docs` 에 메시지를 게시할 수도 있다. + +리뷰가 완료되면, 리뷰어가 PR을 병합하고 몇 분 후에 변경 사항이 적용된다. + +## 로컬 포크에서 작업하기 {#fork-the-repo} + +git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, +로컬 포크로 작업한다. + +컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다. + +### kubernetes/website 리포지터리 포크하기 + +1. [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다. +2. **Fork** 를 선택한다. + +### 로컬 클론 생성 및 업스트림 설정 + +3. 터미널 창에서, 포크를 클론한다. + + ```bash + git clone git@github.com//website + ``` + +4. 새 `website` 디렉터리로 이동한다. `kubernetes/website` 리포지터리를 `upstream` 원격으로 설정한다. + + ```bash + cd website + + git remote add upstream https://github.com/kubernetes/website.git + ``` + +5. `origin` 과 `upstream` 리포지터리를 확인한다. + + ```bash + git remote -v + ``` + + 출력은 다음과 비슷하다. + + ```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) + ``` + +6. 포크의 `origin/master` 와 `kubernetes/website` 의 `upstream/master` 에서 커밋을 가져온다. + + ```bash + git fetch origin + git fetch upstream + ``` + + 이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다. + + {{< note >}} + 이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `master` 복사본을 `upstream/master` 와 병합할 필요가 없다. + {{< /note >}} + +### 브랜치 만들기 + +1. 작업할 브랜치 기반을 결정한다. + + - 기존 콘텐츠를 개선하려면, `upstream/master` 를 사용한다. + - 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/master` 를 사용한다. + - 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다. + - 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다. + - 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는, + 해당 작업을 위해 작성된 특정 기능 브랜치를 + 사용한다. + + 브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다. + +2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/master` 라고 가정한다. + + ```bash + git checkout -b upstream/master + ``` + +3. 텍스트 편집기를 사용하여 변경한다. + +언제든지, `git status` 명령을 사용하여 변경한 파일을 본다. + +### 변경 사항 커밋 + +풀 리퀘스트를 제출할 준비가 되면, 변경 사항을 커밋한다. + +1. 로컬 리포지터리에서 커밋해야 할 파일을 확인한다. + + ```bash + git status + ``` + + 출력은 다음과 비슷하다. + + ```bash + On branch + Your branch is up to date with 'origin/'. + + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) + + modified: content/en/docs/contribute/new-content/contributing-content.md + + no changes added to commit (use "git add" and/or "git commit -a") + ``` + +2. **Changes not staged for commit** 에 나열된 파일을 커밋에 추가한다. + + ```bash + git add + ``` + + 각 파일에 대해 이 작업을 반복한다. + +3. 모든 파일을 추가한 후, 커밋을 생성한다. + + ```bash + git commit -m "Your commit message" + ``` + + {{< note >}} + 커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 말자. 나중에 풀 리퀘스트 설명에 추가할 + 수 있다. + {{< /note >}} + +4. 로컬 브랜치와 새로운 커밋을 원격 포크로 푸시한다. + + ```bash + git push origin + ``` + +### 로컬에서 변경 사항 미리보기 {#preview-locally} + +변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다. + +website의 도커 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다. + +{{< tabs name="tab_with_hugo" >}} +{{% tab name="Hugo 컨테이너" %}} + +1. 로컬에서 이미지를 빌드한다. + + ```bash + make docker-image + ``` + +2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다. + + ```bash + make docker-serve + ``` + +3. 웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는 + 변경 사항을 보고 필요에 따라 사이트를 다시 구축한다. + +4. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나, + 터미널 창을 닫는다. + +{{% /tab %}} +{{% tab name="Hugo 커맨드 라인" %}} + +또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다. + +5. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. + +6. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다. + + ```bash + cd /website + hugo server + ``` + +7. 브라우저의 주소 표시줄에 `https://localhost:1313` 을 입력한다. + +8. 로컬의 Hugo 인스턴스를 중지하려면, 터미널로 돌아가서 `Ctrl+C` 를 입력하거나, +    터미널 창을 닫는다. + +{{% /tab %}} +{{< /tabs >}} + +### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr} + +1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다. +2. **New Pull Request** 를 선택한다. +3. **compare across forks** 를 선택한다. +4. **head repository** 드롭다운 메뉴에서, 포크를 선택한다. +5. **compare** 드롭다운 메뉴에서, 브랜치를 선택한다. +6. **Create Pull Request** 를 선택한다. +7. 풀 리퀘스트에 대한 설명을 추가한다. + - **Title**(50자 이하): 변경 사항에 대한 의도를 요약한다. + - **Description**: 변경 사항을 자세히 설명한다. + - 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다. 이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다. 다른 관련된 PR이 있는 경우, 이들 PR도 연결한다. + - 구체적인 내용에 대한 조언이 필요한 경우, 원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다. + +8. **Create pull request** 버튼을 선택한다. + + 축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다. + + +PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다. + + - Netlify 빌드가 실패하면, 자세한 정보를 위해 **Details** 를 선택한다. + - Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다. + +또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels)를 참고한다. + +### 로컬에서 피드백 해결 + +1. 변경한 후, 이전 커밋을 수정한다. + + ```bash + git commit -a --amend + ``` + + - `-a`: 모든 변경 사항을 커밋 + - `--amend`: 새로운 커밋을 만들지 않고, 이전 커밋을 수정한다. + +2. 필요한 경우 커밋 메시지를 업데이트한다. + +3. `git push origin ` 를 사용해서 변경 사항을 푸시하고 Netlify 테스트를 다시 실행한다. + + {{< note >}} + 수정하는 대신 `git commit -m` 을 사용하는 경우, 병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다. + {{< /note >}} + +#### 리뷰어의 변경 + +때때로 리뷰어가 여러분의 풀 리퀘스트를 커밋한다. 다른 변경을 하기 전에, 커밋을 가져온다. + +1. 원격 포크에서 커밋을 가져오고 작업 브랜치를 리베이스한다. + + ```bash + git fetch origin + git rebase origin/ + ``` + +2. 리베이스한 후, 포크에 새로운 변경 사항을 강제로 푸시한다. + + ```bash + git push --force-with-lease origin + ``` + +#### 충돌 병합 및 리베이스 + +{{< note >}} +자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다. +{{< /note >}} + +다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다. PR의 모든 병합 충돌을 해결해야 한다. + +1. 포크를 업데이트하고 로컬 브랜치를 리베이스한다. + + ```bash + git fetch origin + git rebase origin/ + ``` + + 그런 다음 포크에 변경 사항을 강제로 푸시한다. + + ```bash + git push --force-with-lease origin + ``` + +2. `kubernetes/website` 의 `upstream/master` 에 대한 변경 사항을 가져오고 브랜치를 리베이스한다. + + ```bash + git fetch upstream + git rebase upstream/master + ``` + +3. 리베이스의 결과를 검사한다. + + ```bash + git status + ``` + + 이 명령의 결과에 여러 파일이 충돌된 것으로 표시된다. + +4. 충돌하는 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다. 충돌을 해결하고 충돌 마커를 삭제한다. + + {{< note >}} + 자세한 내용은 [충돌이 표시되는 방법](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented)을 참고한다. + {{< /note >}} + +5. 변경 세트에 파일을 추가한다. + + ```bash + git add + ``` +6. 리베이스를 계속한다. + + ```bash + git rebase --continue + ``` + +7. 필요에 따라 2단계에서 5단계를 반복한다. + + 모든 커밋을 적용한 후, `git status` 명령은 리베이스가 완료되었음을 나타낸다. + +8. 브랜치를 포크에 강제로 푸시한다. + + ```bash + git push --force-with-lease origin + ``` + + 풀 리퀘스트에 더 이상 충돌이 표시되지 않는다. + + +### 커밋 스쿼시하기 + +{{< note >}} +자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다. +{{< /note >}} + +PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여 커밋 수를 확인할 수 있다. + +{{< note >}} +여기서는 `vim` 을 커맨드 라인 텍스트 편집기로 사용하는 것을 가정한다. +{{< /note >}} + +1. 대화식 리베이스를 시작한다. + + ```bash + git rebase -i HEAD~ + ``` + + 커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~}} + 자세한 내용은 [대화식 모드](https://git-scm.com/docs/git-rebase#_interactive_mode)를 참고한다. + {{< /note >}} + +2. 파일 편집을 시작한다. + + 다음의 원본 텍스트를 변경한다. + + ```bash + pick d875112ca Original commit + pick 4fa167b80 Address feedback 1 + pick 7d54e15ee Address feedback 2 + ``` + + 아래와 같이 변경한다. + + ```bash + pick d875112ca Original commit + squash 4fa167b80 Address feedback 1 + squash 7d54e15ee Address feedback 2 + ``` + + 이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다. 타임라인의 일부로 `d875112ca Original commit` 만 남긴다. + +3. 파일을 저장하고 종료한다. + +4. 스쿼시된 커밋을 푸시한다. + + ```bash + git push --force-with-lease origin + ``` + +## 다른 리포지터리에 기여하기 + +[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다. 이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스 또는 코드 주석과 같은 문서가 포함되어 있다. + +개선하려는 텍스트가 보이면, GitHub을 사용하여 쿠버네티스 조직의 모든 리포지터리를 검색한다. +이를 통해 어디에 이슈나 PR을 제출할지를 파악할 수 있다. + +각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를 +제기하거나 PR을 제출하기 전에, 그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고 +`code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다. + +대부분의 리포지터리에는 이슈와 PR 템플릿이 사용된다. 팀의 프로세스에 대한 +느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때 +가능한 한 상세하게 템플릿의 내용을 작성한다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +- 리뷰 프로세스에 대한 자세한 내용은 [리뷰하기](/ko/docs/contribute/reviewing/revewing-prs)를 읽어본다. + +{{% /capture %}} diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md new file mode 100644 index 0000000000..ca1bc10737 --- /dev/null +++ b/content/ko/docs/contribute/new-content/overview.md @@ -0,0 +1,58 @@ +--- +title: 새로운 콘텐츠 기여하기에 대한 개요 +linktitle: 개요 +content_template: templates/concept +main_menu: true +weight: 5 +--- + +{{% capture overview %}} + +이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다. + + +{{% /capture %}} + +{{% capture body %}} + +## 기여하기에 대한 기본 + +- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다. +- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다. +- [페이지 템플릿](/docs/contribute/style/page-templates/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. +- 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. +- 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. +- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다. + +## 시작하기 전에 {#before-you-begin} + +### CNCF CLA 서명 {#sign-the-cla} + +모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다. + +CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다. + +### 사용할 Git 브랜치를 선택한다 + +풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다. + +시나리오 | 브랜치 +:---------|:------------ +현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `master` +기능 변경 릴리스의 콘텐츠 | `dev-release-` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `{{< latest-version >}}` 에서 기능이 변경된 경우, ``dev-{{< release-branch >}}`` 에 문서 변경을 추가한다. +다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다. + + +어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다. + +{{< note >}} +풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면, +제출자(제출자인 여러분만)가 이를 변경할 수 있다. +{{< /note >}} + +### PR 당 언어 + +PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다. + + +{{% /capture %}} diff --git a/content/ko/docs/contribute/review/_index.md b/content/ko/docs/contribute/review/_index.md new file mode 100644 index 0000000000..a79fb6129f --- /dev/null +++ b/content/ko/docs/contribute/review/_index.md @@ -0,0 +1,14 @@ +--- +title: 변경 사항 리뷰하기 +weight: 30 +--- + +{{% capture overview %}} + +이 섹션은 콘텐츠를 리뷰하는 방법에 대해 설명한다. + +{{% /capture %}} + +{{% capture body %}} + +{{% /capture %}} diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md new file mode 100644 index 0000000000..c6ebb465ac --- /dev/null +++ b/content/ko/docs/contribute/review/for-approvers.md @@ -0,0 +1,228 @@ +--- +title: 승인자와 리뷰어의 리뷰 +linktitle: 승인자와 리뷰어용 +slug: for-approvers +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +SIG Docs [리뷰어](/ko/docs/contribute/participating/#리뷰어)와 [승인자](/ko/docs/contribute/participating/#승인자)는 변경 사항을 리뷰할 때 몇 가지 추가 작업을 수행한다. + +매주 특정 문서 승인자 역할의 지원자가 +풀 리퀘스트를 심사하고 리뷰한다. 이 +사람은 일주일 동안 "PR 랭글러(Wrangler)"이다. 자세한 +정보는 [PR 랭글러 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 참고한다. PR 랭글러가 되려면, 매주 SIG Docs 회의에 참석하고 자원한다. 이번 주에 해당 일정이 없는 경우에도, 아직 리뷰 중이 아닌 +풀 리퀘스트(PR)를 여전히 리뷰할 수 있다. + +로테이션 외에도, 봇은 영향을 받는 파일의 소유자를 기반으로 +PR에 대한 리뷰어와 승인자를 할당한다. + +{{% /capture %}} + + +{{% capture body %}} + +## PR 리뷰 + +쿠버네티스의 문서는 [쿠버네티스의 코드 리뷰 프로세스](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)를 따른다. + +[풀 리퀘스트 리뷰](/ko/docs/contribute/review/reviewing-prs)에 설명된 모든 내용이 적용되지만, 리뷰어와 승인자도 다음을 수행해야 한다. + +- `/assign` Prow 명령을 사용하여 필요에 따라 특정 리뷰어를 PR에 할당한다. 이는 코드 기여자에게 +기술 리뷰를 요청할 때 특히 중요하다. + + {{< note >}} + 마크다운 파일 맨 위에 있는 헤더의 `reviewers` 필드를 보고 기술 리뷰를 + 제공할 수 있는 사람을 확인한다. + {{< /note >}} + +- PR이 [콘텐츠](/docs/contribute/style/content-guide/)와 [스타일](/docs/contribute/style/style-guide/) 가이드를 따르는 지 확인한다. 그렇지 않은 경우 가이드의 관련 부분에 작성자를 연결한다. +- 적용이 가능한 경우 GitHub **Request Changes** 옵션을 사용하여 PR 작성자에게 변경을 제안한다. +- 제안한 사항이 구현된 경우, `/approve` 또는 `/lgtm` Prow 명령을 사용하여 GitHub에서 리뷰 상태를 변경한다. + +## 다른 사람의 PR에 커밋 + +PR 코멘트를 남기는 것이 도움이 되지만, 대신 다른 사람의 PR에 커밋을 +해야 하는 경우가 있다. + +다른 사람이 명시적으로 요청하거나, 오랫동안 +중단된 PR을 재개하려는 경우가 아니라면 다른 사람에게서 "가져오지" 마라. 단기적으로는 +작업이 빠를 수 있지만, 그 사람이 기여할 기회를 박탈하게 된다. + +사용할 프로세스는 이미 PR의 범위에 있는 파일을 편집해야 +하는지, 또는 PR이 아직 다루지 않은 파일을 편집해야 하는지에 따라 다르다. + +다음 중 하나에 해당하면 다른 사람의 PR에 커밋할 수 +없다. + +- PR 작성자가 브랜치를 + [https://github.com/kubernetes/website/](https://github.com/kubernetes/website/) + 리포지터리로 직접 푸시한 경우, 푸시 접근 권한이 있는 리뷰어만 다른 사용자의 PR에 커밋할 수 있다. + + {{< note >}} + 다음 번부터는 PR을 열기 전에 작성자가 브랜치를 자신의 포크로 + 푸시하도록 권장한다. + {{< /note >}} + +- PR 작성자가 승인자의 수정을 명시적으로 허용하지 않는다. + +## 리뷰를 위한 Prow 명령 + +[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)는 +풀 리퀘스트 (PR)에 대한 작업을 실행하는 쿠버네티스 기반 CI/CD 시스템이다. Prow는 +챗봇 스타일 명령으로 쿠버네티스 +조직 전체에서 [레이블 추가와 +제거](#이슈-레이블-추가와-제거), 이슈 종료 및 승인자 할당과 같은 GitHub 작업을 처리할 수 ​​있다. `/` 형식을 사용하여 Prow 명령을 GitHub 코멘트로 입력한다. + +리뷰어와 승인자가 사용하는 가장 일반적인 Prow 명령은 다음과 같다. + +{{< table caption="리뷰를 위한 Prow 명령" >}} +Prow 명령 | 역할 제한 | 설명 +:------------|:------------------|:----------- +`/lgtm` | 누구나, 리뷰어나 승인자가 사용한다면 자동화를 트리거한다. | PR 리뷰를 마치고 변경 사항에 만족했음을 나타낸다. +`/approve` | 승인자 | PR을 병합(merge)하기 위해 승인한다. +`/assign` | 리뷰어 또는 승인자 | PR을 리뷰하거나 승인할 사람을 지정한다. +`/close` | 리뷰어 또는 승인자 | 이슈 또는 PR을 닫는다. +`/hold` | 누구나 | 자동으로 병합할 수 없음을 나타내는 `do-not-merge/hold` 레이블을 추가한다. +`/hold cancel` | 누구나 | `do-not-merge/hold` 레이블을 제거한다. +{{< /table >}} + +PR에서 사용할 수 있는 명령의 전체 목록을 보려면 +[Prow 명령 레퍼런스](https://prow.k8s.io/command-help)를 참고한다. + +## 이슈 심사와 분류 + + +일반적으로, SIG Docs는 [쿠버네티스 이슈 심사](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md) 프로세스를 따르며 동일한 레이블을 사용한다. + + +이 GitHub 이슈 [필터](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)는 +심사가 필요한 이슈를 찾는다. + +### 이슈 심사 + +1. 이슈 확인 + - 이슈가 website 문서에 관한 것인지 확인한다. 질문에 답하거나 + 리소스에 리포터를 지정하면 일부 이슈를 신속하게 종결할 수 있다. 자세한 내용은 + [지원 요청 또는 코드 버그 리포트](#지원-요청-또는-코드-버그-리포트) 섹션을 참고한다. + - 이슈가 가치가 있는지 평가한다. + - 이슈의 내용에 실행할 수 있는 세부 사항이 충분하지 않거나 템플릿의 내용이 + 제대로 작성되지 않은 경우 `triage/needs-information` 레이블을 추가한다. + - `lifecycle/stale` 과 `triage/needs-information` 레이블이 모두 있으면 이슈를 닫는다. + +2. 우선순위 레이블을 + 추가한다([이슈 심사 가이드라인](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)은 우선순위 레이블을 자세히 정의함). + + {{< table caption="이슈 레이블" >}} + 레이블 | 설명 + :------------|:------------------ + `priority/critical-urgent` | 이 작업을 지금 즉시 수행한다. + `priority/important-soon` | 3개월 이내에 이 작업을 수행한다. + `priority/important-longterm` | 6개월 이내에 이 작업을 수행한다. + `priority/backlog` | 무기한 연기할 수 있다. 자원이 있을 때 수행한다. + `priority/awaiting-more-evidence` | 잠재적으로 좋은 이슈에 대해 잊지 않도록 표시한다. + `help` 또는 `good first issue` | 쿠버네티스나 SIG Docs 경험이 거의 없는 사람에게 적합하다. 자세한 내용은 [도움이 필요함 및 좋은 첫 번째 이슈 레이블](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)을 참고한다. + + {{< /table >}} + + 재량에 따라, 이슈의 소유권을 가져와서 PR을 + 제출한다(특히, 이미 수행 중인 작업과 관련이 있거나 빠르다면). + +이슈 심사에 대해 질문이 있다면, 슬랙의 `#sig-docs` 채널이나 +[kubernetes-sig-docs 메일링리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 문의한다. + +## 이슈 레이블 추가와 제거 + +레이블을 추가하려면, 다음의 형식 중 하나로 코멘트를 남긴다. + +- `/` (예: `/good-first-issue`) +- `/ ` (예: `/triage needs-information` 또는 `/language ko`) + +레이블을 제거하려면, 다음의 형식 중 하나로 코멘트를 남긴다. + +- `/remove-` (예: `/remove-help`) +- `/remove- ` (예: `/remove-triage needs-information`) + +두 경우 모두, 사용하려는 레이블은 이미 존재하는 레이블이어야 한다. 존재하지 않는 레이블을 추가하려고 하면, 명령이 +자동으로 무시된다. + +모든 레이블 목록에 대해서는 [website 리포지터리의 레이블 섹션](https://github.com/kubernetes/website/labels)을 참고한다. SIG Docs에서 모든 레이블을 사용하는 것은 아니다. + +### 이슈의 lifecycle 레이블 + +이슈는 일반적으로 신속하게 열리고 닫힌다. +그러나, 가끔씩은 이슈가 열린 후 비활성 상태로 있다. +어떤 경우에는 이슈가 90일 이상 열려 있을 수도 있다. + +{{< table caption="이슈의 lifecycle 레이블" >}} +레이블 | 설명 +:------------|:------------------ +`lifecycle/stale` | 90일이 지나도 아무런 활동이 없는 이슈는 자동으로 오래된 것(stale)으로 표시된다. `/remove-lifecycle stale` 명령을 사용하여 라이프사이클을 수동으로 되돌리지 않으면 이슈가 자동으로 닫힌다. +`lifecycle/frozen` | 90일 동안 활동이 없어도 이 레이블의 이슈는 오래된 것(stale)으로 바뀌지 않는다. 사용자는 `priority/important-longterm` 레이블이 있는 이슈처럼 90일보다 훨씬 오래 열려 있어야 하는 이슈에 이 레이블을 수동으로 추가한다. +{{< /table >}} + +## 특별한 이슈 유형의 처리 + +SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의 이슈를 +자주 경험하게 된다. + +### 중복된 이슈 + +단일 문제에 대해 하나 이상의 이슈가 열려 있으면, 이를 단일 이슈로 합친다. +열린 상태를 유지할 이슈를 결정한 다음(또는 +새로운 이슈를 열어야 함), 모든 관련 정보로 이동하여 관련 이슈를 연결해야 한다. +마지막으로, 동일한 문제를 설명하는 다른 모든 이슈에 +`triage/duplicate` 레이블을 지정하고 닫는다. 하나의 이슈만 해결하는 것으로 혼동을 줄이고 +같은 문제에 대한 중복 작업을 피할 수 있다. + +### 깨진 링크 이슈 + +깨진 링크 이슈가 API 문서나 `kubectl` 문서에 있는 경우, 문제가 완전히 이해될 때까지 `/priority critical-urgent` 레이블을 할당한다. 다른 모든 깨진 링크 이슈는 수동으로 수정해야하므로, `/priority important-longterm` 를 할당한다. + +### 블로그 이슈 + +[쿠버네티스 블로그](https://kubernetes.io/blog/) 항목은 시간이 지남에 따라 +구식이 될 것으로 예상한다. 따라서, 1년 미만의 블로그 항목만 유지 관리한다. +1년이 지난 블로그 항목과 관련된 이슈일 경우, +수정하지 않고 이슈를 닫는다. + +### 지원 요청 또는 코드 버그 리포트 + +문서에 대한 일부 이슈는 실제로 기본 코드와 관련된 이슈이거나, 튜토리얼과 +같은 무언가가 작동하지 않을 때 도움을 요청하는 것이다. +문서와 관련이 없는 이슈의 경우, `triage/support` 레이블과 함께 요청자에게 지원받을 수 있는 곳(슬랙, Stack Overflow)을 +알려주며 이슈를 닫고, 기능 관련 버그에 대한 이슈인 경우, +관련 리포지터리를 코멘트로 남긴다(`kubernetes/kubernetes` 는 +시작하기 좋은 곳이다). + +지원 요청에 대한 샘플 응답은 다음과 같다. + +```none +이 이슈는 지원 요청과 비슷하지만 +문서 관련 이슈와는 관련이 없는 것 같습니다. +[쿠버네티스 슬랙](http://slack.k8s.io/)의 +`#kubernetes-users` 채널에서 질문을 하시기 바랍니다. 또한, +[Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)와 +같은 리소스를 검색하여 유사한 질문에 대한 답변을 +얻을 수도 있습니다. + +https://github.com/kubernetes/kubernetes 에서 +쿠버네티스 기능 관련 이슈를 열 수도 있습니다. + +문서에 대한 이슈인 경우 이 이슈를 다시 여십시오. +``` + +샘플 코드 버그 리포트 응답은 다음과 같다. + +```none +이 이슈는 문서에 대한 이슈보다 코드에 대한 이슈와 +비슷합니다. https://github.com/kubernetes/kubernetes/issues 에서 +이슈를 여십시오. + +문서에 대한 이슈인 경우 이 이슈를 다시 여십시오. +``` + + +{{% /capture %}} diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md new file mode 100644 index 0000000000..c220e9599c --- /dev/null +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -0,0 +1,98 @@ +--- +title: 풀 리퀘스트 리뷰 +content_template: templates/concept +main_menu: true +weight: 10 +--- + +{{% capture overview %}} + +누구나 문서화에 대한 풀 리퀘스트를 리뷰할 수 있다. 쿠버네티스 website 리포지터리의 [풀 리퀘스트](https://github.com/kubernetes/website/pulls) 섹션을 방문하여 열린(open) 풀 리퀘스트를 확인한다. + +문서화에 대한 풀 리퀘스트를 리뷰하는 것은 +쿠버네티스 커뮤니티에 자신을 소개하는 훌륭한 방법이다. +아울러, 코드 베이스(code base)를 배우고 다른 기여자와 신뢰를 구축하는 데 도움이 된다. + +리뷰하기 전에, 다음을 수행하는 것이 좋다. + +- 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와 +[스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. +- 쿠버네티스 문서화 커뮤니티의 다양한 [역할과 책임](/docs/contribute/participating/#roles-and-responsibilities)을 이해한다. + +{{% /capture %}} + +{{% capture body %}} + +## 시작하기 전에 + +리뷰를 시작하기 전에 다음을 명심하자. + +- [CNCF 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 읽고 항상 준수한다. +- 정중하고, 사려 깊고, 도움이 되자. +- PR의 긍정적인 측면과 변화에 대한 의견을 남긴다. +- 당신의 리뷰를 어떻게 받아들일지에 대해 공감하고 주의한다. +- 좋은 의도를 가지고 명확한 질문을 한다. +- 숙련된 기여자인 경우, 작업에 광범위한 변경이 필요한 새 기여자와 쌍을 이루어 리뷰해 본다. + +## 리뷰 과정 + +일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. + +1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로 + 이동한다. + 쿠버네티스 website와 문서에 대한 모든 열린 풀 리퀘스트 목록이 + 표시된다. + +2. 다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다. + - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다. + - `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다. + - `size/`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다. + + 또한, PR이 진행 중인 작업으로 표시되지 않았는지 확인한다. `work in progress` 레이블을 사용하는 PR은 아직 리뷰할 준비가 되지 않은 PR이다. + +3. 리뷰할 PR을 선택한 후, 다음을 통해 변경 사항을 이해한다. + - PR 설명을 통해 변경 사항을 이해하고, 연결된 이슈 읽기 + - 다른 리뷰어의 의견 읽기 + - **Files changed** 탭을 클릭하여 변경된 파일과 행 보기 + - **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 **deploy/netlify** 행의 **Details** 링크를 클릭하고 Netlify 미리보기 빌드의 변경 사항을 확인 + +4. **Files changed** 탭으로 이동하여 리뷰를 시작한다. + 1. 코멘트을 달려는 줄 옆에 있는 `+` 기호를 클릭한다. + 2. 행에 대한 의견을 작성하고 **Add single comments**(작성할 의견이 하나만 있는 경우) 또는 **Start a review**(작성할 의견이 여러 개인 경우)를 클릭한다. + 3. 완료되면, 페이지 상단에서 **Review changes** 를 클릭한다. 여기에서 + 리뷰에 대한 요약을 추가하고(기여자에게 긍정적인 의견을 남겨주기 바란다!), + PR을 승인하거나, 의견을 보내거나 필요에 따라 변경을 요청할 수 있다. 새로운 기여자는 + 항상 **Comment** 를 선택해야 한다. + +## 리뷰 체크리스트 + +리뷰할 때, 다음을 시작점으로 사용한다. + +### 언어와 문법 + +- 언어나 문법에 명백한 오류가 있는가? 무언가를 표현하는 더 좋은 방법이 있는가? +- 더 간단한 단어로 대체될 수 있는 복잡하거나 오래된 단어가 있는가? +- 비 차별적 대안으로 대체될 수 있는 단어, 용어 또는 문구가 있는가? +- 단어 선택과 대소문자는 [스타일 가이드](/docs/contribute/style/style-guide/)를 따르는가? +- 더 짧고 간결하게 만들 수 있는 긴 문장이 있는가? +- 목록이나 표로 더 잘 표현할 수 있는 긴 단락이 있는가? + +### 콘텐츠 + +- 쿠버네티스 사이트의 다른 곳에도 비슷한 콘텐츠가 있는가? +- 콘텐츠가 오프-사이트, 개별 업체, 또는 공개되지 않은 소스 문서에 과도하게 링크되는가? + +### 웹 사이트 + +- 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가? 그렇다면, 이 PR의 결과로 끊어진 링크가 있는가? slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가? +- PR이 새로운 페이지를 소개하는가? 그렇다면, + - 페이지가 올바른 [페이지 템플릿](/docs/contribute/style/page-templates/)과 연관된 Hugo 단축 코드를 사용하는가? + - 섹션의 측면 탐색에 페이지가 올바르게 나타나는가? + - 페이지가 [문서 홈](/ko/docs/home/) 목록에 나타나야 하는가? +- 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다. + +### 기타 + +오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다. 이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다. + +{{% /capture %}} diff --git a/content/ko/docs/contribute/style/_index.md b/content/ko/docs/contribute/style/_index.md new file mode 100644 index 0000000000..69ece73a9a --- /dev/null +++ b/content/ko/docs/contribute/style/_index.md @@ -0,0 +1,9 @@ +--- +title: 문서 스타일 개요 +main_menu: true +weight: 80 +--- + +이 섹션의 주제는 문서 작성 스타일, 컨텐츠 형식과 +구성, 쿠버네티스 문서화에 적합하게 사용자 정의된 Hugo 사용 방법에 대한 +가이드를 제공한다. diff --git a/content/ko/docs/reference/glossary/cloud-controller-manager.md b/content/ko/docs/reference/glossary/cloud-controller-manager.md new file mode 100644 index 0000000000..20121a9371 --- /dev/null +++ b/content/ko/docs/reference/glossary/cloud-controller-manager.md @@ -0,0 +1,23 @@ +--- +title: 클라우드 컨트롤 매니저 +id: cloud-controller-manager +date: 2018-04-12 +full_link: /ko/docs/concepts/architecture/cloud-controller/ +short_description: > + 쿠버네티스를 타사 클라우드 공급자와 통합하는 컨트롤 플레인 컴포넌트. +aka: +tags: +- core-object +- architecture +- operation +--- + 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 +{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다. +클라우트 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, +해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와 상호 작용하는 컴포넌트를 분리할 수 있다. + + + +쿠버네티스와 기본 클라우드 인프라스터럭처 간의 상호 운용성 로직을 +분리함으로써, cloud-controller-manager 컴포넌트는 클라우드 공급자가 +주요 쿠버네티스 프로젝트와 다른 속도로 기능들을 릴리스할 수 있도록 한다. diff --git a/content/ko/docs/reference/glossary/cluster.md b/content/ko/docs/reference/glossary/cluster.md index 9f4827b52b..13ea3b3606 100755 --- a/content/ko/docs/reference/glossary/cluster.md +++ b/content/ko/docs/reference/glossary/cluster.md @@ -2,18 +2,19 @@ title: 클러스터(Cluster) id: cluster date: 2019-06-15 -full_link: +full_link: short_description: > - 컨테이너화된 애플리케이션을 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. + 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. aka: tags: - fundamental - operation --- -컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. +컨테이너화된 애플리케이션을 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}라고 +하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. - + 워커 노드는 애플리케이션의 구성요소인 {{< glossary_tooltip text="파드" term_id="pod" >}}를 호스트한다. {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 워커 노드와 diff --git a/content/ko/docs/reference/glossary/configmap.md b/content/ko/docs/reference/glossary/configmap.md new file mode 100755 index 0000000000..06cd2c9c46 --- /dev/null +++ b/content/ko/docs/reference/glossary/configmap.md @@ -0,0 +1,20 @@ +--- +title: 컨피그맵(ConfigMap) +id: configmap +date: 2018-04-12 +full_link: /docs/concepts/configuration/configmap/ +short_description: > + 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. 볼륨에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 사용될 수 있다. + +aka: +tags: +- core-object +--- + 키-값 쌍으로 기밀이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트이다. +{{< glossary_tooltip text="파드" term_id="pod" >}}는 +{{< glossary_tooltip text="볼륨" term_id="volume" >}}에서 +환경 변수, 커맨드-라인 인수 또는 구성 파일로 컨피그맵을 사용할 수 있다. + + + +컨피그맵을 사용하면 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다. diff --git a/content/ko/docs/reference/glossary/control-plane.md b/content/ko/docs/reference/glossary/control-plane.md index 4cf2abbf5a..96b344ef76 100644 --- a/content/ko/docs/reference/glossary/control-plane.md +++ b/content/ko/docs/reference/glossary/control-plane.md @@ -11,3 +11,15 @@ tags: - fundamental --- 컨테이너의 라이프사이클을 정의, 배포, 관리하기 위한 API와 인터페이스들을 노출하는 컨테이너 오케스트레이션 레이어. + + + +이 계층은 다음과 같은 다양한 컴포넌트로 구성된다(그러나 제한되지는 않는다). + + * {{< glossary_tooltip text="etcd" term_id="etcd" >}} + * {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} + * {{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}} + * {{< glossary_tooltip text="컨트롤러 매니저" term_id="kube-controller-manager" >}} + * {{< glossary_tooltip text="클라우드 컨트롤러 매니저" term_id="cloud-controller-manager" >}} + + 이러한 컴포넌트는 기존 운영체제 서비스(데몬) 또는 컨테이너로 실행할 수 있다. 이러한 컴포넌트를 실행하는 호스트를 {{< glossary_tooltip text="마스터" term_id="master" >}}라 한다. \ No newline at end of file diff --git a/content/ko/docs/reference/glossary/cronjob.md b/content/ko/docs/reference/glossary/cronjob.md index 452f95a4af..b0f8342b66 100755 --- a/content/ko/docs/reference/glossary/cronjob.md +++ b/content/ko/docs/reference/glossary/cronjob.md @@ -4,7 +4,7 @@ id: cronjob date: 2018-04-12 full_link: /ko/docs/concepts/workloads/controllers/cron-jobs/ short_description: > - 주기적인 일정에 따라 실행되는 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리. + 정기적인 일정으로 실행되는 반복 작업(잡). aka: tags: diff --git a/content/ko/docs/reference/glossary/deployment.md b/content/ko/docs/reference/glossary/deployment.md index e21c413d70..00bd0d12fb 100755 --- a/content/ko/docs/reference/glossary/deployment.md +++ b/content/ko/docs/reference/glossary/deployment.md @@ -4,7 +4,7 @@ id: deployment date: 2018-04-12 full_link: /ko/docs/concepts/workloads/controllers/deployment/ short_description: > - 복제된(replicated) 애플리케이션을 관리하는 API 오브젝트. + 클러스터에서 복제된 애플리케이션을 관리한다. aka: tags: @@ -12,9 +12,10 @@ tags: - core-object - workload --- - 복제된 애플리케이션을 관리하는 API 오브젝트. + 일반적으로 로컬 상태가 없는 파드를 실행하여 복제된 애플리케이션을 관리하는 API 오브젝트. -각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 파드는 클러스터의 {{< glossary_tooltip text="노드" term_id="node" >}}에 분산된다. - +각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, +파드는 클러스터의 {{< glossary_tooltip text="노드" term_id="node" >}}에 분산된다. +로컬 상태가 필요한 워크로드의 경우 {{< glossary_tooltip term_id="StatefulSet" >}}의 사용을 고려한다. \ No newline at end of file diff --git a/content/ko/docs/reference/glossary/pod.md b/content/ko/docs/reference/glossary/pod.md index c7a4d4debc..565361ea7b 100755 --- a/content/ko/docs/reference/glossary/pod.md +++ b/content/ko/docs/reference/glossary/pod.md @@ -4,7 +4,7 @@ id: pod date: 2018-04-12 full_link: /ko/docs/concepts/workloads/pods/pod-overview/ short_description: > - 가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 컨테이너의 집합을 나타낸다. + 파드는 클러스터에서 실행 중인 컨테이너의 집합을 나타낸다. aka: tags: diff --git a/content/ko/docs/reference/glossary/service-account.md b/content/ko/docs/reference/glossary/service-account.md index 1de65927ba..d70aabf794 100755 --- a/content/ko/docs/reference/glossary/service-account.md +++ b/content/ko/docs/reference/glossary/service-account.md @@ -1,5 +1,5 @@ --- -title: 서비스 어카운트(ServiceAccount) +title: 서비스어카운트(ServiceAccount) id: service-account date: 2018-04-12 full_link: /docs/tasks/configure-pod-container/configure-service-account/ diff --git a/content/ko/docs/reference/glossary/statefulset.md b/content/ko/docs/reference/glossary/statefulset.md index 71fde2fc06..afb2dd3ba9 100755 --- a/content/ko/docs/reference/glossary/statefulset.md +++ b/content/ko/docs/reference/glossary/statefulset.md @@ -4,7 +4,7 @@ id: statefulset date: 2018-04-12 full_link: /ko/docs/concepts/workloads/controllers/statefulset/ short_description: > - 파드 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 *순서 및 고유성을 보장한다* . + 내구성이 있는 스토리지와 파드별로 지속성 식별자를 사용해서 파드 집합의 디플로이먼트와 스케일링을 관리한다. aka: tags: @@ -17,4 +17,6 @@ tags: -{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀 셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀 셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다. +{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다. + +스토리지 볼륨을 사용해서 워크로드에 지속성을 제공하려는 경우, 솔루션의 일부로 스테이트풀셋을 사용할 수 있다. 스테이트풀셋의 개별 파드는 장애에 취약하지만, 퍼시스턴트 파드 식별자는 기존 볼륨을 실패한 볼륨을 대체하는 새 파드에 더 쉽게 일치시킬 수 있다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 94fd790fb9..8956d72474 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -64,7 +64,7 @@ kubectl config get-contexts # 컨텍스트 리스트 kubectl config current-context # 현재 컨텍스트 출력 kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정 -# 기본 인증을 지원하는 새로운 클러스터를 kubeconf에 추가한다 +# 기본 인증을 지원하는 새로운 사용자를 kubeconf에 추가한다 kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword # 해당 컨텍스트에서 모든 후속 kubectl 커맨드에 대한 네임스페이스를 영구적으로 저장한다 @@ -342,6 +342,21 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 `-o=wide` | 추가 정보가 포함된 일반-텍스트 형식으로 출력하고, 파드의 경우 노드 명이 포함 `-o=yaml` | YAML 형식의 API 오브젝트 출력 +`-o=custom-columns` 의 사용 예시: + +```bash +# 클러스터에서 실행 중인 모든 이미지 +kubectl get pods -A -o=custom-columns='DATA: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' + +# 이름에 관계없이 메타데이터 아래의 모든 필드 +kubectl get pods -A -o=custom-columns='DATA:metadata.*' +``` + +More examples in the kubectl [reference documentation](/docs/reference/kubectl/overview/#custom-columns). + ### Kubectl 출력 로그 상세 레벨(verbosity)과 디버깅 Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 레벨을 나타내는 정수로 제어된다. 일반적인 쿠버네티스 로깅 규칙과 관련 로그 레벨이 [여기](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)에 설명되어 있다. diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index 82ebdccb29..1ea418fd5e 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -50,28 +50,28 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery | Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) | | Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) | | Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) | -| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | -| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | | Node.js | [github.com/ajpauwels/easy-k8s](https://github.com/ajpauwels/easy-k8s) +| Node.js | [github.com/godaddy/kubernetes-client](https://github.com/godaddy/kubernetes-client) | +| Node.js | [github.com/tenxcloud/node-kubernetes-client](https://github.com/tenxcloud/node-kubernetes-client) | | Perl | [metacpan.org/pod/Net::Kubernetes](https://metacpan.org/pod/Net::Kubernetes) | -| PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | | PHP | [github.com/allansun/kubernetes-php-client](https://github.com/allansun/kubernetes-php-client) | +| 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) | | 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) | -| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | +| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | | 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/doriordan/skuber](https://github.com/doriordan/skuber) | -| dotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | +| Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-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) | -| Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | {{% /capture %}} diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index 3aed39f400..3efc951e1b 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -195,7 +195,7 @@ minikube start --driver= * virtualbox * vmwarefusion -* docker (EXPERIMENTAL) +* docker ([드라이버 설치](https://minikube.sigs.k8s.io/docs/drivers/docker/) * kvm2 ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/)) * hyperkit ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/)) * hyperv ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/)) @@ -457,11 +457,11 @@ Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/communit ## 추가적인 링크: -* **목표와 비목표**: Minikube 프로젝트의 목표와 비목표에 대해서는 [로드맵](https://git.k8s.io/minikube/docs/contributors/roadmap.md)을 살펴보자. -* **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [참여 가이드](https://git.k8s.io/minikube/CONTRIBUTING.md)를 살펴보자. -* **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://git.k8s.io/minikube/docs/contributors/build_guide.md)를 살펴보자. -* **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)를 보자. -* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)를 보자. +* **목표와 비목표**: Minikube 프로젝트의 목표와 비목표에 대해서는 [로드맵](https://minikube.sigs.k8s.io/docs/contrib/roadmap/)을 살펴보자. +* **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [기여하기](https://minikube.sigs.k8s.io/docs/contrib/)를 살펴보자. +* **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://minikube.sigs.k8s.io/docs/contrib/building/)를 살펴보자. +* **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/drivers/)를 보자. +* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자. * **MicroK8s**: 가상 머신을 사용하지 않으려는 Linux 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다. ## 커뮤니티 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 2520f1ed2d..7651fcc172 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 @@ -7,7 +7,7 @@ weight: 40 {{% capture overview %}} -{{< feature-state for_k8s_version="1.12" state="stable" >}} +{{< feature-state for_k8s_version="v1.12" state="stable" >}} kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는 기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다. diff --git a/content/ko/docs/tasks/administer-cluster/highly-available-master.md b/content/ko/docs/tasks/administer-cluster/highly-available-master.md index cd9be9736c..880f4a4992 100644 --- a/content/ko/docs/tasks/administer-cluster/highly-available-master.md +++ b/content/ko/docs/tasks/administer-cluster/highly-available-master.md @@ -6,7 +6,7 @@ content_template: templates/task {{% capture overview %}} -{{< feature-state for_k8s_version="1.5" state="alpha" >}} +{{< feature-state for_k8s_version="v1.5" state="alpha" >}} 구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 마스터를 복제할 수 있다. 이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 마스터를 관리하는 방법과 GCE와 함께 사용하기 위해 HA 마스터를 구현하는 방법에 관해 설명한다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/_index.md b/content/ko/docs/tasks/administer-cluster/kubeadm/_index.md new file mode 100755 index 0000000000..6f01fc069a --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/_index.md @@ -0,0 +1,4 @@ +--- +title: "kubeadm으로 관리하기" +weight: 10 +--- diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md new file mode 100644 index 0000000000..f24ae129ec --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -0,0 +1,443 @@ +--- +title: kubeadm 클러스터 업그레이드 +content_template: templates/task +weight: 20 +min-kubernetes-server-version: 1.18 +--- + +{{% capture overview %}} + +이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를 +1.17.x 버전에서 1.18.x 버전으로, 1.18.x 버전에서 1.18.y(여기서 `y > x`) 버전으로 업그레이드하는 방법을 설명한다. + +이전 버전의 kubeadm을 사용하여 생성된 클러스터 업그레이드에 대한 정보를 보려면, +이 페이지 대신 다음의 페이지들을 참고한다. + +- [kubeadm 클러스터를 1.16에서 1.17로 업그레이드](https://v1-17.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [kubeadm 클러스터를 1.15에서 1.16으로 업그레이드](https://v1-16.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [kubeadm 클러스터를 1.14에서 1.15로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-15/) +- [kubeadm 클러스터를 1.13에서 1.14로 업그레이드](https://v1-15.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14/) + +추상적인 업그레이드 작업 절차는 다음과 같다. + +1. 기본 컨트롤 플레인 노드를 업그레이드한다. +1. 추가 컨트롤 플레인 노드를 업그레이드한다. +1. 워커(worker) 노드를 업그레이드한다. + +{{% /capture %}} + +{{% capture prerequisites %}} + +- 1.17.0 버전 이상을 실행하는 kubeadm 쿠버네티스 클러스터가 있어야 한다. +- [스왑을 비활성화해야 한다](https://serverfault.com/questions/684771/best-way-to-disable-swap-in-linux). +- 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다. +- [릴리스 노트]({{< latest-release-notes >}})를 주의 깊게 읽어야 한다. +- 데이터베이스에 저장된 앱-레벨 상태와 같은 중요한 컴포넌트를 반드시 백업한다. + `kubeadm upgrade` 는 워크로드에 영향을 미치지 않고, 쿠버네티스 내부의 컴포넌트만 다루지만, 백업은 항상 모범 사례일 정도로 중요하다. + +### 추가 정보 + +- 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다. +- 하나의 MINOR 버전에서 다음 MINOR 버전으로, + 또는 동일한 MINOR의 PATCH 버전 사이에서만 업그레이드할 수 있다. 즉, 업그레이드할 때 MINOR 버전을 건너 뛸 수 없다. + 예를 들어, 1.y에서 1.y+1로 업그레이드할 수 있지만, 1.y에서 1.y+2로 업그레이드할 수는 없다. + +{{% /capture %}} + +{{% capture steps %}} + +## 업그레이드할 버전 결정 + +1. 최신의 안정 버전인 1.18을 찾는다. + + {{< tabs name="k8s_install_versions" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + apt update + apt-cache madison kubeadm + # 목록에서 최신 버전 1.18을 찾는다 + # 1.18.x-00과 같아야 한다. 여기서 x는 최신 패치이다. + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + yum list --showduplicates kubeadm --disableexcludes=kubernetes + # 목록에서 최신 버전 1.18을 찾는다 + # 1.18.x-0과 같아야 한다. 여기서 x는 최신 패치이다. + {{% /tab %}} + {{< /tabs >}} + +## 컨트롤 플레인 노드 업그레이드 + +### 첫 번째 컨트롤 플레인 노드 업그레이드 + +1. 첫 번째 컨트롤 플레인 노드에서 kubeadm을 업그레이드한다. + + {{< tabs name="k8s_install_kubeadm_first_cp" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + # 1.18.x-00에서 x를 최신 패치 버전으로 바꾼다. + apt-mark unhold kubeadm && \ + apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ + apt-mark hold kubeadm + + # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 + apt-get update && \ + apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다. + yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes + {{% /tab %}} + {{< /tabs >}} + +1. 다운로드하려는 버전이 잘 받아졌는지 확인한다. + + ```shell + kubeadm version + ``` + +1. 컨트롤 플레인 노드를 드레인(drain)한다. + + ```shell + # 을 컨트롤 플레인 노드 이름으로 바꾼다. + kubectl drain --ignore-daemonsets + ``` + +1. 컨트롤 플레인 노드에서 다음을 실행한다. + + ```shell + sudo kubeadm upgrade plan + ``` + + 다음과 비슷한 출력이 표시되어야 한다. + + ``` + [upgrade/config] Making sure the configuration is correct: + [upgrade/config] Reading configuration from the cluster... + [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' + [preflight] Running pre-flight checks. + [upgrade] Running cluster health checks + [upgrade] Fetching available versions to upgrade to + [upgrade/versions] Cluster version: v1.17.3 + [upgrade/versions] kubeadm version: v1.18.0 + [upgrade/versions] Latest stable version: v1.18.0 + [upgrade/versions] Latest version in the v1.17 series: v1.18.0 + + Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply': + COMPONENT CURRENT AVAILABLE + Kubelet 1 x v1.17.3 v1.18.0 + + Upgrade to the latest version in the v1.17 series: + + COMPONENT CURRENT AVAILABLE + API Server v1.17.3 v1.18.0 + Controller Manager v1.17.3 v1.18.0 + Scheduler v1.17.3 v1.18.0 + Kube Proxy v1.17.3 v1.18.0 + CoreDNS 1.6.5 1.6.7 + Etcd 3.4.3 3.4.3-0 + + You can now apply the upgrade by executing the following command: + + kubeadm upgrade apply v1.18.0 + + _____________________________________________________________________ + ``` + + 이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다. + + {{< note >}} + 또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다. + 인증서 갱신을 하지 않으려면 `--certificate-renewal=false` 플래그를 사용할 수 있다. + 자세한 내용은 [인증서 관리 가이드](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다. + {{}} + +1. 업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다. + + ```shell + # 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다. + sudo kubeadm upgrade apply v1.18.x + ``` + + + 다음과 비슷한 출력이 표시되어야 한다. + + ``` + [upgrade/config] Making sure the configuration is correct: + [upgrade/config] Reading configuration from the cluster... + [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml' + [preflight] Running pre-flight checks. + [upgrade] Running cluster health checks + [upgrade/version] You have chosen to change the cluster version to "v1.18.0" + [upgrade/versions] Cluster version: v1.17.3 + [upgrade/versions] kubeadm version: v1.18.0 + [upgrade/confirm] Are you sure you want to proceed with the upgrade? [y/N]: y + [upgrade/prepull] Will prepull images for components [kube-apiserver kube-controller-manager kube-scheduler etcd] + [upgrade/prepull] Prepulling image for component etcd. + [upgrade/prepull] Prepulling image for component kube-apiserver. + [upgrade/prepull] Prepulling image for component kube-controller-manager. + [upgrade/prepull] Prepulling image for component kube-scheduler. + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-controller-manager + [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-etcd + [apiclient] Found 0 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-apiserver + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-etcd + [apiclient] Found 1 Pods for label selector k8s-app=upgrade-prepull-kube-scheduler + [upgrade/prepull] Prepulled image for component etcd. + [upgrade/prepull] Prepulled image for component kube-apiserver. + [upgrade/prepull] Prepulled image for component kube-controller-manager. + [upgrade/prepull] Prepulled image for component kube-scheduler. + [upgrade/prepull] Successfully prepulled the images for all the control plane components + [upgrade/apply] Upgrading your Static Pod-hosted control plane to version "v1.18.0"... + Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46 + Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18 + Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366 + [upgrade/etcd] Upgrading to TLS for etcd + [upgrade/etcd] Non fatal issue encountered during upgrade: the desired etcd version for this Kubernetes version "v1.18.0" is "3.4.3-0", but the current etcd version is "3.4.3". Won't downgrade etcd, instead just continue + [upgrade/staticpods] Writing new Static Pod manifests to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests308527012" + W0308 18:48:14.535122 3082 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC" + [upgrade/staticpods] Preparing for "kube-apiserver" upgrade + [upgrade/staticpods] Renewing apiserver certificate + [upgrade/staticpods] Renewing apiserver-kubelet-client certificate + [upgrade/staticpods] Renewing front-proxy-client certificate + [upgrade/staticpods] Renewing apiserver-etcd-client certificate + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-apiserver.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) + Static pod: kube-apiserver-myhost hash: 2cc222e1a577b40a8c2832320db54b46 + Static pod: kube-apiserver-myhost hash: 609429acb0d71dce6725836dd97d8bf4 + [apiclient] Found 1 Pods for label selector component=kube-apiserver + [upgrade/staticpods] Component "kube-apiserver" upgraded successfully! + [upgrade/staticpods] Preparing for "kube-controller-manager" upgrade + [upgrade/staticpods] Renewing controller-manager.conf certificate + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-controller-manager.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-controller-manager.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) + Static pod: kube-controller-manager-myhost hash: f7ce4bc35cb6e646161578ac69910f18 + Static pod: kube-controller-manager-myhost hash: c7a1232ba2c5dc15641c392662fe5156 + [apiclient] Found 1 Pods for label selector component=kube-controller-manager + [upgrade/staticpods] Component "kube-controller-manager" upgraded successfully! + [upgrade/staticpods] Preparing for "kube-scheduler" upgrade + [upgrade/staticpods] Renewing scheduler.conf certificate + [upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-scheduler.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests-2020-03-08-18-48-14/kube-scheduler.yaml" + [upgrade/staticpods] Waiting for the kubelet to restart the component + [upgrade/staticpods] This might take a minute or longer depending on the component/version gap (timeout 5m0s) + Static pod: kube-scheduler-myhost hash: e3025acd90e7465e66fa19c71b916366 + Static pod: kube-scheduler-myhost hash: b1b721486ae0ac504c160dcdc457ab0d + [apiclient] Found 1 Pods for label selector component=kube-scheduler + [upgrade/staticpods] Component "kube-scheduler" upgraded successfully! + [upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace + [kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster + [kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.18" ConfigMap in the kube-system namespace + [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml" + [bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials + [bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token + [bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster + [addons] Applied essential addon: CoreDNS + [addons] Applied essential addon: kube-proxy + + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.18.0". Enjoy! + + [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. + ``` + +1. CNI 제공자 플러그인을 수동으로 업그레이드한다. + + CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다. + [애드온](/docs/concepts/cluster-administration/addons/) 페이지에서 + 사용하는 CNI 제공자를 찾고 추가 업그레이드 단계가 필요한지 여부를 확인한다. + + CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다. + +1. 컨트롤 플레인 노드에 적용된 cordon을 해제한다. + + ```shell + # 을 컨트롤 플레인 노드 이름으로 바꾼다. + kubectl uncordon + ``` + +### 추가 컨트롤 플레인 노드 업그레이드 + +1. 첫 번째 컨트롤 플레인 노드와 동일하지만 다음을 사용한다. + + ``` + sudo kubeadm upgrade node + ``` + + 아래 명령 대신 위의 명령을 사용한다. + + ``` + sudo kubeadm upgrade apply + ``` + + 또한 `sudo kubeadm upgrade plan` 은 필요하지 않다. + +### kubelet과 kubectl 업그레이드 + +1. 모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다. + + {{< tabs name="k8s_install_kubelet" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \ + apt-mark hold kubelet kubectl + + # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 + apt-get update && \ + apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes + {{% /tab %}} + {{< /tabs >}} + +1. kubelet을 다시 시작한다. + + ```shell + sudo systemctl restart kubelet + ``` + +## 워커 노드 업그레이드 + +워커 노드의 업그레이드 절차는 워크로드를 실행하는 데 필요한 최소 용량을 보장하면서, +한 번에 하나의 노드 또는 한 번에 몇 개의 노드로 실행해야 한다. + +### kubeadm 업그레이드 + +1. 모든 워커 노드에서 kubeadm을 업그레이드한다. + + {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 + apt-mark unhold kubeadm && \ + apt-get update && apt-get install -y kubeadm=1.18.x-00 && \ + apt-mark hold kubeadm + + # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 + apt-get update && \ + apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes + {{% /tab %}} + {{< /tabs >}} + +### 노드 드레인 + +1. 스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다. + + ```shell + # 을 드레이닝하려는 노드 이름으로 바꾼다. + kubectl drain --ignore-daemonsets + ``` + + 다음과 비슷한 출력이 표시되어야 한다. + + ``` + node/ip-172-31-85-18 cordoned + WARNING: ignoring DaemonSet-managed Pods: kube-system/kube-proxy-dj7d7, kube-system/weave-net-z65qx + node/ip-172-31-85-18 drained + ``` + +### kubelet 구성 업그레이드 + +1. 다음의 명령을 호출한다. + + ```shell + sudo kubeadm upgrade node + ``` + +### kubelet과 kubectl 업그레이드 + +1. 모든 워커 노드에서 kubelet 및 kubectl을 업그레이드한다. + + {{< tabs name="k8s_kubelet_and_kubectl" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 && \ + apt-mark hold kubelet kubectl + + # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 + apt-get update && \ + apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes + {{% /tab %}} + {{< /tabs >}} + +1. kubelet을 다시 시작한다. + + ```shell + sudo systemctl restart kubelet + ``` + +### 노드에 적용된 cordon 해제 + +1. 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 만든다. + + ```shell + # 을 노드의 이름으로 바꾼다. + kubectl uncordon + ``` + +## 클러스터 상태 확인 + +모든 노드에서 kubelet을 업그레이드 한 후 kubectl이 클러스터에 접근할 수 있는 곳에서 다음의 명령을 실행하여 모든 노드를 다시 사용할 수 있는지 확인한다. + +```shell +kubectl get nodes +``` + +모든 노드에 대해 `STATUS` 열에 `Ready` 가 표시되어야 하고, 버전 번호가 업데이트되어 있어야 한다. + +{{% /capture %}} + +## 장애 상태에서의 복구 + +예를 들어 `kubeadm upgrade` 를 실행하는 중에 예기치 못한 종료로 인해 업그레이드가 실패하고 롤백하지 않는다면, `kubeadm upgrade` 를 다시 실행할 수 있다. +이 명령은 멱등성을 보장하며 결국 실제 상태가 선언한 의도한 상태인지 확인한다. + +잘못된 상태에서 복구하기 위해, 클러스터가 실행 중인 버전을 변경하지 않고 `kubeadm upgrade apply --force` 를 실행할 수도 있다. + +업그레이드하는 동안 kubeadm은 `/etc/kubernetes/tmp` 아래에 다음과 같은 백업 폴더를 작성한다. + +- `kubeadm-backup-etcd--

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
StringAPI Object
"pods"Pod
"servicesService
"services"Service
"replicationcontrollers"ReplicationController
"resourcequotas"ResourceQuota
"secrets"Secret
--address 0.0.0.0
- - kubelet 的服务 IP 地址（所有 IPv4 接口设置为 0.0.0.0 ，所有 IPv6 接口设置为 “::”）（默认值为 0.0.0.0）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--allowed-unsafe-sysctls strings
- - 设置允许的非安全 sysctls 或 sysctl 模式(以 * 结尾) 白名单。使用此参数，风险自担。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--alsologtostderr
- - 设置为 true 表示将日志输出到文件的同时输出到 stderr -
--anonymous-auth
- - 设置为 true 表示 kubelet 服务器可以接受匿名请求。未被任何认证组件拒绝的请求将被视为匿名请求。匿名请求的用户名为 system:anonymous，用户组为 system:unauthenticated。（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--application-metrics-count-limit int
- - 设置每个容器应用性能度量值存储的个数上限。（默认值为 100）。（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--authentication-token-webhook
- - 使用 TokenReview API 对持有者令牌进行身份认证。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--authentication-token-webhook-cache-ttl duration
- - webhook 令牌认证器返回的响应的缓存时间。（默认值为 2m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--authorization-mode string
- - kubelet 服务器的鉴权模式。可选值包括：AlwaysAllow、Webhook。Webhook 模式使用 SubjectAccessReview API 鉴权。（默认值：“AlwaysAllow”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--authorization-webhook-cache-authorized-ttl duration
- - webhook 认证器所返回的 “己授权” 应答的缓存时间。（默认值为 5m0s）（默认值为 “AlwaysAllow”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--authorization-webhook-cache-unauthorized-ttl duration
- - webhook 认证器所返回的 “未授权” 应答的缓存时间。（默认值为 30s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--azure-container-registry-config string
- - Azure 云上镜像库的配置文件路径。 -
--boot-id-file string
- - 以逗号分隔的文件列表，用于检查引导 id（boot-id）。使用第 1 个存在 boot-id 的文件。（默认值为“/proc/sys/kernel/random/boot_id”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--bootstrap-checkpoint-path string
- - <警告：alpha 功能> 存储检查点的目录的路径 -
--bootstrap-kubeconfig string
- - kubeconfig 文件的路径，该文件将用于获取 kubelet 的客户端证书。如果 --kubeconfig 指定的文件不存在，则使用引导 kubeconfig 从 API 服务器请求客户端证书。成功后，将引用生成的客户端证书和密钥的 kubeconfig 文件写入 --kubeconfig 所指定的路径。客户端证书和密钥文件将存储在 --cert-dir 指向的目录中。 -
--cert-dir string
- - TLS 证书所在的目录。如果设置了 --tls-cert-file 和 --tls-private-key-file，则该设置将被忽略。（默认值为 “/var/lib/kubelet/pki”） -
--cgroup-driver string
- - kubelet 操作本机 cgroup 时使用的驱动程序。支持的选项包括 cgroupfs 或者 systemd（默认值为 cgroupfs）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） - /td> -
--cgroup-root string
- - 为 pod 设置可选的根 cgroup。容器运行时会尽力而为。默认值：‘’，意味着将使用容器运行时的默认设置。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--cgroups-per-qos
- - 启用创建 QoS cgroup 层次结构。此值为 true 时创建顶级的 QoS 和 Pod cgroup。（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--chaos-chance float
- - 如果大于 0.0，则引入随机客户端错误和延迟。用于测试。 -
--client-ca-file string
- - 如果已设置客户端 CA 证书文件，则使用与客户端证书的 CommonName 对应的身份对任何携带 client-ca 文件中的授权机构之一签名的客户端证书的请求进行身份验证。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--cloud-config string
- - 云服务商的配置文件路径。 -
--cloud-provider string
- - 云服务商。设置为空字符串表示在没有云服务商的情况下运行。如果已设置云服务商，则云服务商将确定节点的名称（查阅云提供商文档以确定是否以及如何使用主机名）。 -
--cluster-dns strings
- - 集群内 DNS 服务的 IP 地址，以逗号分隔。仅当 Pod 设置了 “dnsPolicy=ClusterFirst” 属性时可用。注意：列表中出现的所有 DNS 服务器必须包含相同的记录组，否则集群中的名称解析可能无法正常工作。无法保证名称解析过程中会牵涉到哪些 DNS 服务器。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--cluster-domain string
- - 集群的域名。如果设置了此值，除了主机的搜索域外，kubelet 还将配置所有容器以搜索所指定的域名（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/）。 -
--cni-bin-dir string
- - <警告：alpha 功能> 以逗号分隔的目录的完整路径列表，kubelet 将在其中搜索 CNI 插件可执行文件。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。(默认为 “/opt/cni/bin”) -
--cni-cache-dir string
- - <警告：alpha 功能> CNI 用于缓存文件的目录的完整路径。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。(默认为 “/var/lib/cni/cache”) -
--cni-conf-dir string
- - <警告：alpha 功能> 用来搜索 CNI 配置文件的目录的完整路径。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。(默认为 “/etc/cni/net.d”) -
--config string
- - kubelet 将从该文件加载其初始配置。该路径可以是绝对路径，也可以是相对路径。相对路径从 kubelet 的当前工作目录开始。省略此参数则使用内置的默认配置值。命令行参数会覆盖此文件中的配置。 -
--container-hints string
- - 容器提示（hints）文件的位置。（默认值为 “/etc/cadvisor/container_hints.json”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--container-log-max-files int32
- - <警告：beta 功能> 设置容器可以存在的容器日志文件个数上限。此值必须不小于 2。此参数只能与 --container-runtime=remote 参数一起使用。（默认值为 5）。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--container-log-max-size string
- - <警告：beta 功能> 设置容器日志文件在轮转生成新文件时之前的最大值。此参数只能与 --container-runtime=remote 参数一起使用。（默认值为 “10Mi”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--container-runtime string
- - 要使用的容器运行时。目前支持 ‘docker’、‘remote’、‘rkt(已弃用)’。（默认值为 ‘docker’）。 -
--container-runtime-endpoint string
- - [实验性特性] 容器运行时的远程服务端点。目前支持的类型包括 Linux 系统上的 UNIX 套接字、Windows 系统上支持的 npipe 和 TCP 端点。例如：‘unix:///var/run/dockershim.sock’、‘npipe:////./pipe/dockershim’。（默认值为 “unix:///var/run/dockershim.sock”） -
--containerd string
- - 设置 containerd 的端点（默认值为 “/run/containerd/containerd.sock”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--contention-profiling
- - 当启用了性能分析时，启用锁竞争分析（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--cpu-cfs-quota
- - 设置为 true 表示启用 CPU CFS 配额，用于设置容器的 CPU 限制（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--cpu-cfs-quota-period duration
- - 设置 CPU CFS 配额周期，cpu.cfs_period_us。默认使用 Linux 内核所设置的默认值 （默认值为 100ms）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--cpu-manager-policy string
- - 设置 CPU 管理器策略。可选值包括：‘none’ 和 ‘static’。默认值：“none”。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--cpu-manager-reconcile-period NodeStatusUpdateFrequency
- - <警告：alpha 功能> 设置 CPU 管理器的调和时间。例如：‘10s’ 或者 ‘1m’。如果未设置，默认使用 NodeStatusUpdateFrequency 取值（默认值为 10s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--docker string
- - docker 服务的端点地址（默认值为 “unix:///var/run/docker.sock”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--docker-endpoint string
- - docker 端点使用该参数值进行通信。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。(默认为 “unix:///var/run/docker.sock”) -
--docker-env-metadata-whitelist string
- - docker 容器需要使用的以逗号分隔的环境变量键名列表（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--docker-only
- - 设置为 true 表示除了根统计信息外，仅报告 Docker 容器的统计信息（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--docker-root string
- - 已弃用：docker 根目录的路径（备用，默认值：/var/lib/docker）（默认值为 “/var/lib/docker”） -
--docker-tls
- - 使用 TLS 连接 docker。（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--docker-tls-ca string
- - 可信 CA 的路径（默认值为 “ca.pem”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--docker-tls-cert string
- - 客户端证书的路径（默认值为 “cert.pem”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--docker-tls-key string
- - 私钥文件路径（默认值为 “key.pem”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--dynamic-config-dir string
- - 设置 kubelet 使用此目录来保存所下载的配置和跟踪配置运行状况。如果目录不存在，则创建该目录。该路径可以是绝对路径，也可以是相对路径。相对路径从 kubelet 的当前工作目录开始。设置此参数将启用动态 kubelet 配置。必须启用 DynamicKubeletConfig 特性开关才能传递此参数；由于该功能为 beta，此特性开关当前默认为 true。 -
--enable-cadvisor-json-endpoints
- - 启用 cAdvisor JSON 数据的 /spec 和 /stats/* 端点。（默认值为 false）（已弃用：未来版本将会移除该参数） -
--enable-controller-attach-detach
- - 设置为 true 表示启用 Attach/Detach 控制器进行来挂接和摘除调度到该节点的卷，同时禁用 kubelet 执行挂接和摘除操作（默认值为 true） -
--enable-debugging-handlers
- - 设置为 true 表示启用服务器端点进行日志收集和在本地运行容器和命令（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--enable-load-reader
- - 设置为 true 表示启用读取 CPU 负载（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--enable-server
- - 启动 kubelet 服务器（默认值为 true） -
--enforce-node-allocatable stringSlice
- - 用逗号分隔的列表，包含由 kubelet 强制执行的节点可分配资源级别。可选配置为：‘none’、‘pods’、‘system-reserved’ 和 ‘kube-reserved’。在设置 ‘system-reserved’ 和 ‘kube-reserved’ 这两个值时，同时要求设置 ‘--system-reserved-cgroup’ 和 ‘--kube-reserved-cgroup’ 这两个参数。如果设置为 ‘none’，则不需要设置其他参数。更多信息请参考 https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/。（默认值为 pods）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--event-burst int32
- - 突发事件记录的个数上限，在遵从 event-qps 阈值约束的前提下临时允许事件记录达到此数目。仅在 --event-qps 大于 0 时使用（默认值为 10）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--event-qps int32
- - 设置大于 0 的值表示限制每秒可生成的事件数量。设置为 0 表示不限制。（默认值为 5）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--event-storage-age-limit string
- - 不同类型事件的最长保存时间。取值是键值对（key=value）的逗号分隔列表，其中键名是事件类型（例如：creation、oom）或者 “default”，键值是持续时间（duration）。所有未指定的事件类型都使用默认值（默认值为 “default=0”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--event-storage-event-limit string
- - 每种事件类型的最大保存数量。取值是键值对（key=value）的逗号分隔列表，其中键名是事件类型（例如：creation、oom）或者 “default”，键值是一个整数（integer）。所有未指定的事件类型都使用默认值（默认值为 “default=0”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--eviction-hard mapStringString
- - 触发 Pod 驱逐操作的一组硬性门限（例如：memory.available < 1Gi（内存可用值小于 1 G））设置。（默认值为 imagefs.available<15%,memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--eviction-max-pod-grace-period int32
- - 响应满足软驱逐阈值（soft eviction threshold）而终止 Pod 时使用的最长宽限期（以秒为单位）。如果设置为负数，则遵循 Pod 的指定值。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--eviction-minimum-reclaim mapStringString
- - 当本节点压力过大时，kubelet 执行软性驱逐操作。此参数设置软性驱逐操作需要回收的资源的最小数量（例如：imagefs.available=2Gi）。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--eviction-pressure-transition-period duration
- - kubelet 在触发软性 Pod 驱逐操作之前的最长等待时间。（默认值为 5m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--eviction-soft mapStringString
- - 设置一组驱逐阈值（例如：memory.available<1.5Gi）。如果在相应的宽限期内达到该阈值，则会触发软性 Pod 驱逐操作。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--eviction-soft-grace-period mapStringString
- - 设置一组驱逐宽限期，对应于触发软性 Pod 驱逐操作之前软性驱逐阈值所需持续的时间长短。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--exit-on-lock-contention
- - 设置为 true 表示当发生锁文件竞争时 kubelet 可以退出。 -
--experimental-allocatable-ignore-eviction
- - 设置为 true 表示在计算节点可分配资源数量时忽略硬性逐出阈值设置。请参考 https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/。（默认值为 false）。 -
--experimental-bootstrap-kubeconfig string
- - （已弃用：使用 --bootstrap-kubeconfig 参数） -
--experimental-check-node-capabilities-before-mount
- - [实验性特性] 设置为 true 表示 kubelet 在进行挂载卷操作之前对本节点上所需的组件（如可执行文件等）进行检查 -
--experimental-kernel-memcg-notification
- - 设置为 true 表示 kubelet 将会集成内核的 memcg 通知机制而不是使用轮询机制来判断是否达到了内存驱逐阈值。 -
--experimental-mounter-path string
- - [实验性特性] 卷挂载器（mounter）可执行文件的路径。设置为空表示使用默认挂载器 mount。 -
--fail-swap-on
- - 设置为 true 表示如果主机启用了交换分区，kubelet 将无法使用。（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--feature-gates mapStringBool
- - 用于 alpha 实验性质的特性开关组，每个开关以 key=value 形式表示。当前可用开关包括：
APIListChunking=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
AllAlpha=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
AttachVolumeLimit=true|false (BETA - 默认值=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
BlockVolume=true|false (BETA - 默认值=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)
CPUManager=true|false (BETA - 默认值=true)
CRIContainerLogRotation=true|false (BETA - 默认值=true) -
CSIBlockVolume=true|false (BETA - 默认值=true)
CSIDriverRegistry=true|false (BETA - 默认值=true)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (ALPHA - 默认值=false)
CSIMigrationAWS=true|false (ALPHA - 默认值=false)
CSIMigrationAzureDisk=true|false (ALPHA - 默认值=false)
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)
CSIMigrationGCE=true|false (ALPHA - 默认值=false)
CSIMigrationOpenStack=true|false (ALPHA - 默认值=false)
CSINodeInfo=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
CustomResourceDefaulting=true|false (BETA - 默认值=true)
DevicePlugins=true|false (BETA - 默认值=true)
DryRun=true|false (BETA - 默认值=true)
DynamicAuditing=true|false (ALPHA - 默认值=false)
DynamicKubeletConfig=true|false (BETA - 默认值=true)
EndpointSlice=true|false (ALPHA - 默认值=false)
EphemeralContainers=true|false (ALPHA - 默认值=false)
EvenPodsSpread=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
HyperVContainer=true|false (ALPHA - 默认值=false)
IPv6DualStack=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
LegacyNodeRoleBehavior=true|false (ALPHA - 默认值=true)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
MountContainers=true|false (ALPHA - 默认值=false)
NodeDisruptionExclusion=true|false (ALPHA - 默认值=false)
NodeLease=true|false (BETA - 默认值=true)
NonPreemptingPriority=true|false (ALPHA - 默认值=false)
PodOverhead=true|false (ALPHA - 默认值=false)
PodShareProcessNamespace=true|false (BETA - 默认值=true)
ProcMountType=true|false (ALPHA - 默认值=false)br/>QOSReserved=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (ALPHA - 默认值=false)
RequestManagement=true|false (ALPHA - 默认值=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - 默认值=false)
ResourceQuotaScopeSelectors=true|false (BETA - 默认值=true)
RotateKubeletClientCertificate=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
RunAsGroup=true|false (BETA - 默认值=true)
RuntimeClass=true|false (BETA - 默认值=true)
SCTPSupport=true|false (ALPHA - 默认值=false)
ScheduleDaemonSetPods=true|false (BETA - 默认值=true)
ServerSideApply=true|false (BETA - 默认值=true)
ServiceLoadBalancerFinalizer=true|false (BETA - 默认值=true)
ServiceNodeExclusion=true|false (ALPHA - 默认值=false)
StartupProbe=true|false (BETA - 默认值=true)
StorageVersionHash=true|false (BETA - 默认值=true)
StreamingProxyRedirects=true|false (BETA - 默认值=true)
SupportNodePidsLimit=true|false (BETA - 默认值=true)
SupportPodPidsLimit=true|false (BETA - 默认值=true)
Sysctls=true|false (BETA - 默认值=true)
TTLAfterFinished=true|false (ALPHA - 默认值=false)
TaintBasedEvictions=true|false (BETA - 默认值=true)
TaintNodesByCondition=true|false (BETA - 默认值=true)
TokenRequest=true|false (BETA - 默认值=true)
TokenRequestProjection=true|false (BETA - 默认值=true)
TopologyManager=true|false (ALPHA - 默认值=false)
ValidateProxyRedirects=true|false (BETA - 默认值=true)
VolumePVCDataSource=true|false (BETA - 默认值=true)
VolumeSnapshotDataSource=true|false (ALPHA - 默认值=false)
VolumeSubpathEnvExpansion=true|false (BETA - 默认值=true)
WatchBookmark=true|false (BETA - 默认值=true)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (ALPHA - 默认值=false)
WindowsGMSA=true|false (BETA - 默认值=true)
WindowsRunAsUserName=true|false (ALPHA - 默认值=false)（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--file-check-frequency duration
- - 检查配置文件中新数据的时间间隔（默认值为 20s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--global-housekeeping-interval duration
- - 全局资源清理（housekeeping）操作的时间间隔。（默认值为 1m0s）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--hairpin-mode string
- - 设置 kubelet 执行发夹模式（hairpin）网络地址转译的方式。该模式允许后端端点对其自身服务的访问能够再次经由负载均衡转发回自身。可选项包括 “promiscuous-bridge”、“hairpin-veth” 和 “none”。（默认值为 “promiscuous-bridge”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--healthz-bind-address 0.0.0.0
- - 用于运行 healthz 服务器的 IP 地址（对于所有 IPv4 接口，设置为 0.0.0.0；对于所有 IPv6 接口，设置为 `::`）（默认值为 127.0.0.1）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--healthz-port int32
- - 本地 healthz 端点使用的端口（设置为 0 表示禁用）（默认值为 10248）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
-h, --help
- - kubelet 操作的帮助命令 -
--hostname-override string
- - 如果为非空，将使用此字符串而不是实际的主机名作为节点标识。如果设置了 --cloud-provider，则云服务商将确定节点的名称（请查询云服务商文档以确定是否以及如何使用主机名）。 -
--housekeeping-interval duration
- - 清理容器操作的时间间隔（默认值为 10 s） -
--http-check-frequency duration
- - HTTP 服务以获取新数据的时间间隔（默认值为 20 s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--image-gc-high-threshold int32
- - 镜像垃圾回收上限。磁盘使用空间达到该百分比时，镜像垃圾回收将持续工作。值必须在 [0，100] 范围内。要禁用镜像垃圾回收，请设置为 100。（默认值为 85）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--image-gc-low-threshold int32
- - 镜像垃圾回收下限。磁盘使用空间在达到该百分比之前，镜像垃圾回收操作不会运行。值必须在 [0，100] 范围内，并且不得大于 --image-gc-high-threshold 的值。（默认值为 80）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--image-pull-progress-deadline duration
- - 如果在该参数值所设置的期限之前没有拉取镜像的进展，镜像拉取操作将被取消。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。（默认值为 1m0s） -
--image-service-endpoint string
- - [实验性特性] 远程镜像服务的端点。若未设定则默认情况下使用 container-runtime-endpoint 的值。目前支持的类型包括在 Linux 系统上的 UNIX 套接字端点和 Windows 系统上的 npipe 和 TCP 端点。例如：‘unix:///var/run/dockershim.sock’、‘npipe:////./pipe/dockershim’。 -
--iptables-drop-bit int32
- - 标记数据包将被丢弃的 fwmark 位设置。必须在 [0，31] 范围内。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--iptables-masquerade-bit int32
- - 标记数据包将进行 SNAT 的 fwmark 位设置。必须在 [0，31] 范围内。请将此参数与 kube-proxy 中的相应参数匹配。（默认值为 14）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--keep-terminated-pod-volumes
- - 设置为 true 表示 Pod 终止后仍然保留之前挂载过的卷，常用于调试与卷有关的问题。（已弃用：未来版本将会移除该参数） -
--kube-api-burst int32
- - 每秒发送到 apiserver 的请求数量上限（默认值为 10）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--kube-api-content-type string
- - 发送到 apiserver 的请求的内容类型。（默认值为 “application/vnd.kubernetes.protobuf”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--kube-api-qps int32
- - 与 apiserver 通信的每秒查询数（QPS） 值（默认值为 5）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--kube-reserved mapStringString
- - kubernetes 系统预留的资源配置，以一组 ResourceName=ResourceQuantity 格式表示。（例如：cpu=200m,memory=500Mi,ephemeral-storage=1Gi）。当前支持用于根文件系统的 CPU、内存（memory）和本地临时存储。请参阅 http://kubernetes.io/docs/user-guide/compute-resources 获取更多信息。（默认值为 none）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--kube-reserved-cgroup string
- - 给出某个顶层 cgroup 绝对名称，该 cgroup 用于管理带 ‘--kube-reserved’ 标签的 kubernetes 组件的计算资源。例如：‘/kube-reserved’。（默认值为 ‘’）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--kubeconfig string
- - kubeconfig 配置文件的路径，指定如何连接到 API 服务器。提供 --kubeconfig 将启用 API 服务器模式，而省略 --kubeconfig 将启用独立模式。 -
--kubelet-cgroups string
- - 用于创建和运行 kubelet 的 cgroup 的绝对名称。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--lock-file string
- - <警告：alpha 功能> kubelet 使用的锁文件的路径。 -
--log-backtrace-at traceLocation
- - 当日志逻辑执行到命中 file 的第 N 行时，转储调用堆栈（默认值为：0） -
--log-cadvisor-usage
- - 设置为 true 表示将 cAdvisor 容器的使用情况写入日志（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--log-dir string
- - 如果此值为非空，则在所指定的目录中写入日志文件 -
--log-file string
- - 如果此值非空，使用所给字符串作为日志文件名 -
--log-file-max-size uint
- - 定义日志文件的最大值。单位为兆字节（M）。如果值为 0，则最大文件大小表示无限制。（默认值为 1800） -
--log-flush-frequency duration
- - 两次日志刷新之间的最大秒数（默认值为 5s） -
--logtostderr
- - 日志输出到 stderr 而不是文件（默认值为 true） -
--machine-id-file string
- - 以逗号分隔的文件列表，用于检查 machine-id。kubelet 使用存在的第一个 machine-id。（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--make-iptables-util-chains
- - 设置为 true 表示 kubelet 将确保 Iptables 规则在主机上存在。（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--manifest-url string
- - 用于访问要运行的其他 Pod 规范的 URL（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--manifest-url-header --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'
- - 取值为由 HTTP 头部组成的逗号分隔列表，在访问 --manifest-url 所给出的 URL 时使用。名称相同的多个头部将按所列的顺序添加。该参数可以多次使用。例如：--manifest-url-header ‘a:hello,b:again,c:world’ --manifest-url-header ‘b:beautiful’（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--master-service-namespace string
- - kubelet 向 Pod 注入 Kubernetes 主控服务信息时使用的命名空间（默认值为 “default”）（已弃用：此参数将在未来的版本中删除。） -
--max-open-files int
- - kubelet 进程可以打开的最大文件数量（默认值为 1000000）。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--max-pods int32
- - kubelet 能运行的 Pod 最大数量。（默认值为 110）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--maximum-dead-containers int32
- - 设置全局可保留的已停止容器实例个数上限。每个实例会占用一些磁盘空间。要禁用，请设置为负数。（默认值为 -1）（已弃用：请改用 --eviction-hard 或者 --eviction-soft。此参数将在未来的版本中删除。） -
--maximum-dead-containers-per-container int32
- - 可以保留的每个已停止容器的最大实例数量。每个容器占用一些磁盘空间。（默认值为 1）（已弃用：请改用 --eviction-hard 或者 --eviction-soft。此参数将在未来的版本中删除。） -
--minimum-container-ttl-duration duration
- - 已结束的容器在被垃圾回收清理之前的最少存活时间。例如：‘300ms’、‘10s’ 或者 ‘2h45m’（已弃用：请改用 --eviction-hard 或者 --eviction-soft。此参数将在未来的版本中删除。） -
--minimum-image-ttl-duration duration
- - 不再使用的镜像在被垃圾回收清理之前的最少存活时间。例如：‘300ms’、‘10s’ 或者 ‘2h45m’。（默认值为 2m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--network-plugin string
- - <警告：alpha 功能> 设置 kubelet/pod 生命周期中各种事件调用的网络插件的名称。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。 -
--network-plugin-mtu int32
- - <警告：alpha 功能> 传递给网络插件的 MTU 值，将覆盖默认值。设置为 0 则使用默认的 1460 MTU。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。 -
--node-ip string
- - 节点的 IP 地址。如果设置，kubelet 将使用该 IP 地址作为节点的 IP 地址。 -
--node-labels mapStringString
- - <警告：alpha 功能> kubelet 在集群中注册本节点时设置的标签。标签以 key=value 的格式表示，多个标签以逗号分隔。命名空间 ‘kubernetes.io’ 中的标签必须以 kubelet.kubernetes.io 或 node.kubernetes.io 为前缀，或者在以下明确允许范围内（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、failure-domain.kubernetes.io/region、failure-domain.kubernetes.io/zone、kubernetes.io/arch、kubernetes.io/hostname、kubernetes.io/instance-type、kubernetes.io/os） -
--node-status-max-images int32
- - <警告：alpha 功能> 在 Node.Status.Images 中可以报告的最大镜像数量。如果指定为 -1，则不设上限。（默认值为 50） -
--node-status-update-frequency duration
- - 指定 kubelet 向主控节点汇报节点状态的时间间隔。注意：更改此常量时请务必谨慎，它必须与 nodecontroller 中的 nodeMonitorGracePeriod 一起使用。（默认值为 10s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--non-masquerade-cidr string
- - kubelet 向该 IP 段之外的 IP 地址发送的流量将使用 IP 伪装技术。设置为 “0.0.0.0/0” 则不会使用伪装技术。（默认值为 “10.0.0.0/8”）（已弃用：该参数将在未来版本中删除。） -
--oom-score-adj int32
- - kubelet 进程的 oom-score-adj 参数值。有效范围为 [-1000，1000]（默认值为 -999）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--pod-cidr string
- - 用于给 Pod 分配 IP 地址的 CIDR 地址池，仅在单机模式下使用。在集群模式下，CIDR 设置是从主服务器获取的。对于 IPv6，分配的 IP 的最大数量为 65536（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--pod-infra-container-image string
- - 指定基础设施镜像，Pod 内所有容器与其共享网络和 IPC 命名空间。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。（默认值为 “k8s.gcr.io/pause:3.1”） -
--pod-manifest-path string
- - 设置包含要运行的静态 Pod 的文件的路径，或单个静态 Pod 文件的路径。以点（.）开头的文件将被忽略。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--pod-max-pids int
- - 设置每个 Pod 中的最大进程数目。如果为 -1，则 kubelet 使用节点可分配的 PID 容量作为默认值。（默认值为 -1）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--pods-per-core int32
- - kubelet 在每个处理器核上可运行的 Pod 数量。此 kubelet 上的 Pod 总数不能超过 max-pods 值。因此，如果此计算结果导致在 kubelet 上允许更多数量的 Pod，则使用 max-pods 值。值为 0 表示不做限制。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--port int32
- - kubelet 服务监听的本机端口号。（默认值为 10250）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--protect-kernel-defaults
- - 设置 kubelet 的默认内核调整行为。如果已设置该参数，当任何内核可调参数与 kubelet 默认值不同时，kubelet 都会出错。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--provider-id string
- - 设置主机数据库中用来标识节点的唯一标识，即 cloudprovider -
--qos-reserved mapStringString
- - <警告：alpha 功能> 设置在指定的 QoS 级别预留的 Pod 资源请求，以一组 “ResourceName=Percentage（资源名称=百分比）” 的形式进行设置，例如 memory=50%。当前仅支持内存（memory）。要求启用 QOSReserved 特性开关。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--read-only-port int32
- - kubelet 可以在没有身份验证/鉴权的情况下提供只读服务的端口（设置为 0 表示禁用）（默认值为 10255）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--really-crash-for-testing
- - 设置为 true 表示发生内核失效时崩溃。仅用于测试。 -
--redirect-container-streaming
- - 启用容器流数据重定向。如果设置为 false，则 kubelet 将在 apiserver 和容器运行时之间转发容器流数据；如果设置为 true，则 kubelet 将返回指向 apiserver 的 HTTP 重定向指令，而 apiserver 将直接访问容器运行时。代理方法更安全，但会带来一些开销。重定向方法性能更高，但安全性较低，因为 apiserver 和容器运行时之间的连接可能未通过身份验证。 -
--register-node
- - 将本节点注册到 apiserver。如果未提供 --kubeconfig 参数，则此参数无关紧要，因为 kubelet 将没有要注册的 apiserver。（默认值为 true） -
--register-schedulable
- - 注册本节点为可调度的。register-node 为 false 时此设置无效。（默认值为 true）（已弃用：此参数将在未来的版本中删除。） -
--register-with-taints []api.Taint
- - 设置本节点的污点标记，格式为 “<key>=<value>:<effect>” ，以逗号分隔。当 register-node 为 false 时此标志无效。 -
--registry-burst int32
- - 设置突发性镜像拉取的个数上限，在不超过 registration-qps 设置值的前提下暂时允许此参数所给的镜像拉取个数。仅在 --registry-qps 大于 0（默认值为 10）时使用（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--registry-qps int32
- - 如果 --registry-qps 大于 0，用来限制镜像仓库的 QPS 上限。设置为 0，表示不受限制。（默认值为 5）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--resolv-conf string
- - 名字解析服务的配置文件名，用作容器 DNS 解析配置的基础。（默认值为 “/etc/resolv.conf”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--root-dir string
- - 设置用于管理 kubelet 文件的根目录（例如挂载卷的相关文件）（默认值为 “/var/lib/kubelet”） -
--rotate-certificates
- - <警告：alpha 功能> 设置当客户端证书即将过期时 kubelet 自动从 kube-apiserver 请求新的证书进行轮换。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--rotate-server-certificates
- - 当证书即将过期时自动从 kube-apiserver 请求新的证书进行轮换。要求启用 RotateKubeletServerCertificate 特性开关，以及对提交的 CertificateSigningRequest 对象进行批复（approve）操作。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--runonce
- - 设置为 true 表示从本地清单或远程 URL 创建完 Pod 后立即退出 kubelet 进程，与 --enable-server 参数互斥 -
--runtime-cgroups string
- - 设置用于创建和运行容器运行时的 cgroup 的绝对名称。 -
--runtime-request-timeout duration
- - 除了长时间运行的请求（包括 pull、logs、exec 和 attach 等操作），设置其他请求的超时时间。到达超时时间时，请求会被取消，抛出一个错误并会等待重试。（默认值为 2m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--seccomp-profile-root string
- - <警告：alpha 功能> seccomp 配置文件目录。（默认值为 “/var/lib/kubelet/seccomp”） -
--serialize-image-pulls
- - 逐一拉取镜像。建议 *不要* 在 docker 守护进程版本低于 1.9 或启用了 Aufs 存储后端的节点上更改默认值。（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--skip-headers
- - 设置为 true，则在日志消息中去掉标头前缀 -
--skip-log-headers
- - 设置为 true，打开日志文件时去掉标头 -
--stderrthreshold severity
- - 设置严重程度达到或超过此阈值的日志输出到标准错误输出（默认值为 2） -
--storage-driver-buffer-duration duration
- - 设置存储驱动程序中写操作的缓冲时长，超过时长的操作会作为单一事务提交到非内存后端。（默认值为 1m0s）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--storage-driver-db string
- - 后端存储的数据库名称（默认值为 “cadvisor”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--storage-driver-host string
- - 后端存储的数据库连接 URL 地址（默认值为 “localhost:8086”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--storage-driver-password string
- - 后端存储的数据库密码（默认值为 “root”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--storage-driver-secure
- - 后端存储的数据库是否用安全连接（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--storage-driver-table string
- - 后端存储的数据库表名（默认值为 “stats”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--storage-driver-user string
- - 后端存储的数据库用户名（默认值为 “root”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） -
--streaming-connection-idle-timeout duration
- - 设置流连接在自动关闭之前可以空闲的最长时间。0 表示没有超时限制。例如：‘5m’（默认值为 4h0m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--sync-frequency duration
- - 在运行中的容器与其配置之间执行同步操作的最长时间间隔（默认值为 1m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--system-cgroups /
- - cgroup 的绝对名称，用于所有尚未放置在根目录下某 cgroup 内的非内核进程。空值表示不指定 cgroup。回滚该参数需要重启机器。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--system-reserved mapStringString
- - 系统预留的资源配置，以一组 ”ResourceName=ResourceQuantity“ 的格式表示，（例如：cpu=200m,memory=500Mi,ephemeral-storage=1Gi）。目前仅支持 CPU 和内存（memory）的设置。请参考 http://kubernetes.io/docs/user-guide/compute-resources 获取更多信息。（默认值为 ”none“）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--system-reserved-cgroup string
- - 给出一个顶层 cgroup 绝对名称，该 cgroup 用于管理非 kubernetes 组件，这些组件的计算资源通过 ‘--system-reserved’ 标志进行预留。例如 ‘/system-reserved’。（默认值为 ‘’）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--tls-cert-file string
- - 包含 x509 证书的文件路径，用于 HTTPS 认证。如果有中间证书，则中间证书要串接在在服务器证书之后。如果未提供 --tls-cert-file 和 --tls-private-key-file，kubelet 会为公开地址生成自签名证书和密钥，并将其保存到通过 --cert-dir 指定的目录中。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--tls-cipher-suites stringSlice
- - 服务器端加密算法列表，以逗号分隔，如果不设置，则使用 Go 语言加密包的默认算法列表。可选加密算法包括：TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,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_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,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_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA （已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--tls-min-version string
- - 设置支持的最小 TLS 版本号，可选的版本号包括：VersionTLS10、VersionTLS11、VersionTLS12 和 VersionTLS13 （已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--tls-private-key-file string
- - 包含与 --tls-cert-file 对应的 x509 私钥文件路径。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
--topology-manager-policy string
- - 设置拓扑管理策略（Topology Manager policy）。可选值包括：‘none’、‘best-effort’、‘restricted’ 和 ‘single-numa-node’。（默认值为 “none”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
-v, --v Level
- - 设置 kubelet 日志级别详细程度的数值 -
--version version[=true]
- - 打印 kubelet 版本信息并退出 -
--vmodule moduleSpec
- - 以逗号分隔的 pattern=N 设置列表，用于文件过滤的日志记录 -
--volume-plugin-dir string
- - <警告：alpha 功能> 用来搜索第三方存储卷插件的目录（默认值为 “/usr/libexec/kubernetes/kubelet-plugins/volume/exec/”） -
--volume-stats-agg-period duration
- - 指定 kubelet 计算和缓存所有 Pod 和卷的磁盘用量总值的时间间隔。要禁用磁盘用量计算，请设置为 0。（默认值为 1m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） -
++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--add-dir-header
+ +设置为 true 表示添加文件目录到 header 中 +
--address 0.0.0.0
+ +kubelet 的服务 IP 地址（所有 IPv4 接口设置为 0.0.0.0 ，所有 IPv6 接口设置为 “::”）（默认值为 0.0.0.0）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--allowed-unsafe-sysctls strings
+ +设置允许的非安全 sysctls 或 sysctl 模式(以 * 结尾) 白名单。使用此参数，风险自担。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--alsologtostderr
+ +设置为 true 表示将日志输出到文件的同时输出到 stderr +
--anonymous-auth
+ +设置为 true 表示 kubelet 服务器可以接受匿名请求。未被任何认证组件拒绝的请求将被视为匿名请求。匿名请求的用户名为 system:anonymous，用户组为 system:unauthenticated。（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--application-metrics-count-limit int
+ +设置每个容器应用性能度量值存储的个数上限。（默认值为 100）。（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--authentication-token-webhook
+ +使用 TokenReview API 对持有者令牌进行身份认证。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--authentication-token-webhook-cache-ttl duration
+ +webhook 令牌认证器返回的响应的缓存时间。（默认值为 2m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--authorization-mode string
+ +kubelet 服务器的鉴权模式。可选值包括：AlwaysAllow、Webhook。Webhook 模式使用 SubjectAccessReview API 鉴权。（默认值：“AlwaysAllow”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--authorization-webhook-cache-authorized-ttl duration
+ +webhook 认证器所返回的 “己授权” 应答的缓存时间。（默认值为 5m0s）（默认值为 “AlwaysAllow”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--authorization-webhook-cache-unauthorized-ttl duration
+ +webhook 认证器所返回的 “未授权” 应答的缓存时间。（默认值为 30s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--azure-container-registry-config string
+ +Azure 云上镜像库的配置文件路径。 +
--boot-id-file string
+ +以逗号分隔的文件列表，用于检查引导 id（boot-id）。使用第 1 个存在 boot-id 的文件。（默认值为“/proc/sys/kernel/random/boot_id”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--bootstrap-checkpoint-path string
+ +<警告：alpha 功能> 存储检查点的目录的路径 +
--bootstrap-kubeconfig string
+ +kubeconfig 文件的路径，该文件将用于获取 kubelet 的客户端证书。如果 --kubeconfig 指定的文件不存在，则使用引导 kubeconfig 从 API 服务器请求客户端证书。成功后，将引用生成的客户端证书和密钥的 kubeconfig 文件写入 --kubeconfig 所指定的路径。客户端证书和密钥文件将存储在 --cert-dir 指向的目录中。 +
--cert-dir string
+ +TLS 证书所在的目录。如果设置了 --tls-cert-file 和 --tls-private-key-file，则该设置将被忽略。（默认值为 “/var/lib/kubelet/pki”） +
--cgroup-driver string
+ +kubelet 操作本机 cgroup 时使用的驱动程序。支持的选项包括 cgroupfs 或者 systemd（默认值为 cgroupfs）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +/td> +
--cgroup-root string
+ +为 pod 设置可选的根 cgroup。容器运行时会尽力而为。默认值：‘’，意味着将使用容器运行时的默认设置。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--cgroups-per-qos
+ +启用创建 QoS cgroup 层次结构。此值为 true 时创建顶级的 QoS 和 Pod cgroup。（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--chaos-chance float
+ +如果大于 0.0，则引入随机客户端错误和延迟。用于测试。 +
--client-ca-file string
+ +如果已设置客户端 CA 证书文件，则使用与客户端证书的 CommonName 对应的身份对任何携带 client-ca 文件中的授权机构之一签名的客户端证书的请求进行身份验证。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--cloud-config string
+ +云服务商的配置文件路径。 +
--cloud-provider string
+ +云服务商。设置为空字符串表示在没有云服务商的情况下运行。如果已设置云服务商，则云服务商将确定节点的名称（查阅云提供商文档以确定是否以及如何使用主机名）。 +
--cluster-dns strings
+ +集群内 DNS 服务的 IP 地址，以逗号分隔。仅当 Pod 设置了 “dnsPolicy=ClusterFirst” 属性时可用。注意：列表中出现的所有 DNS 服务器必须包含相同的记录组，否则集群中的名称解析可能无法正常工作。无法保证名称解析过程中会牵涉到哪些 DNS 服务器。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--cluster-domain string
+ +集群的域名。如果设置了此值，除了主机的搜索域外，kubelet 还将配置所有容器以搜索所指定的域名（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/）。 +
--cni-bin-dir string
+ +<警告：alpha 功能> 以逗号分隔的目录的完整路径列表，kubelet 将在其中搜索 CNI 插件可执行文件。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。(默认为 “/opt/cni/bin”) +
--cni-cache-dir string
+ +<警告：alpha 功能> CNI 用于缓存文件的目录的完整路径。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。(默认为 “/var/lib/cni/cache”) +
--cni-conf-dir string
+ +<警告：alpha 功能> 用来搜索 CNI 配置文件的目录的完整路径。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。(默认为 “/etc/cni/net.d”) +
--config string
+ +kubelet 将从该文件加载其初始配置。该路径可以是绝对路径，也可以是相对路径。相对路径从 kubelet 的当前工作目录开始。省略此参数则使用内置的默认配置值。命令行参数会覆盖此文件中的配置。 +
--container-hints string
+ +容器提示（hints）文件的位置。（默认值为 “/etc/cadvisor/container_hints.json”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--container-log-max-files int32
+ +<警告：beta 功能> 设置容器可以存在的容器日志文件个数上限。此值必须不小于 2。此参数只能与 --container-runtime=remote 参数一起使用。（默认值为 5）。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--container-log-max-size string
+ +<警告：beta 功能> 设置容器日志文件在轮转生成新文件时之前的最大值。此参数只能与 --container-runtime=remote 参数一起使用。（默认值为 “10Mi”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--container-runtime string
+ +要使用的容器运行时。目前支持 ‘docker’、‘remote’、‘rkt(已弃用)’。（默认值为 ‘docker’）。 +
--container-runtime-endpoint string
+ +[实验性特性] 容器运行时的远程服务端点。目前支持的类型包括 Linux 系统上的 UNIX 套接字、Windows 系统上支持的 npipe 和 TCP 端点。例如：‘unix:///var/run/dockershim.sock’、‘npipe:////./pipe/dockershim’。（默认值为 “unix:///var/run/dockershim.sock”） +
--containerd string
+ +设置 containerd 的端点（默认值为 “/run/containerd/containerd.sock”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--contention-profiling
+ +当启用了性能分析时，启用锁竞争分析（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--cpu-cfs-quota
+ +设置为 true 表示启用 CPU CFS 配额，用于设置容器的 CPU 限制（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--cpu-cfs-quota-period duration
+ +设置 CPU CFS 配额周期，cpu.cfs_period_us。默认使用 Linux 内核所设置的默认值 （默认值为 100ms）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--cpu-manager-policy string
+ +设置 CPU 管理器策略。可选值包括：‘none’ 和 ‘static’。默认值：“none”。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--cpu-manager-reconcile-period NodeStatusUpdateFrequency
+ +<警告：alpha 功能> 设置 CPU 管理器的调和时间。例如：‘10s’ 或者 ‘1m’。如果未设置，默认使用 NodeStatusUpdateFrequency 取值（默认值为 10s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--docker string
+ +docker 服务的端点地址（默认值为 “unix:///var/run/docker.sock”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--docker-endpoint string
+ +docker 端点使用该参数值进行通信。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。(默认为 “unix:///var/run/docker.sock”) +
--docker-env-metadata-whitelist string
+ +docker 容器需要使用的以逗号分隔的环境变量键名列表（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--docker-only
+ +设置为 true 表示除了根统计信息外，仅报告 Docker 容器的统计信息（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--docker-root string
+ +已弃用：docker 根目录的路径（备用，默认值：/var/lib/docker）（默认值为 “/var/lib/docker”） +
--docker-tls
+ +使用 TLS 连接 docker。（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--docker-tls-ca string
+ +可信 CA 的路径（默认值为 “ca.pem”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--docker-tls-cert string
+ +客户端证书的路径（默认值为 “cert.pem”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--docker-tls-key string
+ +私钥文件路径（默认值为 “key.pem”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--dynamic-config-dir string
+ +设置 kubelet 使用此目录来保存所下载的配置和跟踪配置运行状况。如果目录不存在，则创建该目录。该路径可以是绝对路径，也可以是相对路径。相对路径从 kubelet 的当前工作目录开始。设置此参数将启用动态 kubelet 配置。必须启用 DynamicKubeletConfig 特性开关才能传递此参数；由于该功能为 beta，此特性开关当前默认为 true。 +
--enable-cadvisor-json-endpoints
+ +启用 cAdvisor JSON 数据的 /spec 和 /stats/* 端点。（默认值为 false）（已弃用：未来版本将会移除该参数） +
--enable-controller-attach-detach
+ +设置为 true 表示启用 Attach/Detach 控制器进行来挂接和摘除调度到该节点的卷，同时禁用 kubelet 执行挂接和摘除操作（默认值为 true） +
--enable-debugging-handlers
+ +设置为 true 表示启用服务器端点进行日志收集和在本地运行容器和命令（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--enable-load-reader
+ +设置为 true 表示启用读取 CPU 负载（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--enable-server
+ +启动 kubelet 服务器（默认值为 true） +
--enforce-node-allocatable stringSlice
+ +用逗号分隔的列表，包含由 kubelet 强制执行的节点可分配资源级别。可选配置为：‘none’、‘pods’、‘system-reserved’ 和 ‘kube-reserved’。在设置 ‘system-reserved’ 和 ‘kube-reserved’ 这两个值时，同时要求设置 ‘--system-reserved-cgroup’ 和 ‘--kube-reserved-cgroup’ 这两个参数。如果设置为 ‘none’，则不需要设置其他参数。更多信息请参考 https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/。（默认值为 pods）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--event-burst int32
+ +突发事件记录的个数上限，在遵从 event-qps 阈值约束的前提下临时允许事件记录达到此数目。仅在 --event-qps 大于 0 时使用（默认值为 10）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--event-qps int32
+ +设置大于 0 的值表示限制每秒可生成的事件数量。设置为 0 表示不限制。（默认值为 5）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--event-storage-age-limit string
+ +不同类型事件的最长保存时间。取值是键值对（key=value）的逗号分隔列表，其中键名是事件类型（例如：creation、oom）或者 “default”，键值是持续时间（duration）。所有未指定的事件类型都使用默认值（默认值为 “default=0”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--event-storage-event-limit string
+ +每种事件类型的最大保存数量。取值是键值对（key=value）的逗号分隔列表，其中键名是事件类型（例如：creation、oom）或者 “default”，键值是一个整数（integer）。所有未指定的事件类型都使用默认值（默认值为 “default=0”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--eviction-hard mapStringString
+ +触发 Pod 驱逐操作的一组硬性门限（例如：memory.available < 1Gi（内存可用值小于 1 G））设置。（默认值为 imagefs.available<15%,memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--eviction-max-pod-grace-period int32
+ +响应满足软驱逐阈值（soft eviction threshold）而终止 Pod 时使用的最长宽限期（以秒为单位）。如果设置为负数，则遵循 Pod 的指定值。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--eviction-minimum-reclaim mapStringString
+ +当本节点压力过大时，kubelet 执行软性驱逐操作。此参数设置软性驱逐操作需要回收的资源的最小数量（例如：imagefs.available=2Gi）。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--eviction-pressure-transition-period duration
+ +kubelet 在触发软性 Pod 驱逐操作之前的最长等待时间。（默认值为 5m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--eviction-soft mapStringString
+ +设置一组驱逐阈值（例如：memory.available<1.5Gi）。如果在相应的宽限期内达到该阈值，则会触发软性 Pod 驱逐操作。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--eviction-soft-grace-period mapStringString
+ +设置一组驱逐宽限期，对应于触发软性 Pod 驱逐操作之前软性驱逐阈值所需持续的时间长短。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--exit-on-lock-contention
+ +设置为 true 表示当发生锁文件竞争时 kubelet 可以退出。 +
--experimental-allocatable-ignore-eviction
+ +设置为 true 表示在计算节点可分配资源数量时忽略硬性逐出阈值设置。请参考 https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/。（默认值为 false）。 +
--experimental-bootstrap-kubeconfig string
+ +（已弃用：使用 --bootstrap-kubeconfig 参数） +
--experimental-check-node-capabilities-before-mount
+ +[实验性特性] 设置为 true 表示 kubelet 在进行挂载卷操作之前对本节点上所需的组件（如可执行文件等）进行检查 +
--experimental-kernel-memcg-notification
+ +设置为 true 表示 kubelet 将会集成内核的 memcg 通知机制而不是使用轮询机制来判断是否达到了内存驱逐阈值。 +
--experimental-mounter-path string
+ +[实验性特性] 卷挂载器（mounter）可执行文件的路径。设置为空表示使用默认挂载器 mount。 +
--fail-swap-on
+ +设置为 true 表示如果主机启用了交换分区，kubelet 将无法使用。（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--feature-gates mapStringBool
+ +用于 alpha 实验性质的特性开关组，每个开关以 key=value 形式表示。当前可用开关包括：
APIListChunking=true|false (BETA - 默认值=true)
APIResponseCompression=true|false (BETA - 默认值=true)
AllAlpha=true|false (ALPHA - 默认值=false)
AppArmor=true|false (BETA - 默认值=true)
AttachVolumeLimit=true|false (BETA - 默认值=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
BlockVolume=true|false (BETA - 默认值=true)
BoundServiceAccountTokenVolume=true|false (ALPHA - 默认值=false)
CPUManager=true|false (BETA - 默认值=true)
CRIContainerLogRotation=true|false (BETA - 默认值=true) +
CSIBlockVolume=true|false (BETA - 默认值=true)
CSIDriverRegistry=true|false (BETA - 默认值=true)
CSIInlineVolume=true|false (BETA - 默认值=true)
CSIMigration=true|false (ALPHA - 默认值=false)
CSIMigrationAWS=true|false (ALPHA - 默认值=false)
CSIMigrationAzureDisk=true|false (ALPHA - 默认值=false)
CSIMigrationAzureFile=true|false (ALPHA - 默认值=false)
CSIMigrationGCE=true|false (ALPHA - 默认值=false)
CSIMigrationOpenStack=true|false (ALPHA - 默认值=false)
CSINodeInfo=true|false (BETA - 默认值=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
CustomResourceDefaulting=true|false (BETA - 默认值=true)
DevicePlugins=true|false (BETA - 默认值=true)
DryRun=true|false (BETA - 默认值=true)
DynamicAuditing=true|false (ALPHA - 默认值=false)
DynamicKubeletConfig=true|false (BETA - 默认值=true)
EndpointSlice=true|false (ALPHA - 默认值=false)
EphemeralContainers=true|false (ALPHA - 默认值=false)
EvenPodsSpread=true|false (ALPHA - 默认值=false)
ExpandCSIVolumes=true|false (BETA - 默认值=true)
ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
ExpandPersistentVolumes=true|false (BETA - 默认值=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
HPAScaleToZero=true|false (ALPHA - 默认值=false)
HyperVContainer=true|false (ALPHA - 默认值=false)
IPv6DualStack=true|false (ALPHA - 默认值=false)
KubeletPodResources=true|false (BETA - 默认值=true)
LegacyNodeRoleBehavior=true|false (ALPHA - 默认值=true)
LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
MountContainers=true|false (ALPHA - 默认值=false)
NodeDisruptionExclusion=true|false (ALPHA - 默认值=false)
NodeLease=true|false (BETA - 默认值=true)
NonPreemptingPriority=true|false (ALPHA - 默认值=false)
PodOverhead=true|false (ALPHA - 默认值=false)
PodShareProcessNamespace=true|false (BETA - 默认值=true)
ProcMountType=true|false (ALPHA - 默认值=false)br/>QOSReserved=true|false (ALPHA - 默认值=false)
RemainingItemCount=true|false (BETA - 默认值=true)
RemoveSelfLink=true|false (ALPHA - 默认值=false)
RequestManagement=true|false (ALPHA - 默认值=false)
ResourceLimitsPriorityFunction=true|false (ALPHA - 默认值=false)
ResourceQuotaScopeSelectors=true|false (BETA - 默认值=true)
RotateKubeletClientCertificate=true|false (BETA - 默认值=true)
RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
RunAsGroup=true|false (BETA - 默认值=true)
RuntimeClass=true|false (BETA - 默认值=true)
SCTPSupport=true|false (ALPHA - 默认值=false)
ScheduleDaemonSetPods=true|false (BETA - 默认值=true)
ServerSideApply=true|false (BETA - 默认值=true)
ServiceLoadBalancerFinalizer=true|false (BETA - 默认值=true)
ServiceNodeExclusion=true|false (ALPHA - 默认值=false)
StartupProbe=true|false (BETA - 默认值=true)
StorageVersionHash=true|false (BETA - 默认值=true)
StreamingProxyRedirects=true|false (BETA - 默认值=true)
SupportNodePidsLimit=true|false (BETA - 默认值=true)
SupportPodPidsLimit=true|false (BETA - 默认值=true)
Sysctls=true|false (BETA - 默认值=true)
TTLAfterFinished=true|false (ALPHA - 默认值=false)
TaintBasedEvictions=true|false (BETA - 默认值=true)
TaintNodesByCondition=true|false (BETA - 默认值=true)
TokenRequest=true|false (BETA - 默认值=true)
TokenRequestProjection=true|false (BETA - 默认值=true)
TopologyManager=true|false (ALPHA - 默认值=false)
ValidateProxyRedirects=true|false (BETA - 默认值=true)
VolumePVCDataSource=true|false (BETA - 默认值=true)
VolumeSnapshotDataSource=true|false (ALPHA - 默认值=false)
VolumeSubpathEnvExpansion=true|false (BETA - 默认值=true)
WatchBookmark=true|false (BETA - 默认值=true)
WinDSR=true|false (ALPHA - 默认值=false)
WinOverlay=true|false (ALPHA - 默认值=false)
WindowsGMSA=true|false (BETA - 默认值=true)
WindowsRunAsUserName=true|false (ALPHA - 默认值=false)（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--file-check-frequency duration
+ +检查配置文件中新数据的时间间隔（默认值为 20s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--global-housekeeping-interval duration
+ +全局资源清理（housekeeping）操作的时间间隔。（默认值为 1m0s）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--hairpin-mode string
+ +设置 kubelet 执行发夹模式（hairpin）网络地址转译的方式。该模式允许后端端点对其自身服务的访问能够再次经由负载均衡转发回自身。可选项包括 “promiscuous-bridge”、“hairpin-veth” 和 “none”。（默认值为 “promiscuous-bridge”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--healthz-bind-address 0.0.0.0
+ +用于运行 healthz 服务器的 IP 地址（对于所有 IPv4 接口，设置为 0.0.0.0；对于所有 IPv6 接口，设置为 `::`）（默认值为 127.0.0.1）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--healthz-port int32
+ +本地 healthz 端点使用的端口（设置为 0 表示禁用）（默认值为 10248）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
-h, --help
+ +kubelet 操作的帮助命令 +
--hostname-override string
+ +如果为非空，将使用此字符串而不是实际的主机名作为节点标识。如果设置了 --cloud-provider，则云服务商将确定节点的名称（请查询云服务商文档以确定是否以及如何使用主机名）。 +
--housekeeping-interval duration
+ +清理容器操作的时间间隔（默认值为 10 s） +
--http-check-frequency duration
+ +HTTP 服务以获取新数据的时间间隔（默认值为 20 s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--image-gc-high-threshold int32
+ +镜像垃圾回收上限。磁盘使用空间达到该百分比时，镜像垃圾回收将持续工作。值必须在 [0，100] 范围内。要禁用镜像垃圾回收，请设置为 100。（默认值为 85）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--image-gc-low-threshold int32
+ +镜像垃圾回收下限。磁盘使用空间在达到该百分比之前，镜像垃圾回收操作不会运行。值必须在 [0，100] 范围内，并且不得大于 --image-gc-high-threshold 的值。（默认值为 80）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--image-pull-progress-deadline duration
+ +如果在该参数值所设置的期限之前没有拉取镜像的进展，镜像拉取操作将被取消。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。（默认值为 1m0s） +
--image-service-endpoint string
+ +[实验性特性] 远程镜像服务的端点。若未设定则默认情况下使用 container-runtime-endpoint 的值。目前支持的类型包括在 Linux 系统上的 UNIX 套接字端点和 Windows 系统上的 npipe 和 TCP 端点。例如：‘unix:///var/run/dockershim.sock’、‘npipe:////./pipe/dockershim’。 +
--iptables-drop-bit int32
+ +标记数据包将被丢弃的 fwmark 位设置。必须在 [0，31] 范围内。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--iptables-masquerade-bit int32
+ +标记数据包将进行 SNAT 的 fwmark 位设置。必须在 [0，31] 范围内。请将此参数与 kube-proxy 中的相应参数匹配。（默认值为 14）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--keep-terminated-pod-volumes
+ +设置为 true 表示 Pod 终止后仍然保留之前挂载过的卷，常用于调试与卷有关的问题。（已弃用：未来版本将会移除该参数） +
--kube-api-burst int32
+ +每秒发送到 apiserver 的请求数量上限（默认值为 10）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--kube-api-content-type string
+ +发送到 apiserver 的请求的内容类型。（默认值为 “application/vnd.kubernetes.protobuf”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--kube-api-qps int32
+ +与 apiserver 通信的每秒查询数（QPS） 值（默认值为 5）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--kube-reserved mapStringString
+ +kubernetes 系统预留的资源配置，以一组 ResourceName=ResourceQuantity 格式表示。（例如：cpu=200m,memory=500Mi,ephemeral-storage=1Gi）。当前支持用于根文件系统的 CPU、内存（memory）和本地临时存储。请参阅 http://kubernetes.io/docs/user-guide/compute-resources 获取更多信息。（默认值为 none）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--kube-reserved-cgroup string
+ +给出某个顶层 cgroup 绝对名称，该 cgroup 用于管理带 ‘--kube-reserved’ 标签的 kubernetes 组件的计算资源。例如：‘/kube-reserved’。（默认值为 ‘’）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--kubeconfig string
+ +kubeconfig 配置文件的路径，指定如何连接到 API 服务器。提供 --kubeconfig 将启用 API 服务器模式，而省略 --kubeconfig 将启用独立模式。 +
--kubelet-cgroups string
+ +用于创建和运行 kubelet 的 cgroup 的绝对名称。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--lock-file string
+ +<警告：alpha 功能> kubelet 使用的锁文件的路径。 +
--log-backtrace-at traceLocation
+ +当日志逻辑执行到命中 file 的第 N 行时，转储调用堆栈（默认值为：0） +
--log-cadvisor-usage
+ +设置为 true 表示将 cAdvisor 容器的使用情况写入日志（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--log-dir string
+ +如果此值为非空，则在所指定的目录中写入日志文件 +
--log-file string
+ +如果此值非空，使用所给字符串作为日志文件名 +
--log-file-max-size uint
+ +定义日志文件的最大值。单位为兆字节（M）。如果值为 0，则最大文件大小表示无限制。（默认值为 1800） +
--log-flush-frequency duration
+ +两次日志刷新之间的最大秒数（默认值为 5s） +
--logtostderr
+ +日志输出到 stderr 而不是文件（默认值为 true） +
--machine-id-file string
+ +以逗号分隔的文件列表，用于检查 machine-id。kubelet 使用存在的第一个 machine-id。（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--make-iptables-util-chains
+ +设置为 true 表示 kubelet 将确保 Iptables 规则在主机上存在。（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--manifest-url string
+ +用于访问要运行的其他 Pod 规范的 URL（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--manifest-url-header --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'
+ +取值为由 HTTP 头部组成的逗号分隔列表，在访问 --manifest-url 所给出的 URL 时使用。名称相同的多个头部将按所列的顺序添加。该参数可以多次使用。例如：--manifest-url-header ‘a:hello,b:again,c:world’ --manifest-url-header ‘b:beautiful’（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--master-service-namespace string
+ +kubelet 向 Pod 注入 Kubernetes 主控服务信息时使用的命名空间（默认值为 “default”）（已弃用：此参数将在未来的版本中删除。） +
--max-open-files int
+ +kubelet 进程可以打开的最大文件数量（默认值为 1000000）。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--max-pods int32
+ +kubelet 能运行的 Pod 最大数量。（默认值为 110）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--maximum-dead-containers int32
+ +设置全局可保留的已停止容器实例个数上限。每个实例会占用一些磁盘空间。要禁用，请设置为负数。（默认值为 -1）（已弃用：请改用 --eviction-hard 或者 --eviction-soft。此参数将在未来的版本中删除。） +
--maximum-dead-containers-per-container int32
+ +可以保留的每个已停止容器的最大实例数量。每个容器占用一些磁盘空间。（默认值为 1）（已弃用：请改用 --eviction-hard 或者 --eviction-soft。此参数将在未来的版本中删除。） +
--minimum-container-ttl-duration duration
+ +已结束的容器在被垃圾回收清理之前的最少存活时间。例如：‘300ms’、‘10s’ 或者 ‘2h45m’（已弃用：请改用 --eviction-hard 或者 --eviction-soft。此参数将在未来的版本中删除。） +
--minimum-image-ttl-duration duration
+ +不再使用的镜像在被垃圾回收清理之前的最少存活时间。例如：‘300ms’、‘10s’ 或者 ‘2h45m’。（默认值为 2m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--network-plugin string
+ +<警告：alpha 功能> 设置 kubelet/pod 生命周期中各种事件调用的网络插件的名称。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。 +
--network-plugin-mtu int32
+ +<警告：alpha 功能> 传递给网络插件的 MTU 值，将覆盖默认值。设置为 0 则使用默认的 1460 MTU。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。 +
--node-ip string
+ +节点的 IP 地址。如果设置，kubelet 将使用该 IP 地址作为节点的 IP 地址。 +
--node-labels mapStringString
+ +<警告：alpha 功能> kubelet 在集群中注册本节点时设置的标签。标签以 key=value 的格式表示，多个标签以逗号分隔。命名空间 ‘kubernetes.io’ 中的标签必须以 kubelet.kubernetes.io 或 node.kubernetes.io 为前缀，或者在以下明确允许范围内（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、failure-domain.kubernetes.io/region、failure-domain.kubernetes.io/zone、kubernetes.io/arch、kubernetes.io/hostname、kubernetes.io/instance-type、kubernetes.io/os） +
--node-status-max-images int32
+ +<警告：alpha 功能> 在 Node.Status.Images 中可以报告的最大镜像数量。如果指定为 -1，则不设上限。（默认值为 50） +
--node-status-update-frequency duration
+ +指定 kubelet 向主控节点汇报节点状态的时间间隔。注意：更改此常量时请务必谨慎，它必须与 nodecontroller 中的 nodeMonitorGracePeriod 一起使用。（默认值为 10s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--non-masquerade-cidr string
+ +kubelet 向该 IP 段之外的 IP 地址发送的流量将使用 IP 伪装技术。设置为 “0.0.0.0/0” 则不会使用伪装技术。（默认值为 “10.0.0.0/8”）（已弃用：该参数将在未来版本中删除。） +
--oom-score-adj int32
+ +kubelet 进程的 oom-score-adj 参数值。有效范围为 [-1000，1000]（默认值为 -999）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--pod-cidr string
+ +用于给 Pod 分配 IP 地址的 CIDR 地址池，仅在单机模式下使用。在集群模式下，CIDR 设置是从主服务器获取的。对于 IPv6，分配的 IP 的最大数量为 65536（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--pod-infra-container-image string
+ +指定基础设施镜像，Pod 内所有容器与其共享网络和 IPC 命名空间。仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。（默认值为 “k8s.gcr.io/pause:3.1”） +
--pod-manifest-path string
+ +设置包含要运行的静态 Pod 的文件的路径，或单个静态 Pod 文件的路径。以点（.）开头的文件将被忽略。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--pod-max-pids int
+ +设置每个 Pod 中的最大进程数目。如果为 -1，则 kubelet 使用节点可分配的 PID 容量作为默认值。（默认值为 -1）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--pods-per-core int32
+ +kubelet 在每个处理器核上可运行的 Pod 数量。此 kubelet 上的 Pod 总数不能超过 max-pods 值。因此，如果此计算结果导致在 kubelet 上允许更多数量的 Pod，则使用 max-pods 值。值为 0 表示不做限制。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--port int32
+ +kubelet 服务监听的本机端口号。（默认值为 10250）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--protect-kernel-defaults
+ +设置 kubelet 的默认内核调整行为。如果已设置该参数，当任何内核可调参数与 kubelet 默认值不同时，kubelet 都会出错。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--provider-id string
+ +设置主机数据库中用来标识节点的唯一标识，即 cloudprovider +
--qos-reserved mapStringString
+ +<警告：alpha 功能> 设置在指定的 QoS 级别预留的 Pod 资源请求，以一组 “ResourceName=Percentage（资源名称=百分比）” 的形式进行设置，例如 memory=50%。当前仅支持内存（memory）。要求启用 QOSReserved 特性开关。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--read-only-port int32
+ +kubelet 可以在没有身份验证/鉴权的情况下提供只读服务的端口（设置为 0 表示禁用）（默认值为 10255）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--really-crash-for-testing
+ +设置为 true 表示发生内核失效时崩溃。仅用于测试。 +
--redirect-container-streaming
+ +启用容器流数据重定向。如果设置为 false，则 kubelet 将在 apiserver 和容器运行时之间转发容器流数据；如果设置为 true，则 kubelet 将返回指向 apiserver 的 HTTP 重定向指令，而 apiserver 将直接访问容器运行时。代理方法更安全，但会带来一些开销。重定向方法性能更高，但安全性较低，因为 apiserver 和容器运行时之间的连接可能未通过身份验证。 +
--register-node
+ +将本节点注册到 apiserver。如果未提供 --kubeconfig 参数，则此参数无关紧要，因为 kubelet 将没有要注册的 apiserver。（默认值为 true） +
--register-schedulable
+ +注册本节点为可调度的。register-node 为 false 时此设置无效。（默认值为 true）（已弃用：此参数将在未来的版本中删除。） +
--register-with-taints []api.Taint
+ +设置本节点的污点标记，格式为 “<key>=<value>:<effect>” ，以逗号分隔。当 register-node 为 false 时此标志无效。 +
--registry-burst int32
+ +设置突发性镜像拉取的个数上限，在不超过 registration-qps 设置值的前提下暂时允许此参数所给的镜像拉取个数。仅在 --registry-qps 大于 0（默认值为 10）时使用（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--registry-qps int32
+ +如果 --registry-qps 大于 0，用来限制镜像仓库的 QPS 上限。设置为 0，表示不受限制。（默认值为 5）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--resolv-conf string
+ +名字解析服务的配置文件名，用作容器 DNS 解析配置的基础。（默认值为 “/etc/resolv.conf”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--root-dir string
+ +设置用于管理 kubelet 文件的根目录（例如挂载卷的相关文件）（默认值为 “/var/lib/kubelet”） +
--rotate-certificates
+ +<警告：alpha 功能> 设置当客户端证书即将过期时 kubelet 自动从 kube-apiserver 请求新的证书进行轮换。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--rotate-server-certificates
+ +当证书即将过期时自动从 kube-apiserver 请求新的证书进行轮换。要求启用 RotateKubeletServerCertificate 特性开关，以及对提交的 CertificateSigningRequest 对象进行批复（approve）操作。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--runonce
+ +设置为 true 表示从本地清单或远程 URL 创建完 Pod 后立即退出 kubelet 进程，与 --enable-server 参数互斥 +
--runtime-cgroups string
+ +设置用于创建和运行容器运行时的 cgroup 的绝对名称。 +
--runtime-request-timeout duration
+ +除了长时间运行的请求（包括 pull、logs、exec 和 attach 等操作），设置其他请求的超时时间。到达超时时间时，请求会被取消，抛出一个错误并会等待重试。（默认值为 2m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--seccomp-profile-root string
+ +<警告：alpha 功能> seccomp 配置文件目录。（默认值为 “/var/lib/kubelet/seccomp”） +
--serialize-image-pulls
+ +逐一拉取镜像。建议 *不要* 在 docker 守护进程版本低于 1.9 或启用了 Aufs 存储后端的节点上更改默认值。（默认值为 true）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--skip-headers
+ +设置为 true，则在日志消息中去掉标头前缀 +
--skip-log-headers
+ +设置为 true，打开日志文件时去掉标头 +
--stderrthreshold severity
+ +设置严重程度达到或超过此阈值的日志输出到标准错误输出（默认值为 2） +
--storage-driver-buffer-duration duration
+ +设置存储驱动程序中写操作的缓冲时长，超过时长的操作会作为单一事务提交到非内存后端。（默认值为 1m0s）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--storage-driver-db string
+ +后端存储的数据库名称（默认值为 “cadvisor”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--storage-driver-host string
+ +后端存储的数据库连接 URL 地址（默认值为 “localhost:8086”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--storage-driver-password string
+ +后端存储的数据库密码（默认值为 “root”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--storage-driver-secure
+ +后端存储的数据库是否用安全连接（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--storage-driver-table string
+ +后端存储的数据库表名（默认值为 “stats”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--storage-driver-user string
+ +后端存储的数据库用户名（默认值为 “root”）（已弃用：这是一个错误地在 kubelet 中注册的 cadvisor 参数。由于遗留问题，在删除之前，它将遵循标准的 CLI 弃用时间表。） +
--streaming-connection-idle-timeout duration
+ +设置流连接在自动关闭之前可以空闲的最长时间。0 表示没有超时限制。例如：‘5m’（默认值为 4h0m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--sync-frequency duration
+ +在运行中的容器与其配置之间执行同步操作的最长时间间隔（默认值为 1m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--system-cgroups /
+ +cgroup 的绝对名称，用于所有尚未放置在根目录下某 cgroup 内的非内核进程。空值表示不指定 cgroup。回滚该参数需要重启机器。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--system-reserved mapStringString
+ +系统预留的资源配置，以一组 ”ResourceName=ResourceQuantity“ 的格式表示，（例如：cpu=200m,memory=500Mi,ephemeral-storage=1Gi）。目前仅支持 CPU 和内存（memory）的设置。请参考 http://kubernetes.io/docs/user-guide/compute-resources 获取更多信息。（默认值为 ”none“）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--system-reserved-cgroup string
+ +给出一个顶层 cgroup 绝对名称，该 cgroup 用于管理非 kubernetes 组件，这些组件的计算资源通过 ‘--system-reserved’ 标志进行预留。例如 ‘/system-reserved’。（默认值为 ‘’）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--tls-cert-file string
+ +包含 x509 证书的文件路径，用于 HTTPS 认证。如果有中间证书，则中间证书要串接在在服务器证书之后。如果未提供 --tls-cert-file 和 --tls-private-key-file，kubelet 会为公开地址生成自签名证书和密钥，并将其保存到通过 --cert-dir 指定的目录中。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--tls-cipher-suites stringSlice
+ +服务器端加密算法列表，以逗号分隔，如果不设置，则使用 Go 语言加密包的默认算法列表。可选加密算法包括：TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,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_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,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_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA （已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--tls-min-version string
+ +设置支持的最小 TLS 版本号，可选的版本号包括：VersionTLS10、VersionTLS11、VersionTLS12 和 VersionTLS13 （已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--tls-private-key-file string
+ +包含与 --tls-cert-file 对应的 x509 私钥文件路径。（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
--topology-manager-policy string
+ +设置拓扑管理策略（Topology Manager policy）。可选值包括：‘none’、‘best-effort’、‘restricted’ 和 ‘single-numa-node’。（默认值为 “none”）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
-v, --v Level
+ +设置 kubelet 日志级别详细程度的数值 +
--version version[=true]
+ +打印 kubelet 版本信息并退出 +
--vmodule moduleSpec
+ +以逗号分隔的 pattern=N 设置列表，用于文件过滤的日志记录 +
--volume-plugin-dir string
+ +<警告：alpha 功能> 用来搜索第三方存储卷插件的目录（默认值为 “/usr/libexec/kubernetes/kubelet-plugins/volume/exec/”） +
--volume-stats-agg-period duration
+ +指定 kubelet 计算和缓存所有 Pod 和卷的磁盘用量总值的时间间隔。要禁用磁盘用量计算，请设置为 0。（默认值为 1m0s）（已弃用：在 --config 指定的配置文件中进行设置。有关更多信息，请参阅 https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/。） +
{{% /capture %}} diff --git a/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md index 74790f03c9..aeec416870 100644 --- a/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -100,7 +100,7 @@ spec: - -command - "<#code used from https://gist.github.com/wagnerandrade/5424431#> ; $$listener = New-Object System.Net.HttpListener ; $$listener.Prefixes.Add('http://*:80/') ; $$listener.Start() ; $$callerCounts = @{} ; Write-Host('Listening at http://*:80/') ; while ($$listener.IsListening) { ;$$context = $$listener.GetContext() ;$$requestUrl = $$context.Request.Url ;$$clientIP = $$context.Request.RemoteEndPoint.Address ;$$response = $$context.Response ;Write-Host '' ;Write-Host('> {0}' -f $$requestUrl) ; ;$$count = 1 ;$$k=$$callerCounts.Get_Item($$clientIP) ;if ($$k -ne $$null) { $$count += $$k } ;$$callerCounts.Set_Item($$clientIP, $$count) ;$$ip=(Get-NetAdapter | Get-NetIpAddress); $$header='

Windows Container Web Server

' ;$$callerCountsString='' ;$$callerCounts.Keys | % { $$callerCountsString+='

IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; " nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows ``` {{< note >}} diff --git a/content/zh/docs/tasks/administer-cluster/quota-api-object.md b/content/zh/docs/tasks/administer-cluster/quota-api-object.md index 67249bd075..298ef459e5 100644 --- a/content/zh/docs/tasks/administer-cluster/quota-api-object.md +++ b/content/zh/docs/tasks/administer-cluster/quota-api-object.md @@ -196,7 +196,7 @@ by quotas: - + diff --git a/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md b/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md index 58458b5fa1..429e5e6c4e 100644 --- a/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md +++ b/content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md @@ -61,7 +61,7 @@ API, `metrics.k8s.io`) is running, type the following command: 查看是 metrics-server（或者其他资源度量 API 服务提供者，`metrics.k8s.io` ）是否正在运行，请键入以下命令： ```shell -kubectl get API services +kubectl get apiservices ``` 此示例的输出，显示 Pod 使用的是974 milliCPU，即仅略低于 Pod 配置中指定的 1 个 CPU 的限制。 ``` -NAME CPU (cores) MEMORY(bytes) - CPU -demo 974m +NAME CPU(cores) MEMORY(bytes) +cpu-demo 974m ``` ### Web 网上的静态 Pod 声明文件 {#pods-created-via-http} @@ -262,7 +262,7 @@ The output might be something like: 当 kubelet 启动时，会自动启动所有定义的静态 Pod。当定义了一个静态 Pod 并重新启动 kubelet 时，新的静态 Pod 就应该已经在运行了。 -可以在节点上云心下面的命令来看运行的容器（包括静态 Pod）： +可以在节点上运行下面的命令来查看正在运行的容器（包括静态 Pod）： ```shell # 在 kubelet 运行的节点上执行以下命令 docker ps @@ -378,7 +378,7 @@ docker ps --> ## 动态增加和删除静态 pod -运行的 kubelet 定期扫描配置的目录(比如例子中的 `/etc/kubelet.d` 目录)中的变化，并且根据文件中出现/消失的 Pod 来添加/删除 Pod。 +运行中的 kubelet 会定期扫描配置的目录(比如例子中的 `/etc/kubelet.d` 目录)中的变化，并且根据文件中出现/消失的 Pod 来添加/删除 Pod。 ```shell # 前提是你在用主机文件系统上的静态 Pod 配置文件 diff --git a/content/zh/docs/tasks/debug-application-cluster/falco.md b/content/zh/docs/tasks/debug-application-cluster/falco.md new file mode 100644 index 0000000000..8c07c5e641 --- /dev/null +++ b/content/zh/docs/tasks/debug-application-cluster/falco.md @@ -0,0 +1,239 @@ +--- +reviewers: +- soltysh +- sttts +- ericchiang +content_template: templates/concept +title: 使用 Falco 审计 +--- + +{{% capture overview %}} + +### 使用 Falco 采集审计事件 + + +[Falco](https://falco.org/)是一个开源项目，用于为云原生平台提供入侵和异常检测。本节介绍如何设置 Falco、如何将审计事件发送到 Falco 公开的 Kubernetes Audit 端点、以及 Falco 如何应用一组规则来自动检测可疑行为。 + +{{% /capture %}} + +{{% capture body %}} + + +#### 安装 Falco + + +使用以下方法安装 Falco ： + + +- [独立安装 Falco][falco_installation] +- [Kubernetes DaemonSet][falco_installation] +- [Falco Helm Chart][falco_helm_chart] + + +安装完成 Falco 后，请确保将其配置为公开 Audit Webhook。为此，请使用以下配置： + +```yaml +webserver: + enabled: true + listen_port: 8765 + k8s_audit_endpoint: /k8s_audit + ssl_enabled: false + ssl_certificate: /etc/falco/falco.pem +``` + + +此配置通常位于 `/etc/falco/falco.yaml` 文件中。如果 Falco 作为 Kubernetes DaemonSet 安装，请编辑 `falco-config` ConfigMap 并添加此配置。 + +#### 配置 Kubernetes 审计 + + +1. 为 [kube-apiserver][kube-apiserver] webhook 审计后端创建一个[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)文件。 + + cat < /etc/kubernetes/audit-webhook-kubeconfig + apiVersion: v1 + kind: Config + clusters: + - cluster: + server: http://:8765/k8s_audit + name: falco + contexts: + - context: + cluster: falco + user: "" + name: default-context + current-context: default-context + preferences: {} + users: [] + EOF + +2. 使用以下选项启动 [kube-apiserver][kube-apiserver]： + + ```shell + --audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig + ``` + +#### 审计规则 + + + +专门用于 Kubernetes 审计事件的规则可以在 [k8s_audit_rules.yaml][falco_k8s_audit_rules] 中找到。如果审计规则是作为本机软件包安装或使用官方 Docker 镜像安装的，则 Falco 会将规则文件复制到 `/etc/falco/` 中以便使用。 + +共有三类规则。 + +第一类规则用于查找可疑或异常活动，例如： + + +-未经授权或匿名用户的任何活动。 +-创建使用未知或不允许的镜像的 pod。 +-创建特权 Pod，从主机安装敏感文件系统的 Pod 或使用主机网络的 Pod。 +-创建 NodePort 服务。 +-创建包含私有证书（例如密码和云提供商 secrets ）的 ConfigMap。 +-在正在运行的 Pod 上附加或执行命令。 +-在一组允许的名称空间之外创建一个名称空间。 +-在 kube-system 或 kube-public 命名空间中创建 pod 或服务帐户。 +-尝试修改或删除系统 ClusterRole。 +-创建一个 ClusterRoleBinding 到 cluster-admin 角色。 +-创建 ClusterRole 时在动词或资源中使用通配符。 例如，过度赋权。 +-创建具有写权限的 ClusterRole 或可以在 Pod 上执行命令的 ClusterRole。 + + +第二类规则跟踪正在创建或销毁的资源，包括： + +- Deployments +- Services +- ConfigMaps +- Namespaces +- Service accounts +- Role/ClusterRoles +- Role/ClusterRoleBindings + + + +最后一类规则仅负责显示 Falco 收到的所有审核事件。默认情况下，此规则是禁用的，因为它可能会很吵。 + +有关更多详细信息，请参阅 Falco 文档中的[Kubernetes审计事件][falco_ka_docs]。 + + +[kube-apiserver]: /docs/admin/kube-apiserver +[auditing-proposal]: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/auditing.md +[auditing-api]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go +[gce-audit-profile]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh#L735 +[kubeconfig]: /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ +[fluentd]: http://www.fluentd.org/ +[fluentd_install_doc]: https://docs.fluentd.org/v1.0/articles/quickstart#step-1:-installing-fluentd +[fluentd_plugin_management_doc]: https://docs.fluentd.org/v1.0/articles/plugin-management +[logstash]: https://www.elastic.co/products/logstash +[logstash_install_doc]: https://www.elastic.co/guide/en/logstash/current/installing-logstash.html +[kube-aggregator]: /docs/concepts/api-extension/apiserver-aggregation +[falco_website]: https://www.falco.org +[falco_k8s_audit_rules]: https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml +[falco_ka_docs]: https://falco.org/docs/event-sources/kubernetes-audit +[falco_installation]: https://falco.org/docs/installation +[falco_helm_chart]: https://github.com/helm/charts/tree/master/stable/falco + +{{% /capture %}} diff --git a/content/zh/docs/tasks/tools/install-kubectl.md b/content/zh/docs/tasks/tools/install-kubectl.md index fc6ebea985..e8fff91758 100644 --- a/content/zh/docs/tasks/tools/install-kubectl.md +++ b/content/zh/docs/tasks/tools/install-kubectl.md @@ -498,7 +498,7 @@ kubectl 可以作为 Google Cloud SDK 的一部分进行安装。 {{% tab name="Windows" %}} 1. 从[本链接](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)下载 kubectl 的最新版 {{< param "fullversion" >}}。 - 或者如果您已经在系统中安装了 `curl` 工具，也可以通过以下命令下载： + 或者如果您已经在系统中安装了 `curl` 工具，也可以通过以下命令下载： ``` curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe diff --git a/content/zh/examples/windows/configmap-pod.yaml b/content/zh/examples/windows/configmap-pod.yaml index e30939b367..661cb73dee 100644 --- a/content/zh/examples/windows/configmap-pod.yaml +++ b/content/zh/examples/windows/configmap-pod.yaml @@ -28,4 +28,4 @@ spec: name: example-config key: example.property.2 nodeSelector: - beta.kubernetes.io/os: windows \ No newline at end of file + kubernetes.io/os: windows \ No newline at end of file diff --git a/content/zh/examples/windows/daemonset.yaml b/content/zh/examples/windows/daemonset.yaml index d3a7bb6636..7483708fc7 100644 --- a/content/zh/examples/windows/daemonset.yaml +++ b/content/zh/examples/windows/daemonset.yaml @@ -17,5 +17,5 @@ spec: - name: foo image: microsoft/windowsservercore:1709 nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows diff --git a/content/zh/examples/windows/emptydir-pod.yaml b/content/zh/examples/windows/emptydir-pod.yaml index e164f2caeb..08d8091391 100644 --- a/content/zh/examples/windows/emptydir-pod.yaml +++ b/content/zh/examples/windows/emptydir-pod.yaml @@ -17,4 +17,4 @@ spec: - name: scratch-volume emptyDir: {} nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows diff --git a/content/zh/examples/windows/hostpath-volume-pod.yaml b/content/zh/examples/windows/hostpath-volume-pod.yaml index 843250c80c..d95e345b6c 100644 --- a/content/zh/examples/windows/hostpath-volume-pod.yaml +++ b/content/zh/examples/windows/hostpath-volume-pod.yaml @@ -11,7 +11,7 @@ spec: mountPath: "C:\\etc\\foo" readOnly: true nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows volumes: - name: foo hostPath: diff --git a/content/zh/examples/windows/secret-pod.yaml b/content/zh/examples/windows/secret-pod.yaml index f4a8122c0a..69ee9b1f1e 100644 --- a/content/zh/examples/windows/secret-pod.yaml +++ b/content/zh/examples/windows/secret-pod.yaml @@ -29,4 +29,4 @@ spec: name: mysecret key: password nodeSelector: - beta.kubernetes.io/os: windows + kubernetes.io/os: windows diff --git a/content/zh/examples/windows/simple-pod.yaml b/content/zh/examples/windows/simple-pod.yaml index f056f3cf0a..0b1f0ed5c5 100644 --- a/content/zh/examples/windows/simple-pod.yaml +++ b/content/zh/examples/windows/simple-pod.yaml @@ -11,4 +11,4 @@ spec: ports: - containerPort: 80 nodeSelector: - "beta.kubernetes.io/os": windows + "kubernetes.io/os": windows diff --git a/i18n/en.toml b/i18n/en.toml index c3a5ab69ae..015897ce78 100644 --- a/i18n/en.toml +++ b/i18n/en.toml @@ -175,6 +175,9 @@ other = "Objectives" [prerequisites_heading] other = "Before you begin" +[subscribe_button] +other = "Subscribe" + [ui_search_placeholder] other = "Search" diff --git a/i18n/it.toml b/i18n/it.toml index 6deb7ead6a..5e1f29898c 100644 --- a/i18n/it.toml +++ b/i18n/it.toml @@ -1,4 +1,164 @@ # i18n strings for the Italian site. +# NOTE: Please keep the entries in alphabetical order when editing + +[caution] +other = "Attenzione: " + +[cleanup_heading] +other = "In pulizia" + +[community_events_calendar] +other = "Calendario Eventi" + +[community_forum_name] +other = "Forum" + +[community_github_name] +other = "GitHub" + +[community_slack_name] +other = "Slack" + +[community_stack_overflow_name] +other = "Stack Overflow" + +[community_twitter_name] +other = "Twitter" + +[community_youtube_name] +other = "YouTube" + +[deprecation_warning] +other = " documentazione non è più manutenuta. La versione che stai visualizzando in questo momento è archiviata. Per una versione aggiornata, guarda " + +[deprecation_file_warning] +other = "Deprecata" + +[docs_label_browse] +other = "Sfoglia documenti" + +[docs_label_contributors] +other = "Contributors" + +[docs_label_i_am] +other = "Io Sono..." + +[docs_label_users] +other = "Utenti" + +[feedback_heading] +other = "Feedback" + +[feedback_no] +other = "No" + +[feedback_question] +other = "Questa pagina è stata di aiuto?" + +[feedback_yes] +other = "Sì" + +[input_placeholder_email_address] +other = "indirizzo email" + +[latest_version] +other = "ultima versione." + +[layouts_blog_pager_prev] +other = "<< Precedente" + +[layouts_blog_pager_next] +other = "Succesiva >>" + +[layouts_case_studies_list_tell] +other = "Racconta il tuo use case" + +[layouts_docs_glossary_aka] +other = "Anche noto come" + +[layouts_docs_glossary_description] +other = "Questo glossario vuole essere un aiuto per standardizzare la terminologia usata per Kubernetes. Include termini tecnici che sono specifici di Kubernetes, così come termini più generali che sono utili per dare un contesto." + +[layouts_docs_glossary_deselect_all] +other = "Deseleziona tutto" + +[layouts_docs_glossary_click_details_after] +other = "per il significato di questo termine." + +[layouts_docs_glossary_click_details_before] +other = "Fare click sull'icona" + +[layouts_docs_glossary_filter] +other = "Filtra i termini sulla base delle loro etichette" + +[layouts_docs_glossary_select_all] +other = "Seleziona tutto" + +[layouts_docs_partials_feedback_improvement] +other = "suggerire un miglioramento" + +[layouts_docs_partials_feedback_issue] +other = "Apri un issue sul repository GitHub se vuoi " + +[layouts_docs_partials_feedback_or] +other = "o" + +[layouts_docs_partials_feedback_problem] +other = "riportare un problema" + +[layouts_docs_partials_feedback_thanks] +other = "Grazie per il feedback. Se hai una domanda specifica su Kubernetes, chiedi su" + +[layouts_docs_search_fetching] +other = "Caricando i risultati..." + +[main_by] +other = "di" + +[main_cncf_project] +other = """Kubernetes è un progetto CNCF

""" + +[main_community_explore] +other = "Explora la community" + +[main_contribute] +other = "Contribuire" + +[main_copyright_notice] +other = """The Linux Foundation ®. Tutti i diritti riservati. The Linux Foundation ha marchi registrati e utilizza marchi commerciali. Per un elenco dei marchi di Linux Foundation, consulta la pagina sull'utilizzo dei marchi""" + +[main_documentation_license] +other = """Gli autori di Kubernetes | Documentazione distribuita sotto CC BY 4.0""" + +[main_edit_this_page] +other = "Modifica questa pagina" + +[main_github_create_an_issue] +other = "Crea un issue" + +[main_github_invite] +other = "Sei interessato a contribuire a Kubernetes?" + +[main_github_view_on] +other = "Visualizza su GitHub" + +[main_kubernetes_features] +other = "Caratteristiche di Kubernetes" + +[main_kubeweekly_baseline] +other = "Sei interessato a ricevere le ultime notizie su Kubernetes? Registrati alla newsletter KubeWeekly." + +[main_kubernetes_past_link] +other = "Vedi le precedenti mail della newsletter" + +[main_kubeweekly_signup] +other = "Iscriviti" + +[main_page_history] +other = "Storico della Pagina" + +[main_page_last_modified_on] +other = "Ultima modifica alla pagina" [main_read_about] other = "Leggi" @@ -6,77 +166,29 @@ other = "Leggi" [main_read_more] other = "Leggi di più" -[main_github_invite] -other = "Ti interessa l'hacking sulla base del codice di Kubernetes?" +[note] +other = "Nota:" -[main_github_view_on] -other = "Visualizza su GitHub" +[objectives_heading] +other = "Obbiettivi" -[main_github_create_an_issue] -other = "Crea un issue" +[prerequisites_heading] +other = "Prima di cominciare" -[main_community_explore] -other = "Explora la community" - -[main_kubernetes_features] -other = "Caratteristiche di Kubernetes" - -[main_cncf_project] -other = """Noi siamo un CNCF progetto

""" - -[main_kubeweekly_signup] -other = "Sottoscrivi" - -[main_contribute] -other = "Contribuire" - -[main_edit_this_page] -other = "Modifica questa pagina" - -[main_page_history] -other = "Lo Storico della Pagina" - -[main_page_last_modified_on] -other = "Ultima modifica alla pagina" - -[main_by] -other = "di" - -[main_documentation_license] -other = """Gli autori di Kubernetes| Documentazione distribuita sotto CC BY 4.0""" - -[main_copyright_notice] -other = """The Linux Foundation ®. Tutti i diritti riservati. The Linux Foundation ha marchi registrati e utilizza marchi commerciali. Per un elenco dei marchi di Linux Foundation, consultare il nostro sitoTrademark Usage page""" - -# Labels for the docs portal home page. -[docs_label_browse] -other = "Sfoglia documenti" - -[docs_label_contributors] -other = "Contributori" - -[docs_label_users] -other = "Utenti" - -[docs_label_i_am] -other = "Io Sono..." - - - -# Community links -[community_twitter_name] -other = "Twitter" -[community_github_name] -other = "GitHub" -[community_slack_name] -other = "Slack" -[community_stack_overflow_name] -other = "Stack Overflow" -[community_forum_name] -other = "Forum" -[community_events_calendar] -other = "Events Calendar" - -# UI elements [ui_search_placeholder] -other = "Search" +other = "Cerca" + +[version_check_mustbe] +other = "La tua installazione Kubernetes deve avere la versione " + +[version_check_mustbeorlater] +other = "La tua installazione Kubernetes deve avere almeno la versione " + +[version_check_tocheck] +other = "Per verificare la versione, esegui " + +[warning] +other = "Attenzione:" + +[whatsnext_heading] +other = "Voci correlate" diff --git a/i18n/ja.toml b/i18n/ja.toml index a80eac684f..5806716d01 100644 --- a/i18n/ja.toml +++ b/i18n/ja.toml @@ -25,6 +25,9 @@ other = "Stack Overflow" [community_twitter_name] other = "Twitter" +[community_youtube_name] +other = "YouTube" + [deprecation_warning] other = " のドキュメントは積極的にメンテナンスされていません。現在表示されているバージョンはスナップショットです。最新のドキュメントはこちらです: " diff --git a/i18n/nl.toml b/i18n/nl.toml index bb334b1a65..a0aa6faee4 100644 --- a/i18n/nl.toml +++ b/i18n/nl.toml @@ -189,6 +189,8 @@ other = "Stack Overflow" other = "Forum" [community_events_calendar] other = "Evenementenkalender" +[community_youtube_name] +other = "YouTube" # UI elements [ui_search_placeholder] diff --git a/i18n/ru.toml b/i18n/ru.toml index 7a0e39b708..37447c0cad 100644 --- a/i18n/ru.toml +++ b/i18n/ru.toml @@ -15,6 +15,9 @@ other = "Очистка" [prerequisites_heading] other = "Подготовка к работе" +[subscribe_button] +other = "Подписаться" + [whatsnext_heading] other = "Что дальше" diff --git a/i18n/uk.toml b/i18n/uk.toml index ef59e46cfa..ec60865783 100644 --- a/i18n/uk.toml +++ b/i18n/uk.toml @@ -226,6 +226,10 @@ other = "Цілі" # other = "Before you begin" other = "Перш ніж ви розпочнете" +[subscribe_button] +# other = "Subscribe" +other = "Підписатися" + [ui_search_placeholder] # other = "Search" other = "Пошук" diff --git a/layouts/index.html b/layouts/index.html index 955bd6a934..1e14ba9228 100644 --- a/layouts/index.html +++ b/layouts/index.html @@ -28,7 +28,7 @@ -
+
{{ T "main_kubeweekly_past_link" }}
diff --git a/layouts/partials/footer.html b/layouts/partials/footer.html index dfedd412b0..e132e3df38 100644 --- a/layouts/partials/footer.html +++ b/layouts/partials/footer.html @@ -17,7 +17,7 @@ {{ T "community_stack_overflow_name" }} {{ T "community_youtube_name" }} {{ T "community_forum_name" }} - {{ T "community_events_calendar" }} + {{ T "community_events_calendar" }}
{{ with site.GetPage "page" "/docs/setup/pick-right-solution/" }}{{ .LinkTitle }}{{ end }} diff --git a/layouts/partials/header.html b/layouts/partials/header.html index ac6c6f0d1f..44365f8ecb 100644 --- a/layouts/partials/header.html +++ b/layouts/partials/header.html @@ -64,7 +64,7 @@ {{ T "community_stack_overflow_name" }} {{ T "community_youtube_name" }} {{ T "community_forum_name" }} - {{ T "community_events_calendar" }} + {{ T "community_events_calendar" }}
diff --git a/layouts/partials/templates/feature-dialog.html b/layouts/partials/templates/feature-dialog.html deleted file mode 100644 index 2f25aefb02..0000000000 --- a/layouts/partials/templates/feature-dialog.html +++ /dev/null @@ -1,29 +0,0 @@ - -{{ .page.Title }} -
-{{ .page.Content | markdownify }} -
- diff --git a/layouts/partials/templates/feature-state.html b/layouts/partials/templates/feature-state.html deleted file mode 100644 index 2076b0f078..0000000000 --- a/layouts/partials/templates/feature-state.html +++ /dev/null @@ -1,21 +0,0 @@ -
-{{ $for_k8s_version := .for_k8s_version | default (.page.Param "version") }} -{{ $width := .width | default "600" }} -{{ $state := .state }} -FEATURE STATE: Kubernetes {{ $for_k8s_version }} -{{/* docs/templates is a Hugo page bundle */}} -{{ $templates_path := "docs/templates" }} -{{ $templates := site.GetPage "page" $templates_path }} -{{ with $templates.Resources }} - {{ $template_path := printf "**feature-state-%s*" $state }} - {{ $content_template := .GetMatch $template_path }} - {{ with $content_template }} - {{ $dialog := dict "page" $content_template "for_k8s_version" $for_k8s_version "width" $width }} - {{ partial "templates/feature-dialog.html" $dialog }} - {{ else }} - {{ errorf "[%s] template not found in %s" site.Language.Lang $template_path }} - {{ end }} -{{ else }} - {{ errorf "[%s] templates not found in docs/templates" site.Language.Lang }} -{{ end }} -
diff --git a/layouts/shortcodes/feature-state.html b/layouts/shortcodes/feature-state.html index 17f278b1f6..745c5f396e 100644 --- a/layouts/shortcodes/feature-state.html +++ b/layouts/shortcodes/feature-state.html @@ -1,10 +1,11 @@ {{ $valid_states := "alpha, beta, deprecated, stable" }} {{ $state := .Get "state" }} -{{ $for_k8s_version := .Get "for_k8s_version" }} -{{ $width := .Get "width" }} +{{ $for_k8s_version := .Get "for_k8s_version" | default (.Page.Param "version")}} {{ $is_valid := strings.Contains $valid_states $state }} {{ if not $is_valid }} {{ errorf "%q is not a valid feature-state, use one of %q" $valid_states }} {{ else }} -{{ partial "templates/feature-state.html" (dict "ctx" . "page" .Page "state" $state "for_k8s_version" $for_k8s_version "width" $width) }} -{{ end }} +
+FEATURE STATE: Kubernetes {{ $for_k8s_version }} [{{ $state }}] +
+{{ end }} \ No newline at end of file diff --git a/layouts/shortcodes/latest-version.html b/layouts/shortcodes/latest-version.html index ece9e21df7..ba8a6811b2 100644 --- a/layouts/shortcodes/latest-version.html +++ b/layouts/shortcodes/latest-version.html @@ -1 +1 @@ -{{ site.Params.latest }} +{{ site.Params.latest }} \ No newline at end of file diff --git a/layouts/shortcodes/note.html b/layouts/shortcodes/note.html index 1161c2366c..1da48797c5 100644 --- a/layouts/shortcodes/note.html +++ b/layouts/shortcodes/note.html @@ -1,3 +1,3 @@
-
{{ T "note" }} {{ trim .Inner " \n" | markdownify }}
+
{{ T "note" }} {{ replaceRE "\\s+|\n" " " .Inner | markdownify }}
\ No newline at end of file diff --git a/layouts/shortcodes/release-branch.html b/layouts/shortcodes/release-branch.html index 7c760ebebf..df21f05b64 100644 --- a/layouts/shortcodes/release-branch.html +++ b/layouts/shortcodes/release-branch.html @@ -1,3 +1,3 @@ {{- $latestVersion := site.Params.latest }} {{- $latestReleaseBranch := printf "release-%s" (replace $latestVersion "v" "") }} -{{- $latestReleaseBranch }} +{{- $latestReleaseBranch }} \ No newline at end of file diff --git a/layouts/shortcodes/tabs.html b/layouts/shortcodes/tabs.html index cfb6246aae..7abe6c14e8 100644 --- a/layouts/shortcodes/tabs.html +++ b/layouts/shortcodes/tabs.html @@ -1,43 +1,43 @@ -{{ .Page.Scratch.Add "tabset-counter" 1 }} -{{ $tab_set_id := .Get "name" | default (printf "tabset-%s-%d" (.Page.RelPermalink) (.Page.Scratch.Get "tabset-counter") ) | anchorize }} -{{ $tabs := .Scratch.Get "tabs" }} -{{ if .Inner }}{{/* We don't use the inner content, but Hugo will complain if we don't reference it. */}}{{ end }} +{{- .Page.Scratch.Add "tabset-counter" 1 -}} +{{- $tab_set_id := .Get "name" | default (printf "tabset-%s-%d" (.Page.RelPermalink) (.Page.Scratch.Get "tabset-counter") ) | anchorize -}} +{{- $tabs := .Scratch.Get "tabs" -}} +{{- if .Inner -}}{{- /* We don't use the inner content, but Hugo will complain if we don't reference it. */ -}}{{- end -}}
    - {{ range $i, $e := $tabs }} - {{ $id := printf "%s-%d" $tab_set_id $i }} -
  • {{ trim .name " " }}
    • -{{ end }} + {{- range $i, $e := $tabs -}} + {{- $id := printf "%s-%d" $tab_set_id $i -}} +
  • {{- trim .name " " -}}
    • +{{- end -}}
-{{ range $i, $e := $tabs }} -{{ $id := printf "%s-%d" $tab_set_id $i }} +{{- range $i, $e := $tabs -}} +{{- $id := printf "%s-%d" $tab_set_id $i -}}
- {{ with .content }} - {{ . }} - {{ else }} - {{ if eq $.Page.BundleType "leaf" }} - {{/* find the file somewhere inside the bundle. Note the use of double asterisk */}} - {{ with $.Page.Resources.GetMatch (printf "**%s*" .include) }} - {{ if ne .ResourceType "page" }} - {{/* Assume it is a file that needs code highlighting. */}} - {{ $codelang := $e.codelang | default ( path.Ext .Name | strings.TrimPrefix ".") }} - {{ highlight .Content $codelang "" }} - {{ else}} - {{ .Content }} - {{ end }} - {{ end }} - {{ else}} - {{ $path := path.Join $.Page.File.Dir .include }} - {{ $page := site.GetPage "page" $path }} - {{ with $page }} - {{ .Content }} - {{ else }} - {{ errorf "[%s] tabs include not found for path %q" site.Language.Lang $path}} - {{ end }} - {{ end }} - {{ end }} + {{- with .content -}} + {{- . -}} + {{- else -}} + {{- if eq $.Page.BundleType "leaf" -}} + {{- /* find the file somewhere inside the bundle. Note the use of double asterisk */ -}} + {{- with $.Page.Resources.GetMatch (printf "**%s*" .include) -}} + {{- if ne .ResourceType "page" -}} + {{- /* Assume it is a file that needs code highlighting. */ -}} + {{- $codelang := $e.codelang | default ( path.Ext .Name | strings.TrimPrefix ".") -}} + {{- highlight .Content $codelang "" -}} + {{- else -}} + {{- .Content -}} + {{- end -}} + {{- end -}} + {{- else -}} + {{- $path := path.Join $.Page.File.Dir .include -}} + {{- $page := site.GetPage "page" $path -}} + {{- with $page -}} + {{- .Content -}} + {{- else -}} + {{- errorf "[%s] tabs include not found for path %q" site.Language.Lang $path -}} + {{- end -}} + {{- end -}} + {{- end -}}
-{{ end }} +{{- end -}}
-{{ $elem := $tab_set_id | safeJS }} - +{{- $elem := $tab_set_id | safeJS -}} + \ No newline at end of file diff --git a/netlify.toml b/netlify.toml index 47fb91279b..136652e60c 100644 --- a/netlify.toml +++ b/netlify.toml @@ -7,7 +7,8 @@ functions = "functions" command = "make non-production-build" [build.environment] -HUGO_VERSION = "0.59.1" +HUGO_VERSION = "0.70.0" +NODE_VERSION = "10.20.0" [context.production.environment] HUGO_BASEURL = "https://kubernetes.io/" diff --git a/static/_redirects b/static/_redirects index 806d1ebb60..94a9db1c70 100644 --- a/static/_redirects +++ b/static/_redirects @@ -91,11 +91,13 @@ /docs/concepts/cluster-administration/sysctl-cluster/ /docs/tasks/administer-cluster/sysctl-cluster/ 301 /docs/concepts/cluster-administration/static-pod/ /docs/tasks/administer-cluster/static-pod/ 301 /docs/concepts/clusters/logging/ /docs/concepts/cluster-administration/logging/ 301 +/docs/concepts/configuration/assign-pod-node/ /docs/concepts/scheduling-eviction/assign-pod-node/ 301 /docs/concepts/configuration/container-command-arg/ /docs/tasks/inject-data-application/define-command-argument-container/ 301 /docs/concepts/configuration/container-command-args/ /docs/tasks/inject-data-application/define-command-argument-container/ 301 /docs/concepts/configuration/manage-compute-resources-container/ /docs/concepts/configuration/manage-resources-containers/ 301 /docs/concepts/configuration/scheduler-perf-tuning/ /docs/concepts/scheduling-eviction/scheduler-perf-tuning/ 301 /docs/concepts/configuration/scheduling-framework/ /docs/concepts/scheduling-eviction/scheduling-framework/ 301 +/docs/concepts/configuration/taint-and-toleration/ /docs/concepts/scheduling-eviction/taint-and-toleration/ 301 /docs/concepts/ecosystem/thirdpartyresource/ /docs/tasks/access-kubernetes-api/extend-api-third-party-resource/ 301 /docs/concepts/jobs/cron-jobs/ /docs/concepts/workloads/controllers/cron-jobs/ 301 /docs/concepts/jobs/run-to-completion-finite-workloads/ /docs/concepts/workloads/controllers/jobs-run-to-completion/ 301 @@ -365,8 +367,8 @@ /docs/user-guide/monitoring/ /docs/tasks/debug-application-cluster/resource-usage-monitoring/ 301 /docs/user-guide/namespaces/ /docs/concepts/overview/working-with-objects/namespaces/ 301 /docs/user-guide/networkpolicies/ /docs/concepts/services-networking/network-policies/ 301 -/docs/user-guide/node-selection/ /docs/concepts/configuration/assign-pod-node/ 301 -/docs/user-guide/node-selection/README /docs/concepts/configuration/assign-pod-node/ 301 +/docs/user-guide/node-selection/ /docs/concepts/scheduling-eviction/assign-pod-node/ 301 +/docs/user-guide/node-selection/README /docs/concepts/scheduling-eviction/assign-pod-node/ 301 /docs/user-guide/overview/ /docs/concepts/overview/what-is-kubernetes/ 301 /docs/user-guide/persistent-volumes/ /docs/concepts/storage/persistent-volumes/ 301 /docs/user-guide/persistent-volumes/index /docs/concepts/storage/persistent-volumes/ 301 diff --git a/static/css/blog.css b/static/css/blog.css index c584ee4e53..90bb0c0260 100644 --- a/static/css/blog.css +++ b/static/css/blog.css @@ -497,6 +497,10 @@ img.big-img { overflow-x: scroll; } +.flyout-button { + display: none; +} + /* .content img { max-width: 100%; } */ diff --git a/static/css/case-studies-gradient.css b/static/css/case-studies-gradient.css index a696aa94fb..d33439d91f 100644 --- a/static/css/case-studies-gradient.css +++ b/static/css/case-studies-gradient.css @@ -195,7 +195,7 @@ h4 { font-size:1.2em !important; color:#3366ff; letter-spacing:0.03em; - padding-bottom:1% !important; + padding-bottom:2% !important; padding-top:2%; margin-left:0; padding-left:10%; diff --git a/static/css/gridpage.css b/static/css/gridpage.css index 297c7d3637..542eadea8f 100644 --- a/static/css/gridpage.css +++ b/static/css/gridpage.css @@ -84,6 +84,7 @@ .case-study img { position: absolute; top: 0; + width:215px; left: 0; } diff --git a/static/images/Babylon1.jpg b/static/images/Babylon1.jpg new file mode 100644 index 0000000000..a99573d629 Binary files /dev/null and b/static/images/Babylon1.jpg differ diff --git a/static/images/Babylon2.jpg b/static/images/Babylon2.jpg new file mode 100644 index 0000000000..c099b70cf9 Binary files /dev/null and b/static/images/Babylon2.jpg differ diff --git a/static/images/BoozAllen1.png b/static/images/BoozAllen1.png new file mode 100644 index 0000000000..78c30f5130 Binary files /dev/null and b/static/images/BoozAllen1.png differ diff --git a/static/images/BoozAllen2.jpg b/static/images/BoozAllen2.jpg new file mode 100644 index 0000000000..8de90cd9d9 Binary files /dev/null and b/static/images/BoozAllen2.jpg differ diff --git a/static/images/BoozAllen4.jpg b/static/images/BoozAllen4.jpg new file mode 100644 index 0000000000..d72ebe271f Binary files /dev/null and b/static/images/BoozAllen4.jpg differ diff --git a/static/images/Denso1.png b/static/images/Denso1.png new file mode 100644 index 0000000000..1c6304bc97 Binary files /dev/null and b/static/images/Denso1.png differ diff --git a/static/images/Denso2.jpg b/static/images/Denso2.jpg new file mode 100644 index 0000000000..2356a9ed16 Binary files /dev/null and b/static/images/Denso2.jpg differ diff --git a/static/images/Denso4.jpg b/static/images/Denso4.jpg new file mode 100644 index 0000000000..6fa6af9d9e Binary files /dev/null and b/static/images/Denso4.jpg differ diff --git a/static/images/babylon4.jpg b/static/images/babylon4.jpg new file mode 100644 index 0000000000..57272100b6 Binary files /dev/null and b/static/images/babylon4.jpg differ diff --git a/static/images/babylon_featured.svg b/static/images/babylon_featured.svg new file mode 100644 index 0000000000..8bea0b8fc3 --- /dev/null +++ b/static/images/babylon_featured.svg @@ -0,0 +1 @@ +babylon_featured_logo \ No newline at end of file diff --git a/static/images/babylon_featured_logo.svg b/static/images/babylon_featured_logo.svg new file mode 100644 index 0000000000..8bea0b8fc3 --- /dev/null +++ b/static/images/babylon_featured_logo.svg @@ -0,0 +1 @@ +babylon_featured_logo \ No newline at end of file diff --git a/static/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-1.png b/static/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-1.png new file mode 100644 index 0000000000..aafa4b08ed Binary files /dev/null and b/static/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-1.png differ diff --git a/static/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-2.png b/static/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-2.png new file mode 100644 index 0000000000..17842990c1 Binary files /dev/null and b/static/images/blog/2020-05-05-introducing-podtopologyspread/advanced-usage-2.png differ diff --git a/static/images/blog/2020-05-05-introducing-podtopologyspread/api.png b/static/images/blog/2020-05-05-introducing-podtopologyspread/api.png new file mode 100644 index 0000000000..1865f64261 Binary files /dev/null and b/static/images/blog/2020-05-05-introducing-podtopologyspread/api.png differ diff --git a/static/images/booking1.jpg b/static/images/booking1.jpg new file mode 100644 index 0000000000..61759c55ff Binary files /dev/null and b/static/images/booking1.jpg differ diff --git a/static/images/booking2.JPG b/static/images/booking2.JPG new file mode 100644 index 0000000000..af0b0ff056 Binary files /dev/null and b/static/images/booking2.JPG differ diff --git a/static/images/booking3.jpg b/static/images/booking3.jpg new file mode 100644 index 0000000000..a7d41921cf Binary files /dev/null and b/static/images/booking3.jpg differ diff --git a/static/images/denso_featured_logo.svg b/static/images/denso_featured_logo.svg new file mode 100644 index 0000000000..375d9cefbc --- /dev/null +++ b/static/images/denso_featured_logo.svg @@ -0,0 +1 @@ + \ No newline at end of file
StringAPI Object
"pods"Pod
"servicesService
"services"Service
"replicationcontrollers"ReplicationController
"resourcequotas"ResourceQuota
"secrets"Secret