diff --git a/README-uk.md b/README-uk.md index c1605b0c85716..3b4e7c1e27143 100644 --- a/README-uk.md +++ b/README-uk.md @@ -1,86 +1,209 @@ - # Документація Kubernetes [![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) - -Вітаємо! В цьому репозиторії міститься все необхідне для роботи над [сайтом і документацією Kubernetes](https://kubernetes.io/). Ми щасливі, що ви хочете зробити свій внесок! +Цей репозиторій містить матеріали потрібні для створення [вебсайту Kubernetes та документації](https://kubernetes.io/). Ми щасливі, що ви хочете зробити свій внесок! - -## Запуск сайту локально зa допомогою Hugo +- [Внесок до документації](#внесок-до-документації) +- [Локалізовані файли README](#локалізовані-файли-readme) - -Для інструкцій з встановлення Hugo дивіться [офіційну документацію](https://gohugo.io/getting-started/installing/). Обов’язково встановіть розширену версію Hugo, яка позначена змінною оточення `HUGO_VERSION` у файлі [`netlify.toml`](netlify.toml#L10). +## Користування цим репозиторієм - -Після встановлення Hugo, запустіть сайт локально командою: +Ви можете запустити вебсайт локально, використовуючи [Hugo (розширена версія)](https://gohugo.io/), або ви можете запустити його в контейнерному середовищі. Ми настійно рекомендуємо використовувати контейнерне середовище, оскільки воно забезпечує однорідність розгортання порівняно з основним вебсайтом. + +## Передумови + +Для користування цим репозиторієм вам потрібно локально встановити наступні інструменти: + +- [npm](https://www.npmjs.com/) +- [Go](https://go.dev/) +- [Hugo (Розширена версія)](https://gohugo.io/) +- Середовище запуску контейнерів, наприклад [Docker](https://www.docker.com/). + +Перед тим як розпочати, встановіть залежності. Зробіть клон репозиторію та перейдіть в теку: ```bash git clone https://github.com/kubernetes/website.git cd website +``` + +Сайт Kubernetes використовує [Docsy Hugo theme](https://github.com/google/docsy#readme). Навіть якщо ви плануєте запускати вебсайт в контейнері, ми настійливо рекомендуємо встановити субмодулі та інші залежності зробивши наступне: + +### Windows +```powershell +# отримання залежностей субмодулів git submodule update --init --recursive --depth 1 -make serve ``` - -Команда запустить локальний Hugo-сервер на порту 1313. Відкрийте у своєму браузері http://localhost:1313, щоб побачити сайт. По мірі того, як ви змінюєте вихідний код, Hugo актуалізує сайт відповідно до внесених змін і оновлює сторінку у браузері. +### Linux / інші Unix +```bash +# отримання залежностей субмодулів +make module-init +``` + +## Запуск вебсайту використовуючи контейнер + +Для збирання вебсайту з використанням контейнера, зробіть наступне: + +```bash +# Ви можете встановити у $CONTAINER_ENGINE назву будь-якого Docker-подібного інструменту +make container-serve +``` + +Якщо ви бачите помилку, скоріш за все це означає, що контейнеру hugo не вистачило обчислювальних ресурсів. Для її розвʼязання збільште обсяг процесорних потужностей та памʼяті для Docker у себе на компʼютері ([MacOS](https://docs.docker.com/desktop/settings/mac/) та [Windows](https://docs.docker.com/desktop/settings/windows/)). + +Відкрийте у себе в оглядачі адресу для перегляду локального вебсайту. По міри того, як ви вноситимете зміни в сирці, Hugo оновлюватиме вебсайт та перезавантажуватиме сторінку в оглядачі. + +## Запуск сайт локально з використанням Hugo + +Переконайтесь, що ви встановили розширену версію Hugo яку вказано у змінній оточення `HUGO_VERSION` файлу [`netlify.toml`](netlify.toml#L11). + +Для встановлення залежностей, розгорніть та перевірте сайт локально: + +- На macOS та Linux + ```bash + npm ci + make serve + ``` +- На Windows (PowerShell) + ```powershell + npm ci + hugo.exe server --buildFuture --environment development + ``` + +Це призведе до запуску локального сервера Hugo, який відповідатиме на запити на порту 1313. Відкрийте у себе в оглядачі адресу для перегляду локального вебсайту. По міри того, як ви вноситимете зміни в сирці, Hugo оновлюватиме вебсайт та перезавантажуватиме сторінку в оглядачі. + +## Створення довідкових сторінок API + +Довідкові сторінки API, розташовані в `content/en/docs/reference/kubernetes-api`, створюються на основі специфікації Swagger, також відомої як специфікація OpenAPI, за допомогою . + +Для оновлення довідкових сторінок для нового випуску Kubernetes виконайте наступні кроки: + +1. Отримайте субмодуль `api-ref-generator`: + + ```bash + git submodule update --init --recursive --depth 1 + ``` + +2. Оновіть специфікацію Swagger: + + ```bash + curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json + ``` + +3. В `api-ref-assets/config/`, змініть файли `toc.yaml` та `fields.yaml`, так щоб вони вказували на новий випуск. - -## Спільнота, обговорення, внесок і підтримка +4. Далі, зберіть сторінки: - -Дізнайтеся, як долучитися до спільноти Kubernetes на [сторінці спільноти](http://kubernetes.io/community/). + ```bash + make api-reference + ``` - -Для зв’язку із супроводжуючими проекту скористайтеся: + Ви можете протестувати результати локально запустивши сайт з образу контейнера: + + ```bash + make container-image + make container-serve + ``` + + У вебоглядачі перейдіть до для перегляду довідки API. + +5. Коли всі зміни, щодо переходу на нову версію внесені у файли `toc.yaml` та `fields.yaml`, створіть запит на втягування (pull request) з новоствореними сторінками довідки API. + +## Усунення несправностей + +### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version + +Hugo має два виконуваних файли з технічних причин. Поточний вебсайт запускається лише на **Hugo Extended**. На сторінці [release page](https://github.com/gohugoio/hugo/releases) шукайте архів з `extended`  в назві. Для перевірки запустіть `hugo version` та шукайте слово `extended` у виводі. + +### Усунення несправностей в macOS для занадто великої кількості відкритих файлів + +Якщо ви запускаєте `make serve` в macOS та отримуєте наступну помилку: + +```bash +ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files +make: *** [serve] Error 1 +``` + +Перевірте поточні обмеження на кількість відкритих файлів: + +`launchctl limit maxfiles` + +Потім виконайте наступні команди (взято з ): + +```shell +#!/bin/sh + +# These are the original gist links, linking to my gists now. +# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist +# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist + +curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxfiles.plist +curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxproc.plist + +sudo mv limit.maxfiles.plist /Library/LaunchDaemons +sudo mv limit.maxproc.plist /Library/LaunchDaemons + +sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist +sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist + +sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist +``` + +Це працює як для Catalina, так і для Mojave macOS. + +## Приєднуйтесь до SIG Docs + +Дізнайтеся більше про спільноту SIG Docs Kubernetes та зустрічі на [сторінці спільноти](https://github.com/kubernetes/community/tree/master/sig-docs#meetings). + +Ви також можете звʼязатися з супроводжуючими цього проєкту: - [Slack](https://kubernetes.slack.com/messages/sig-docs) -- [Поштова розсилка](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + - [Отримайте запрошення до Slack](https://slack.k8s.io/) +- [Список розсилки](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + +## Внесок до документації + +Ви можете натиснути кнопку **Fork** у верхній правій частині екрана, щоб створити копію цього репозиторію у своєму обліковому записі GitHub. Ця копія називається _fork_ (відгалуження). Вносьте будь-які зміни, які ви хочете у своєму відгалуженні, і коли ви будете готові надіслати ці зміни нам, перейдіть до нього та створіть новий pull request (запит на втягування), щоб повідомити нас про це. + +Після створення вашого запиту на втягування, рецензент Kubernetes візьме на себе відповідальність за надання чіткого та практичного відгуку. Як власник запиту на втягування, **вам належить внести зміни до вашого запиту на втягування, щоб відповісти на отриманий відгук від рецензента Kubernetes.** - -## Внесок у документацію +Крім того, зверніть увагу, що у вас може бути більше одного рецензента Kubernetes, який надасть вам відгук, або ви можете отримати зворотний звʼязок від рецензента Kubernetes, який відрізняється від того, який спочатку був призначений для надання вам зворотного звʼязку. - -Ви можете створити копію цього репозиторія у своєму акаунті на GitHub, натиснувши на кнопку **Fork**, що розташована справа зверху. Ця копія називатиметься *fork* (відгалуження). Зробіть будь-які необхідні зміни у своєму відгалуженні. Коли ви будете готові надіслати їх нам, перейдіть до свого відгалуження і створіть новий pull request, щоб сповістити нас. +Крім того, в деяких випадках один з ваших рецензентів може попросити технічний огляд у технічного рецензента Kubernetes, коли це необхідно. Рецензенти зроблять все можливе, щоб своєчасно надати відгук, але час відповіді може змінюватися залежно від обставин. - -Після того, як ви створили pull request, рецензент Kubernetes зобов’язується надати вам по ньому чіткий і конструктивний коментар. **Ваш обов’язок як творця pull request - відкоригувати його відповідно до зауважень рецензента Kubernetes.** +Для отримання додаткової інформації про внесок у документацію Kubernetes див.: - -Також, зауважте: може статися так, що ви отримаєте коментарі від декількох рецензентів Kubernetes або від іншого рецензента, ніж той, якого вам було призначено від початку. +- [Участь в створені документації Kubernetes](https://kubernetes.io/docs/contribute/) +- [Типи вмісту сторінок](https://kubernetes.io/docs/contribute/style/page-content-types/) +- [Посібник зі стилю документації](https://kubernetes.io/docs/contribute/style/style-guide/) +- [Локалізація документації Kubernetes](https://kubernetes.io/docs/contribute/localization/) +- [Introduction to Kubernetes Docs](https://www.youtube.com/watch?v=pprMgmNzDcw) - -Крім того, за потреби один із ваших рецензентів може запросити технічну перевірку від одного з технічних рецензентів Kubernetes, коли це необхідно. Рецензенти намагатимуться відреагувати вчасно, проте час відповіді може відрізнятися в залежності від обставин. +### Помічники для нових учасників - -Більше інформації про внесок у документацію Kubernetes ви знайдете у наступних джерелах: +Якщо вам потрібна допомога в будь-який момент, коли ви робите свій внесок, [помічник для нових учасників](https://kubernetes.io/docs/contribute/advanced/#serve-as-a-new-contributor-ambassador) є тою особою, до якої варто звертатись. Вони затверджують роботу інших в SIG Docs, їх обов'язки включають наставництво нових учасників та допомогу їм у перших кількох запитах на злиття змін. Найкращим місцем для звʼязку з помічниками є [Kubernetes Slack](https://slack.k8s.io/). Поточні помічники в SIG Docs: -* [Внесок: з чого почати](https://kubernetes.io/docs/contribute/) -* [Використання шаблонів сторінок](https://kubernetes.io/docs/contribute/style/page-content-types/) -* [Керівництво зі стилю оформлення документації](http://kubernetes.io/docs/contribute/style/style-guide/) -* [Переклад документації Kubernetes іншими мовами](https://kubernetes.io/docs/contribute/localization/) +| Імʼя | Slack | GitHub | +| -------------------------- | -------------------------- | -------------------------- | +| Arsh Sharma | @arsh | @RinkiyaKeDad | - -## Файл `README.md` іншими мовами +## Локалізовані файли README -| інші мови | інші мови | -|-------------------------------|-------------------------------| -| [Англійська](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-ru.md) | -| [Італійська](README-it.md) | [Польська](README-pl.md) | +| Мова | Мова | +| -------------------------- | -------------------------- | +| [Китайська](README-zh.md) | [Корейська](README-ko.md) | +| [Французька](README-fr.md) | [Польська](README-pl.md) | +| [Німецька](README-de.md) | [Португальська](README-pt.md) | +| [Хінді](README-hi.md) | [Російська](README-ru.md) | +| [Індонезійська](README-id.md) | [Іспанська](README-es.md) | +| [Італійська](README-it.md) | [Українська](README-uk.md) | +| [Японська](README-ja.md) | [Вʼєтнамська](README-vi.md) | - ## Кодекс поведінки - -Участь у спільноті Kubernetes визначається правилами [Кодексу поведінки СNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). +Участь у спільноті Kubernetes регулюється [Кодексом поведінки CNCF](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). - -## Дякуємо! +## Дякуємо вам - -Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію! +Kubernetes процвітає завдяки участі спільноти, і ми цінуємо ваш внесок у наш вебсайт та нашу документацію! diff --git a/content/uk/_index.html b/content/uk/_index.html index ff0b5312422af..3aa209edb5206 100644 --- a/content/uk/_index.html +++ b/content/uk/_index.html @@ -1,53 +1,44 @@ --- -title: "Довершена система оркестрації контейнерів" -abstract: "Автоматичне розгортання, масштабування і управління контейнерами" +title: "Система оркестрування контейнерів промислового класу" +abstract: "Автоматичне розгортання, масштабування та управління контейнерами" cid: home +sitemap: + priority: 1.0 --- {{< site-searchbar >}} {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} - -### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) - це система з відкритим вихідним кодом для автоматичного розгортання, масштабування і управління контейнеризованими застосунками. - - -Вона об'єднує контейнери, що утворюють застосунок, у логічні елементи для легкого управління і виявлення. В основі Kubernetes - [15 років досвіду запуску і виконання застосунків у продуктивних середовищах Google](http://queue.acm.org/detail.cfm?id=2898444), поєднані з найкращими ідеями і практиками від спільноти. + +[Kubernetes]({{< relref "/docs/concepts/overview/" >}}), скорочено K8s — це система з відкритими сирцями для автоматичного розгортання, масштабування та управління контейнеризованими застосунками. + +Вона гуртує контейнери, з яких складається застосунок, у логічні елементи для легкого управління ним та їх виявлення. Kubernetes спирається на [15 річний досвід роботи з промисловими навантаженнями в Google](http://queue.acm.org/detail.cfm?id=2898444), поєднуючи найкращі ідеї та практики спільноти. {{% /blocks/feature %}} {{% blocks/feature image="scalable" %}} - -#### Глобальне масштабування - -Заснований на тих самих принципах, завдяки яким Google запускає мільярди контейнерів щотижня, Kubernetes масштабується без потреби збільшення вашого штату з експлуатації. +#### Глобальний масштаб + +Систему створено на тих самих принципах, які дозволяють Google запускати мільярди контейнерів щотижня, Kubernetes може масштабуватися, не вимагаючи збільшення вашої операційної команди. {{% /blocks/feature %}} {{% blocks/feature image="blocks" %}} - + #### Невичерпна функціональність - -Запущений для локального тестування чи у глобальній корпорації, Kubernetes динамічно зростатиме з вами, забезпечуючи регулярну і легку доставку ваших застосунків незалежно від рівня складності ваших потреб. +Незалежно від того, чи ви тестуєте локально, чи керуєте великою корпорацією, гнучкість Kubernetes зростає разом з вами, щоб послідовно та легко доставляти ваші програми, незалежно від того, наскільки складними є ваші вимоги. {{% /blocks/feature %}} {{% blocks/feature image="suitcase" %}} - -#### Працює всюди - -Kubernetes - проект з відкритим вихідним кодом. Він дозволяє скористатися перевагами локальної, гібридної чи хмарної інфраструктури, щоб легко переміщати застосунки туди, куди вам потрібно. +#### K8s працює всюди + +Kubernetes — проєкт з відкритими сирцями. Він дозволяє скористатися перевагами локальної, гібридної чи хмарної інфраструктури, щоб легко переміщати застосунки туди, де вони потрібні. + +Для завантаження Kubernetes відвідайте розділ [Завантаження](/releases/download/). {{% /blocks/feature %}} @@ -55,12 +46,8 @@ {{< blocks/section id="video" background-image="kub_video_banner_homepage" >}}
- -

Проблеми міграції 150+ мікросервісів у Kubernetes

- -

Сара Уеллз, технічний директор з експлуатації і безпеки роботи, Financial Times

+

Виклики повʼязані з міграцією 150+ мікросервісів у Kubernetes

+

Сара Уеллз, технічний директор з експлуатації та надійності, Financial Times



diff --git a/content/uk/case-studies/_index.html b/content/uk/case-studies/_index.html index f8003e82e0d3f..edb8184a99282 100644 --- a/content/uk/case-studies/_index.html +++ b/content/uk/case-studies/_index.html @@ -1,11 +1,7 @@ --- -#title: Case Studies title: Приклади використання -#linkTitle: Case Studies linkTitle: Приклади використання -#bigheader: Kubernetes User Case Studies bigheader: Приклади використання Kubernetes від користувачів. -#abstract: A collection of users running Kubernetes in production. abstract: Підбірка користувачів, що використовують Kubernetes для робочих навантажень. layout: basic class: gridPage diff --git a/content/uk/case-studies/appdirect/appdirect_featured_logo.png b/content/uk/case-studies/appdirect/appdirect_featured_logo.png new file mode 100644 index 0000000000000..724a8a75684f0 Binary files /dev/null and b/content/uk/case-studies/appdirect/appdirect_featured_logo.png differ diff --git a/content/uk/case-studies/appdirect/appdirect_featured_logo.svg b/content/uk/case-studies/appdirect/appdirect_featured_logo.svg new file mode 100644 index 0000000000000..36fcba1abba36 --- /dev/null +++ b/content/uk/case-studies/appdirect/appdirect_featured_logo.svg @@ -0,0 +1 @@ +kubernetes.io-logos \ No newline at end of file diff --git a/content/uk/case-studies/appdirect/index.html b/content/uk/case-studies/appdirect/index.html new file mode 100644 index 0000000000000..134e47a976d51 --- /dev/null +++ b/content/uk/case-studies/appdirect/index.html @@ -0,0 +1,85 @@ +--- +title: AppDirect Case Study +linkTitle: AppDirect +case_study_styles: true +cid: caseStudies +logo: appdirect_featured_logo.png +featured: true +weight: 4 +quote: > + Ми прийняли правильні рішення в потрібний час. Kubernetes та технології хмарних середовищ тепер вважаються стандартною екосистемою. + +new_case_study_styles: true +heading_background: /images/case-studies/appdirect/banner1.jpg +heading_title_logo: /images/appdirect_logo.png +subheading: > + AppDirect: How AppDirect Supported the 10x Growth of Its Engineering Staff with Kubernetes +case_study_details: + - Company: AppDirect + - Location: San Francisco, California + - Industry: Software +--- + +

Challenge

+ +

AppDirect provides an end-to-end commerce platform for cloud-based products and services. When Director of Software Development Pierre-Alexandre Lacerte began working there in 2014, the company had a monolith application deployed on a "tomcat infrastructure, and the whole release process was complex for what it should be," he says. "There were a lot of manual steps involved, with one engineer building a feature, then another team picking up the change. So you had bottlenecks in the pipeline to ship a feature to production." At the same time, the engineering team was growing, and the company realized it needed a better infrastructure to both support that growth and increase velocity.

+ +

Solution

+ +

"My idea was: Let's create an environment where teams can deploy their services faster, and they will say, 'Okay, I don't want to build in the monolith anymore. I want to build a service,'" says Lacerte. They considered and prototyped several different technologies before deciding to adopt Kubernetes in early 2016. Lacerte's team has also integrated Prometheus monitoring into the platform; tracing is next. Today, AppDirect has more than 50 microservices in production and 15 Kubernetes clusters deployed on AWS and on premise around the world.

+ +

Impact

+ +

The Kubernetes platform has helped support the engineering team's 10x growth over the past few years. Coupled with the fact that they were continually adding new features, Lacerte says, "I think our velocity would have slowed down a lot if we didn't have this new infrastructure." Moving to Kubernetes and services has meant that deployments have become much faster due to less dependency on custom-made, brittle shell scripts with SCP commands. Time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn't require Jira tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before. The company also achieved cost savings by moving its marketplace and billing monoliths to Kubernetes from legacy EC2 hosts as well as by leveraging autoscaling, as traffic is higher during business hours.

+ +{{< case-studies/quote author="Alexandre Gervais, Staff Software Developer, AppDirect" >}} +"It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed." +{{< /case-studies/quote >}} + +{{< case-studies/lead >}} +With its end-to-end commerce platform for cloud-based products and services, AppDirect has been helping organizations such as Comcast and GoDaddy simplify the digital supply chain since 2009. +{{< /case-studies/lead >}} + +

When Director of Software Development Pierre-Alexandre Lacerte started working there in 2014, the company had a monolith application deployed on a "tomcat infrastructure, and the whole release process was complex for what it should be," he says. "There were a lot of manual steps involved, with one engineer building a feature then creating a pull request, and a QA or another engineer validating the feature. Then it gets merged and someone else will take care of the deployment. So we had bottlenecks in the pipeline to ship a feature to production."

+ +

At the same time, the engineering team of 40 was growing, and the company wanted to add an increasing number of features to its products. As a member of the platform team, Lacerte began hearing from multiple teams that wanted to deploy applications using different frameworks and languages, from Node.js to Spring Boot Java. He soon realized that in order to both support growth and increase velocity, the company needed a better infrastructure, and a system in which teams are autonomous, can do their own deploys, and be responsible for their services in production.

+ +{{< case-studies/quote + image="/images/case-studies/appdirect/banner3.jpg" + author="Alexandre Gervais, Staff Software Developer, AppDirect" +>}} +"We made the right decisions at the right time. Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team." +{{< /case-studies/quote >}} + +

From the beginning, Lacerte says, "My idea was: Let's create an environment where teams can deploy their services faster, and they will say, 'Okay, I don't want to build in the monolith anymore. I want to build a service.'" (Lacerte left the company in 2019.)

+ +

Working with the operations team, Lacerte's group got more control and access to the company's AWS infrastructure, and started prototyping several orchestration technologies. "Back then, Kubernetes was a little underground, unknown," he says. "But we looked at the community, the number of pull requests, the velocity on GitHub, and we saw it was getting traction. And we found that it was much easier for us to manage than the other technologies."

+ +

They spun up the first few services on Kubernetes using Chef and Terraform provisioning, and as more services were added, more automation was, too. "We have clusters around the world—in Korea, in Australia, in Germany, and in the U.S.," says Lacerte. "Automation is critical for us." They're now largely using Kops, and are looking at managed Kubernetes offerings from several cloud providers.

+ +

Today, though the monolith still exists, there are fewer and fewer commits and features. All teams are deploying on the new infrastructure, and services are the norm. AppDirect now has more than 50 microservices in production and 15 Kubernetes clusters deployed on AWS and on premise around the world.

+ +

Lacerte's strategy ultimately worked because of the very real impact the Kubernetes platform has had to deployment time. Due to less dependency on custom-made, brittle shell scripts with SCP commands, time to deploy a new version has shrunk from 4 hours to a few minutes. Additionally, the company invested a lot of effort to make things self-service for developers. "Onboarding a new service doesn't require Jira tickets or meeting with three different teams," says Lacerte. Today, the company sees 1,600 deployments per week, compared to 1-30 before.

+ +{{< case-studies/quote + image="/images/case-studies/appdirect/banner4.jpg" + author="Pierre-Alexandre Lacerte, Director of Software Development, AppDirect" +>}} +"I think our velocity would have slowed down a lot if we didn't have this new infrastructure." +{{< /case-studies/quote >}} + +

Additionally, the Kubernetes platform has helped support the engineering team's 10x growth over the past few years. "Ownership, a core value of AppDirect, reflects in our ability to ship services independently of our monolith code base," says Staff Software Developer Alexandre Gervais, who worked with Lacerte on the initiative. "Small teams now own critical parts of our business domain model, and they operate in their decoupled domain of expertise, with limited knowledge of the entire codebase. This reduces and isolates some of the complexity." Coupled with the fact that they were continually adding new features, Lacerte says, "I think our velocity would have slowed down a lot if we didn't have this new infrastructure."

+ +

The company also achieved cost savings by moving its marketplace and billing monoliths to Kubernetes from legacy EC2 hosts as well as by leveraging autoscaling, as traffic is higher during business hours.

+ +

AppDirect's cloud native stack also includes gRPC and Fluentd, and the team is currently working on setting up OpenCensus. The platform already has Prometheus integrated, so "when teams deploy their service, they have their notifications, alerts and configurations," says Lacerte. "For example, in the test environment, I want to get a message on Slack, and in production, I want a Slack message and I also want to get paged. We have integration with pager duty. Teams have more ownership on their services."

+ +{{< case-studies/quote author="Pierre-Alexandre Lacerte, Director of Software Development, AppDirect" >}} +"We moved from a culture limited to 'pushing code in a branch' to exciting new responsibilities outside of the code base: deployment of features and configurations; monitoring of application and business metrics; and on-call support in case of outages. It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed." +{{< /case-studies/quote >}} + +

That of course also means more responsibility. "We asked engineers to expand their horizons," says Gervais. "We moved from a culture limited to 'pushing code in a branch' to exciting new responsibilities outside of the code base: deployment of features and configurations; monitoring of application and business metrics; and on-call support in case of outages. It was an immense engineering culture shift, but the benefits are undeniable in terms of scale and speed."

+ +

As the engineering ranks continue to grow, the platform team has a new challenge, of making sure that the Kubernetes platform is accessible and easily utilized by everyone. "How can we make sure that when we add more people to our team that they are efficient, productive, and know how to ramp up on the platform?" Lacerte says. So we have the evangelists, the documentation, some project examples. We do demos, we have AMA sessions. We're trying different strategies to get everyone's attention."

+ +

Three and a half years into their Kubernetes journey, Gervais feels AppDirect "made the right decisions at the right time," he says. "Kubernetes and the cloud native technologies are now seen as the de facto ecosystem. We know where to focus our efforts in order to tackle the new wave of challenges we face as we scale out. The community is so active and vibrant, which is a great complement to our awesome internal team. Going forward, our focus will really be geared towards benefiting from the ecosystem by providing added business value in our day-to-day operations."

diff --git a/content/uk/case-studies/babylon/index.html b/content/uk/case-studies/babylon/index.html new file mode 100644 index 0000000000000..821261135b610 --- /dev/null +++ b/content/uk/case-studies/babylon/index.html @@ -0,0 +1,84 @@ +--- +title: Babylon Case Study +linkTitle: Babylon +case_study_styles: true +cid: caseStudies +logo: babylon_featured_logo.svg +featured: true +weight: 1 +quote: > + Кубернетес – це чудова платформа для машинного навчання, оскільки вона має всі необхідні планувальники та масштабованість. + +new_case_study_styles: true +heading_background: /images/case-studies/babylon/banner4.jpg +heading_title_text: Babylon +use_gradient_overlay: true +subheading: > + AppDirect: How Cloud Native Is Enabling Babylon's Medical AI Innovations +case_study_details: + - 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.

+ +{{< case-studies/quote + image="/images/case-studies/babylon/banner1.jpg" + author="JÉRÉMIE VALLÉE, AI INFRASTRUCTURE LEAD AT BABYLON" +>}} +"Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need." +{{< /case-studies/quote >}} + +{{< case-studies/lead >}} +Babylon's mission is to put accessible and affordable healthcare services in the hands of every person on earth. +{{< /case-studies/lead >}} + +

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.

+ +{{< case-studies/quote author="CAROLINE HARGROVE, CHIEF TECHNOLOGY OFFICER AT BABYLON" >}} +"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." +{{< /case-studies/quote >}} + +

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

+ +{{< case-studies/quote + image="/images/case-studies/babylon/banner2.jpg" + author="JEAN MARIE FERDEGUE, DIRECTOR OF PLATFORM OPERATIONS AT BABYLON" +>}} +"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." +{{< /case-studies/quote >}} + +

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/uk/case-studies/booking-com/booking.com_featured_logo.png b/content/uk/case-studies/booking-com/booking.com_featured_logo.png new file mode 100644 index 0000000000000..623ca67345be5 Binary files /dev/null and b/content/uk/case-studies/booking-com/booking.com_featured_logo.png differ diff --git a/content/uk/case-studies/booking-com/booking.com_featured_logo.svg b/content/uk/case-studies/booking-com/booking.com_featured_logo.svg new file mode 100644 index 0000000000000..0b245c27001af --- /dev/null +++ b/content/uk/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/uk/case-studies/booking-com/index.html b/content/uk/case-studies/booking-com/index.html new file mode 100644 index 0000000000000..570fc75bb6f1c --- /dev/null +++ b/content/uk/case-studies/booking-com/index.html @@ -0,0 +1,86 @@ +--- +title: Booking.com Case Study +linkTitle: Booking.com +case_study_styles: true +cid: caseStudies +logo: booking.com_featured_logo.png +featured: true +weight: 3 +quote: > + Ми зрозуміли, що нам потрібно більше дізнатись про Kubernetes, щоб повністю використовувати його потенціал. На цьому етапі ми зробили крок до створення власної платформи Kubernetes. + +new_case_study_styles: true +heading_background: /images/case-studies/booking/banner1.jpg +heading_title_text: Booking.com +use_gradient_overlay: true +subheading: > + After Learning the Ropes with a Kubernetes Distribution, Booking.com Built a Platform of Its Own +case_study_details: + - 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.

+ +{{< case-studies/quote + image="/images/case-studies/booking/banner2.jpg" + author="BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM" +>}} +"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." +{{< /case-studies/quote >}} + +​{{< case-studies/lead >}} +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. +{{< /case-studies/lead >}} + +

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.

+ +{{< case-studies/quote author="EDUARD IACOBOAIA, SENIOR SYSTEM ADMINISTRATOR, B PLATFORM TRACK AT BOOKING.COM" >}} +"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." +{{< /case-studies/quote >}} + +

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

+ +{{< case-studies/quote + image="/images/case-studies/booking/banner3.jpg" + author="BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM" +>}} +"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." +{{< /case-studies/quote >}} + +

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/uk/case-studies/booz-allen/booz-allen-featured-logo.svg b/content/uk/case-studies/booz-allen/booz-allen-featured-logo.svg new file mode 100644 index 0000000000000..3ce58c68f7858 --- /dev/null +++ b/content/uk/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/uk/case-studies/booz-allen/booz-allen_featured_logo.png b/content/uk/case-studies/booz-allen/booz-allen_featured_logo.png new file mode 100644 index 0000000000000..f9bc64ba3bd2b Binary files /dev/null and b/content/uk/case-studies/booz-allen/booz-allen_featured_logo.png differ diff --git a/content/uk/case-studies/booz-allen/index.html b/content/uk/case-studies/booz-allen/index.html new file mode 100644 index 0000000000000..607a635ec092e --- /dev/null +++ b/content/uk/case-studies/booz-allen/index.html @@ -0,0 +1,80 @@ +--- +title: Booz Allen Case Study +linkTitle: Booz Allen Hamilton +case_study_styles: true +cid: caseStudies +logo: booz-allen-featured-logo.svg +featured: true +weight: 2 +quote: > + Kubernetes є гарним рішенням для нас. Він дозволяє нам швидко реагувати на вимоги наших клієнтів. + +new_case_study_styles: true +heading_background: /images/case-studies/booz-allen/banner4.jpg +heading_title_text: Booz Allen Hamilton +use_gradient_overlay: true +subheading: > + How Booz Allen Hamilton Is Helping Modernize the Federal Government with Kubernetes +case_study_details: + - 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.

+ +{{< case-studies/quote + image="/images/case-studies/booz-allen/banner2.jpg" + author="JOSH BOYD, CHIEF TECHNOLOGIST AT BOOZ ALLEN HAMILTON" +>}} +"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." +{{< /case-studies/quote >}} +​ +​{{< case-studies/lead >}} +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. +{{< /case-studies/lead >}} + +

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.

+ +{{< case-studies/quote author="MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON" >}} +"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." +{{< /case-studies/quote >}} + +

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.

+​ +{{< case-studies/quote + image="/images/case-studies/booz-allen/banner1.png" + author="MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON" +>}} +"Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day's event" +{{< /case-studies/quote >}} + +

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/uk/docs/_index.md b/content/uk/docs/_index.md index a601666b678f9..b390c8f021035 100644 --- a/content/uk/docs/_index.md +++ b/content/uk/docs/_index.md @@ -1,3 +1,6 @@ --- +linktitle: Документація Kubernetes title: Документація +sitemap: + priority: 1.0 --- diff --git a/content/uk/docs/concepts/_index.md b/content/uk/docs/concepts/_index.md index ab9d757e99679..39d39d2bff622 100644 --- a/content/uk/docs/concepts/_index.md +++ b/content/uk/docs/concepts/_index.md @@ -7,118 +7,6 @@ weight: 40 - -В розділі "Концепції" описані складові системи Kubernetes і абстракції, за допомогою яких Kubernetes реалізовує ваш {{< glossary_tooltip text="кластер" term_id="cluster" length="all" >}}. Цей розділ допоможе вам краще зрозуміти, як працює Kubernetes. - - +Розділ "Концепції" допоможе вам дізнатися про складові системи Kubernetes та абстракції, які використовує Kubernetes для представлення вашого {{< glossary_tooltip text="кластера" term_id="cluster" length="all" >}}, і допоможе вам краще зрозуміти, як працює Kubernetes. - - - -## Загальна інформація - - -Для роботи з Kubernetes ви використовуєте *об'єкти API Kubernetes* для того, щоб описати *бажаний стан* вашого кластера: які застосунки або інші робочі навантаження ви плануєте запускати, які образи контейнерів вони використовують, кількість реплік, скільки ресурсів мережі та диску ви хочете виділити тощо. Ви задаєте бажаний стан, створюючи об'єкти в Kubernetes API, зазвичай через інтерфейс командного рядка `kubectl`. Ви також можете взаємодіяти із кластером, задавати або змінювати його бажаний стан безпосередньо через Kubernetes API. - - -Після того, як ви задали бажаний стан, *площина управління Kubernetes* приводить поточний стан кластера до бажаного за допомогою Pod Lifecycle Event Generator ([PLEG](https://github.com/kubernetes/design-proposals-archive/blob/main/node/pod-lifecycle-event-generator.md)). Для цього Kubernetes автоматично виконує ряд задач: запускає або перезапускає контейнери, масштабує кількість реплік у певному застосунку тощо. Площина управління Kubernetes складається із набору процесів, що виконуються у вашому кластері: - - - -* **Kubernetes master** становить собою набір із трьох процесів, запущених на одному вузлі вашого кластера, що визначений як керівний (master). До цих процесів належать: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) і [kube-scheduler](/docs/admin/kube-scheduler/). -* На кожному не-мастер вузлі вашого кластера виконуються два процеси: - * **[kubelet](/docs/admin/kubelet/)**, що обмінюється даними з Kubernetes master. - * **[kube-proxy](/docs/admin/kube-proxy/)**, мережевий проксі, що відображає мережеві сервіси Kubernetes на кожному вузлі. - - - -## Об'єкти Kubernetes - - -Kubernetes оперує певною кількістю абстракцій, що відображають стан вашої системи: розгорнуті у контейнерах застосунки та робочі навантаження, пов'язані з ними ресурси мережі та диску, інша інформація щодо функціонування вашого кластера. Ці абстракції представлені як об'єкти Kubernetes API. Для більш детальної інформації ознайомтесь з [Об'єктами Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects/). - - -До базових об'єктів Kubernetes належать: - -* [Pod](/docs/concepts/workloads/pods/pod-overview/) -* [Service](/docs/concepts/services-networking/service/) -* [Volume](/docs/concepts/storage/volumes/) -* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) - - -В Kubernetes є також абстракції вищого рівня, які надбудовуються над базовими об'єктами за допомогою [контролерів](/docs/concepts/architecture/controller/) і забезпечують додаткову функціональність і зручність. До них належать: - -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) -* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) - - - -## Площина управління Kubernetes (*Kubernetes Control Plane*) {#площина-управління-kubernetes} - - -Різні частини площини управління Kubernetes, такі як Kubernetes Master і kubelet, регулюють, як Kubernetes спілкується з вашим кластером. Площина управління веде облік усіх об'єктів Kubernetes в системі та безперервно, в циклі перевіряє стан цих об'єктів. У будь-який момент часу контрольні цикли, запущені площиною управління, реагуватимуть на зміни у кластері і намагатимуться привести поточний стан об'єктів до бажаного, що заданий у конфігурації. - - -Наприклад, коли за допомогою API Kubernetes ви створюєте Deployment, ви задаєте новий бажаний стан для системи. Площина управління Kubernetes фіксує створення цього об'єкта і виконує ваші інструкції шляхом запуску потрібних застосунків та їх розподілу між вузлами кластера. В такий спосіб досягається відповідність поточного стану бажаному. - - - -### Kubernetes Master - - -Kubernetes Master відповідає за підтримку бажаного стану вашого кластера. Щоразу, як ви взаємодієте з Kubernetes, наприклад при використанні інтерфейсу командного рядка `kubectl`, ви обмінюєтесь даними із Kubernetes master вашого кластера. - - -Слово "master" стосується набору процесів, які управляють станом кластера. Переважно всі ці процеси виконуються на одному вузлі кластера, який також називається master. Master-вузол можна реплікувати для забезпечення високої доступності кластера. - - - -### Вузли Kubernetes - - -Вузлами кластера називають машини (ВМ, фізичні сервери тощо), на яких запущені ваші застосунки та хмарні робочі навантаження. Кожен вузол керується Kubernetes master; ви лише зрідка взаємодіятимете безпосередньо із вузлами. - - - - -## {{% heading "whatsnext" %}} - - - -Якщо ви хочете створити нову сторінку у розділі Концепції, у статті -[Використання шаблонів сторінок](/docs/home/contribute/page-templates/) -ви знайдете інформацію щодо типу і шаблона сторінки. - - diff --git a/content/uk/docs/concepts/architecture/_index.md b/content/uk/docs/concepts/architecture/_index.md new file mode 100644 index 0000000000000..d1a2acf94af1a --- /dev/null +++ b/content/uk/docs/concepts/architecture/_index.md @@ -0,0 +1,8 @@ +--- +title: "Архітектура кластера" +weight: 30 +description: > + Архітектурні концепції в основі Kubernetes. +--- + +{{< figure src="/images/docs/kubernetes-cluster-architecture.svg" alt="Компоненти Kubernetes" caption="Архітектура кластера Kubernetes" class="diagram-large" >}} diff --git a/content/uk/docs/concepts/architecture/cgroups.md b/content/uk/docs/concepts/architecture/cgroups.md new file mode 100644 index 0000000000000..e34b5f59bd1bf --- /dev/null +++ b/content/uk/docs/concepts/architecture/cgroups.md @@ -0,0 +1,101 @@ +--- +title: Про cgroup v2 +content_type: concept +weight: 50 +--- + + + +У Linux {{< glossary_tooltip text="control groups" term_id="cgroup" >}} обмежують ресурси, які виділяються процесам. + +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} та середовище виконання контейнерів повинні співпрацювати з cgroups для забезпечення [управління ресурсами для Podʼів та контейнерів](/docs/concepts/configuration/manage-resources-containers/), що включає запити та обмеження на CPU/памʼяті для контейнеризованих навантажень. + +Є дві версії cgroups у Linux: cgroup v1 і cgroup v2. cgroup v2 — це нове покоління API `cgroup` в Linux. + + + +## Що таке cgroup v2? {#cgroup-v2} + +{{< feature-state for_k8s_version="v1.25" state="stable" >}} + +cgroup v2 — це наступне покоління API Linux `cgroup`. cgroup v2 надає єдину систему управління з розширеними можливостями управління ресурсами. + +cgroup v2 пропонує кілька поліпшень порівняно з cgroup v1, таких як: + +- Один уніфікований дизайн ієрархії в API +- Безпечне делегування піддерева контейнерам +- Нові можливості, такі як [Pressure Stall Information](https://www.kernel.org/doc/html/latest/accounting/psi.html) +- Розширене управління розподілом ресурсів та ізоляція між різними ресурсами + - Обʼєднаний облік різних типів виділення памʼяті (мережева памʼять, памʼять ядра і т. д.) + - Облік негайних змін ресурсів, таких як запис кешу сторінок + +Деякі можливості Kubernetes використовують виключно cgroup v2 для поліпшення управління ресурсами та ізоляцією. Наприклад, можливість [MemoryQoS](/blog/2021/11/26/qos-memory-resources/) покращує якість обслуговування памʼяті та покладається на примітиви cgroup v2. + +## Використання cgroup v2 {#using-cgroupv2} + +Рекомендованим способом використання cgroup v2 є використання дистрибутиву Linux, який типово має та використовує cgroup v2. + +Щоб перевірити, чи ваш дистрибутив використовує cgroup v2, див. [Визначення версії cgroup на вузлах Linux](#check-cgroup-version). + +### Вимоги {#requirements} + +cgroup v2 має наступні вимоги: + +- Дистрибутив ОС включає cgroup v2 +- Версія ядра Linux — 5.8 або пізніше +- Середовище виконання контейнерів підтримує cgroup v2. Наприклад: + - [containerd](https://containerd.io/) v1.4 і новіше + - [cri-o](https://cri-o.io/) v1.20 і новіше +- kubelet та середовище виконання контейнерів налаштовані на використання [cgroup-драйвера systemd](/docs/setup/production-environment/container-runtimes#systemd-cgroup-driver) + +### Підтримка cgroup v2 дистрибутивами Linux {#linux-distribution-cgroup-v2-support} + +Для ознайомлення зі списком дистрибутивів Linux, які використовують cgroup v2, див. [документацію cgroup v2](https://github.com/opencontainers/runc/blob/main/docs/cgroup-v2.md) + + +- Container Optimized OS (з версії M97) +- Ubuntu (з версії 21.10, рекомендовано 22.04+) +- Debian GNU/Linux (з Debian 11 bullseye) +- Fedora (з версії 31) +- Arch Linux (з квітня 2021) +- RHEL та схожі дистрибутиви (з версії 9) + +Щоб перевірити, чи ваш дистрибутив використовує cgroup v2, див. документацію вашого дистрибутиву або скористайтеся інструкціями в [Визначенні версії cgroup на вузлах Linux](#check-cgroup-version). + +Також можна включити cgroup v2 вручну у вашому дистрибутиві Linux, змінивши аргументи завантаження ядра. Якщо ваш дистрибутив використовує GRUB, `systemd.unified_cgroup_hierarchy=1` повинно бути додано в `GRUB_CMDLINE_LINUX` в `/etc/default/grub`, а потім виконайте `sudo update-grub`. Однак рекомендованим підходом є використання дистрибутиву, який вже стандартно має cgroup v2. + +### Міграція на cgroup v2 {#migrating-cgroupv2} + +Щоб перейти на cgroup v2, переконайтеся, що ваша система відповідаєте [вимогам](#requirements), а потім оновіть її до версії ядра, яка стандартно має cgroup v2. + +Kubelet автоматично виявляє, що ОС працює з cgroup v2 і виконує відповідно без додаткової конфігурації. + +При переході на cgroup v2 не повинно бути помітної різниці в використані, якщо користувачі не звертаються безпосередньо до файлової системи cgroup чи на вузлі, чи зсередини контейнерів. + +cgroup v2 використовує інший API, ніж cgroup v1, тому, якщо є застосунки, які безпосередньо отримують доступ до файлової системи cgroup, вони повинні бути оновлені до новіших версій, які підтримують cgroup v2. Наприклад: + +- Деякі сторонні агенти моніторингу та безпеки можуть залежати від файлової системи cgroup. Оновіть ці агенти до версій, які підтримують cgroup v2. +- Якщо ви використовуєте [cAdvisor](https://github.com/google/cadvisor) як окремий DaemonSet для моніторингу Podʼів та контейнерів, оновіть його до v0.43.0 чи новіше. +- Якщо ви розгортаєте Java-застосунки, віддайте перевагу використанню версій, які повністю підтримують cgroup v2: + - [OpenJDK / HotSpot](https://bugs.openjdk.org/browse/JDK-8230305): jdk8u372, 11.0.16, 15 та пізніше + - [IBM Semeru Runtimes](https://www.ibm.com/support/pages/apar/IJ46681): 8.0.382.0, 11.0.20.0, 17.0.8.0 та пізніше + - [IBM Java](https://www.ibm.com/support/pages/apar/IJ46681): 8.0.8.6 та пізніше +- Якщо ви використовуєте пакунок [uber-go/automaxprocs](https://github.com/uber-go/automaxprocs), переконайтеся, що ви використовуєте версію v1.5.1 чи вище. + +## Визначення версії cgroup на вузлах Linux {#check-cgroup-version} + +Версія cgroup залежить від використаного дистрибутиву Linux та версії cgroup, налаштованої в ОС. Щоб перевірити, яка версія cgroup використовується вашим дистрибутивом, виконайте команду `stat -fc %T /sys/fs/cgroup/` на вузлі: + +```shell +stat -fc %T /sys/fs/cgroup/ +``` + +Для cgroup v2 вивід — `cgroup2fs`. + +Для cgroup v1 вивід — `tmpfs.` + +## {{% heading "whatsnext" %}} + +- Дізнайтеся більше про [cgroups](https://man7.org/linux/man-pages/man7/cgroups.7.html) +- Дізнайтеся більше про [середовище виконання контейнерів](/docs/concepts/architecture/cri) +- Дізнайтеся більше про [драйвери cgroup](/docs/setup/production-environment/container-runtimes#cgroup-drivers) diff --git a/content/uk/docs/concepts/architecture/cloud-controller.md b/content/uk/docs/concepts/architecture/cloud-controller.md new file mode 100644 index 0000000000000..17b108fb305d9 --- /dev/null +++ b/content/uk/docs/concepts/architecture/cloud-controller.md @@ -0,0 +1,184 @@ +--- +title: Cloud Controller Manager +content_type: concept +weight: 40 +--- + + + +{{< feature-state state="beta" for_k8s_version="v1.11" >}} + +Технології хмарної інфраструктури дозволяють вам запускати Kubernetes в публічних, приватних та гібридних хмарах. Kubernetes вірить в автоматизовану інфраструктуру, що працює за допомогою API без тісного звʼязку між компонентами. + +{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="Сloud-controller-manager це">}} + +Cloud-controller-manager структурується з допомогою механізму втулків, який дозволяє різним постачальникам хмар інтегрувати свої платформи з Kubernetes. + + + +## Дизайн {#design} + +![Компоненти Kubernetes](/images/docs/components-of-kubernetes.svg) + +Менеджер контролера хмар працює в панелі управління як реплікований набір процесів (зазвичай це контейнери в Podʼах). Кожен контролер хмар реалізує кілька {{< glossary_tooltip text="контролерів" term_id="controller" >}} в одному процесі. + +{{< note >}} +Ви також можете запускати менеджер контролера хмар як {{< glossary_tooltip text="надбудову" term_id="addons" >}} Kubernetes, а не як частину панелі управління. +{{< /note >}} + +## Функції менеджера контролера хмар {#functions-of-the-ccm} + +Контролери всередині менеджера контролера хмар складаються з: + +### Контролер Node {#node-controller} + +Контролер Node відповідає за оновлення обʼєктів {{< glossary_tooltip text="Node" term_id="node" >}} при створенні нових серверів у вашій хмарній інфраструктурі. Контролер Node отримує інформацію про хости, які працюють у вашому оточені у хмарному провайдері. Контролер Node виконує наступні функції: + +1. Оновлення обʼєкта Node відповідним унікальним ідентифікатором сервера, отриманим з API постачальника хмари. +2. Анотація та маркування обʼєкта Node хмароспецифічною інформацією, такою як регіон, в якому розгорнуто вузол, та ресурси (CPU, памʼять і т. д.), якими він володіє. +3. Отримання імені хосту та мережевих адрес. +4. Перевірка стану вузла. У випадку, якщо вузол стає непридатним для відповіді, цей контролер перевіряє за допомогою API вашого постачальника хмари, чи сервер був деактивований / видалений / завершений. Якщо вузол був видалений з хмари, контролер видаляє обʼєкт Node з вашого кластера Kubernetes. + +Деякі реалізації від постачальників хмар розділяють це на контролер Node та окремий контролер життєвого циклу вузла. + +### Контролер Route {#route-controller} + +Контролер Route відповідає за налаштування маршрутів у хмарі відповідним чином, щоб контейнери на різних вузлах вашого Kubernetes кластера могли спілкуватися один з одним. + +Залежно від постачальника хмари, контролер Route може також виділяти блоки IP-адрес для мережі Podʼу. + +### Контролер Service {#service-controller} + +{{< glossary_tooltip text="Services" term_id="service" >}} інтегруються з компонентами хмарної інфраструктури, такими як керовані балансувальники трафіку, IP-адреси, мережеве фільтрування пакетів та перевірка стану цільового обʼєкта. Контролер Service взаємодіє з API вашого постачальника хмари для налаштування балансувальника навантаження та інших компонентів інфраструктури, коли ви оголошуєте ресурс Service, який вимагає їх. + +## Авторизація {#authorization} + +У цьому розділі розглядаються доступи, яких вимагає менеджер контролера хмар для різних обʼєктів API для виконання своїх операцій. + +### Контролер Node {#authorization-node-controller} + +Контролер Node працює тільки з обʼєктами Node. Він вимагає повного доступу для читання та модифікації обʼєктів Node. + +`v1/Node`: + +- get +- list +- create +- update +- patch +- watch +- delete + +### Контролер Route {#authorization-route-controller} + +Контролер Route відстежує створення обʼєктів Node та налаштовує маршрути відповідним чином. Він вимагає доступу Get до обʼєктів Node. + +`v1/Node`: + +- get + +### Контролер Service {#authorization-service-controller} + +Контролер Service відстежує події **create**, **update** та **delete** обʼєктів та після цього налаштовує Endpoints для цих Service відповідним чином (для EndpointSlices менеджер kube-controller-manager керує ними за запитом). + +Для доступу до Service потрібні доступи **list** та **watch**. Для оновлення Service потрібен доступ **patch** та **update**. + +Для налаштування ресурсів Endpoints для Service потрібен доступ до **create**, **list**, **get**, **watch** та **update**. + +`v1/Service`: + +- list +- get +- watch +- patch +- update + +### Інші {#authorization-miscellaneous} + +Реалізація основи менеджера контролера хмар потребує доступу до створення Event та для забезпечення безпечної роботи він потребує доступу до створення ServiceAccounts. + +`v1/Event`: + +- create +- patch +- update + +`v1/ServiceAccount`: + +- create + +{{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для менеджера контролера хмар виглядає наступним чином: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: cloud-controller-manager +rules: +- apiGroups: + - "" + resources: + - events + verbs: + - create + - patch + - update +- apiGroups: + - "" + resources: + - nodes + verbs: + - '*' +- apiGroups: + - "" + resources: + - nodes/status + verbs: + - patch +- apiGroups: + - "" + resources: + - services + verbs: + - list + - patch + - update + - watch +- apiGroups: + - "" + resources: + - serviceaccounts + verbs: + - create +- apiGroups: + - "" + resources: + - persistentvolumes + verbs: + - get + - list + - update + - watch +- apiGroups: + - "" + resources: + - endpoints + verbs: + - create + - get + - list + - watch + - update +``` + +## {{% heading "whatsnext" %}} + +- [Адміністрування менеджера контролера хмар](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) містить інструкції щодо запуску та управління менеджером контролера хмар. + +- Щодо оновлення панелі управління з розділеною доступністю для використання менеджера контролера хмар, див. [Міграція реплікованої панелі управління для використання менеджера контролера хмар](/docs/tasks/administer-cluster/controller-manager-leader-migration/). + +- Хочете знати, як реалізувати свій власний менеджер контролера хмар або розширити поточний проєкт? + + - Менеджер контролера хмар використовує інтерфейси Go, зокрема, інтерфейс `CloudProvider`, визначений у [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69) з [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider), щоб дозволити використовувати імплементації з будь-якої хмари. + - Реалізація загальних контролерів, виділених у цьому документі (Node, Route та Service), разом із загальним інтерфейсом хмарного постачальника, є частиною ядра Kubernetes. Реалізації, специфічні для постачальників хмари, знаходяться поза ядром Kubernetes і реалізують інтерфейс `CloudProvider`. + - Для отримання додаткової інформації щодо розробки втулків, див. [Розробка менеджера контролера хмар](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). diff --git a/content/uk/docs/concepts/architecture/control-plane-node-communication.md b/content/uk/docs/concepts/architecture/control-plane-node-communication.md new file mode 100644 index 0000000000000..43c833c01c87b --- /dev/null +++ b/content/uk/docs/concepts/architecture/control-plane-node-communication.md @@ -0,0 +1,78 @@ +--- +reviewers: +- dchen1107 +- liggitt +title: Звʼязок між Вузлами та Панеллю управління +content_type: concept +weight: 20 +aliases: +- master-node-communication +--- + + + +Цей документ описує шляхи звʼязку між {{< glossary_tooltip term_id="kube-apiserver" text="API-сервером" >}} та {{< glossary_tooltip text="кластером" term_id="cluster" length="all" >}} Kubernetes. Мета — надати користувачам можливість налаштувати їхнє встановлення для зміцнення конфігурації мережі так, щоб кластер можна було запускати в ненадійній мережі (або на повністю публічних IP-адресах у хмарному середовищі). + + + +## Вузол до Панелі управління {#node-to-control-plane} + +У Kubernetes існує шаблон API "hub-and-spoke". Всі використання API вузлів (або Podʼів, які вони виконують) завершуються на API-сервері. Інші компоненти панелі управління не призначені для витіснення віддалених служб. API-сервер налаштований для прослуховування віддалених підключень на захищеному порту HTTPS (зазвичай 443) з однією або декількома формами [автентифікації клієнта](/docs/reference/access-authn-authz/authentication/). Рекомендується включити одну чи кілька форм [авторизації](/docs/reference/access-authn-authz/authorization/), особливо якщо [анонімні запити](/docs/reference/access-authn-authz/authentication/#anonymous-requests) або [токени облікового запису служби](/docs/reference/access-authn-authz/authentication/#service-account-tokens) дозволені. + +Вузли повинні бути забезпечені загальним кореневим {{< glossary_tooltip text="сертифікатом" term_id="certificate" >}} для кластера, щоб вони могли безпечно підключатися до API-сервера разом з дійсними обліковими даними клієнта. Добрим підходом є те, що облікові дані клієнта, які надаються kubelet, мають форму сертифіката клієнта. Див. [завантаження TLS kubelet](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) для автоматичного забезпечення облікових даних клієнта kubelet. + +{{< glossary_tooltip text="Podʼи" term_id="pod" >}}, які бажають підʼєднатися до API-сервера, можуть це зробити безпечно, використовуючи обліковий запис служби (service account), так що Kubernetes автоматично вставлятиме загальний кореневий сертифікат та дійсний токен власника у Pod, коли він буде ініціалізований. Служба `kubernetes` (в просторі імен `default`) налаштована з віртуальною IP-адресою, яка перенаправляється (через `{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}`) на кінцеву точку HTTPS на API-сервері. + +Компоненти панелі управління також взаємодіють з API-сервером через захищений порт. + +В результаті, типовий режим роботи для зʼєднань від вузлів та Podʼів, що працюють на +вузлах, до панелі управління є захищеним і може працювати через ненадійні та/або публічні мережі. + +## Панель управління до вузла {#control-plane-to-node} + +Існують два основних шляхи звʼязку від панелі управління (API-сервера) до вузлів. Перший — від API-сервера до процесу {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, який працює на кожному вузлі в кластері. Другий — від API-сервера до будь-якого вузла, Podʼа чи Servoce через _проксі_ API-сервера. + +### API-сервер до kubelet {#api-server-to-kubelet} + +Підключення від API-сервера до kubelet використовуються для: + +* Отримання логів для Podʼів. +* Приєднання (зазвичай через `kubectl`) до запущених Podʼів. +* Забезпечення функціональності перенаправлення портів kubelet. + +Ці зʼєднання завершуються на кінцевій точці HTTPS kubelet. Стандартно API-сервер не +перевіряє сертифікат обслуговування kubelet, що робить зʼєднання вразливими до атаки "особа-посередині" і **небезпечними** для використання через ненадійні та/або публічні мережі. + +Щоб перевірити це зʼєднання, використовуйте прапорець `--kubelet-certificate-authority`, щоб надати API серверу пакет кореневих сертифікатів для перевірки сертифіката обслуговування kubelet. + +Якщо це неможливо, скористайтеся [тунелюванням SSH](#ssh-tunnels) між API-сервером та kubelet, якщо необхідно, щоб уникнути підключення через ненадійну або публічну мережу. + +### Від API-сервера до вузлів, подів та служб {#api-server-to-nodes-pods-and-services} + +Підключення від API-сервера до вузла, Podʼа чи служби типово використовують прості HTTP-зʼєднання і, отже, не автентифікуються або не шифруються. Їх можна використовувати через захищене зʼєднання HTTPS, підставивши `https:` перед назвою вузла, Podʼу чи служби в URL API, але вони не будуть перевіряти сертифікат, наданий кінцевою точкою HTTPS, та не надаватимуть облікові дані клієнта. Таким чином, хоча зʼєднання буде зашифрованим, воно не гарантує цілісності. Ці зʼєднання **поки не є безпечними** для використання через ненадійні або публічні мережі. + +### Тунелі SSH {#ssh-tunnels} + +Kubernetes підтримує [тунелі SSH](https://www.ssh.com/academy/ssh/tunneling), щоб захистити канали звʼязку від панелі управління до вузлів. У цій конфігурації API-сервер ініціює тунель SSH до кожного вузла в кластері (підключаючись до SSH-сервера, який прослуховує порт 22) і передає весь трафік, призначений для kubelet, вузла, Podʼа чи служби через тунель. Цей тунель гарантує, що трафік не виходить за межі мережі, в якій працюють вузли. + +{{< note >}} +Тунелі SSH наразі застарілі, тому ви не повинні вибирати їх для використання, якщо не знаєте, що робите. Служба [Konnectivity](#konnectivity-service) — це заміна для цього каналу звʼязку. +{{< /note >}} + +### Служба Konnectivity {#konnectivity-service} + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +Як заміна тунелям SSH, служба Konnectivity надає проксі на рівні TCP для звʼязку панелі управління з кластером. Служба Konnectivity складається з двох частин: сервера Konnectivity в мережі панелі управління та агентів Konnectivity в мережі вузлів. Агенти Konnectivity ініціюють зʼєднання з сервером Konnectivity та утримують мережеві підключення. Після ввімкнення служби Konnectivity весь трафік від панелі управління до вузлів прокладається через ці зʼєднання. + +Для налаштування служби Konnectivity у своєму кластері слідкуйте за завданням [служби Konnectivity](/docs/tasks/extend-kubernetes/setup-konnectivity/). + +## {{% heading "whatsnext" %}} + +* Дізнайтеся більше про [компоненти панелі управління Kubernetes](/docs/concepts/overview/components/#control-plane-components) +* Дізнайтеся більше про [модель "Hubs and Spoke"](https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html#hubs-spokes-and-other-wheel-metaphors) +* Дізнайтеся, як [захистити кластер](/docs/tasks/administer-cluster/securing-a-cluster/) +* Дізнайтеся більше про [API Kubernetes](/docs/concepts/overview/kubernetes-api/) +* [Налаштуйте службу Konnectivity](/docs/tasks/extend-kubernetes/setup-konnectivity/) +* [Використовуйте перенаправлення портів для доступу до застосунку у кластері](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) +* Дізнайтеся, як [отримати логи для Podʼів](/docs/tasks/debug/debug-application/debug-running-pod/#examine-pod-logs), [використовуйте kubectl port-forward](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod) diff --git a/content/uk/docs/concepts/architecture/controller.md b/content/uk/docs/concepts/architecture/controller.md new file mode 100644 index 0000000000000..85c085d303f76 --- /dev/null +++ b/content/uk/docs/concepts/architecture/controller.md @@ -0,0 +1,95 @@ +--- +title: Контролери +content_type: concept +weight: 30 +--- + + + +У робототехніці та автоматизації _control loop (цикл керування)_ — це необмежений цикл, який регулює стан системи. + +Ось один приклад control loop — термостат у кімнаті. + +Коли ви встановлюєте температуру, це означає, що ви повідомляєте термостату про _бажаний стан_. Фактична температура в кімнаті — це _поточний стан_. Термостат діє так, щоб наблизити поточний стан до бажаного стану, вмикаючи чи вимикаючи відповідне обладнання. + +{{< glossary_definition term_id="controller" length="short">}} + + + +## Шаблон контролер {#controller-pattern} + +Контролер відстежує принаймні один тип ресурсу Kubernetes. Ці {{< glossary_tooltip text="обʼєкти" term_id="object" >}} мають поле spec, яке представляє бажаний стан. Контролер(и) для цього ресурсу відповідають за наближення поточного стану до цього бажаного стану. + +Контролер може виконати дію самостійно; частіше в Kubernetes контролер надсилає повідомлення {{< glossary_tooltip text="API-серверу" term_id="kube-apiserver" >}}, які мають корисні побічні ефекти. Нижче ви побачите приклади цього. + +{{< comment >}} +Деякі вбудовані контролери, такі як контролер простору імен, діють на обʼєкти, що не мають політики. З метою спрощення ця сторінка пропускає пояснення цих деталей. +{{< /comment >}} + +### Управління через API-сервер {#control-via-api-server} + +Контролер {{< glossary_tooltip term_id="job" >}} — це приклад вбудованого контролера Kubernetes. Вбудовані контролери управляють станом, взаємодіючи з +API-сервером кластера. + +Job — це ресурс Kubernetes, який запускає {{< glossary_tooltip term_id="Pod" >}}, або може кілька Podʼів, щоб виконати завдання і потім зупинитися. + +(Після процесу [планування](/docs/concepts/scheduling-eviction/), обʼєкти Pod стають частиною бажаного стану для kubelet). + +Коли контролер Job бачить нове завдання, він переконується, що десь у вашому кластері kubelet на наборі вузлів виконують потрібну кількість Podʼів. Контролер Job не запускає жодних Podʼів або контейнерів самостійно. Замість цього контролер Job вказує API-серверу створити або видалити Podʼи. Інші компоненти +{{< glossary_tooltip text="панелі управління" term_id="control-plane" >}} працюють з новою інформацією (є нові Podʼи для планування та запуску), і, нарешті, робота виконана. + +Після того, як ви створите нове завдання, бажаний стан полягає в тому, щоб це завдання було завершене. Контролер Job робить поточний стан для цього завдання ближче до бажаного стану: створення Podʼів, які виконують роботу, яку ви хотіли для цього завдання, щоб завдання була ближчим до завершення. + +Контролери також оновлюють обʼєкти, які їх конфігурують. Наприклад, якщо робота виконана для завдання, контролер Job оновлює обʼєкт Job, щоб позначити його як `Finished`. + +(Це трошки схоже на те, як деякі термостати вимикають світловий індикатор, щоб сповістити, що ваша кімната тепер має температуру, яку ви встановили). + +### Безпосереднє управління {#direct-control} + +На відміну від Job, деякі контролери повинні вносити зміни в речі за межами вашого кластера. + +Наприклад, якщо ви використовуєте control loop, щоб переконатися, що у вашому кластері є достатньо {{< glossary_tooltip text="вузлів" term_id="node" >}}, то цей контролер потребує щось поза поточним кластером, щоб налаштувати нові вузли при необхідності. + +Контролери, які взаємодіють із зовнішнім станом, отримують свій бажаний стан від API-сервера, а потім безпосередньо спілкуються з зовнішньою системою для наближення поточного стану до бажаного. + +(Фактично є [контролер](https://github.com/kubernetes/autoscaler/) що горизонтально масштабує вузли у вашому кластері). + +Важливим тут є те, що контролер вносить певні зміни, щоб досягти вашого бажаного стану, а потім повідомляє поточний стан назад на API-сервер вашого кластера. Інші control loop можуть спостерігати за цим звітами та виконувати вже свої дії. + +У прикладі з термостатом, якщо в кімнаті дуже холодно, то інший контролер може також увімкнути обігрівач для захисту від морозу. У кластерах Kubernetes панель управління опосередковано працює з інструментами управління IP-адресами, службами сховища, API хмарних провайдерів та іншими службами, розширюючи [Kubernetes](/docs/concepts/extend-kubernetes/) для їх виконання. + +## Бажаний стан порівняно з поточним {#desired-vs-current} + +Kubernetes має хмарний вигляд систем і здатний обробляти постійні зміни. + +Ваш кластер може змінюватися в будь-який момент під час роботи, а цикли управління автоматично виправляють збої. Це означає, що, потенційно, ваш кластер ніколи не досягає стабільного стану. + +Поки контролери вашого кластера працюють і можуть робити корисні зміни, не має значення, чи є загальний стан сталим, чи ні. + +## Дизайн {#design} + +Як принцип дизайну, Kubernetes використовує багато контролерів, кожен з яких керує певним аспектом стану кластера. Найчастіше, певний цикл управління (контролер) використовує один вид ресурсу як свій бажаний стан, і має різні види ресурсу, якими він управляє, щоб задовольнити цей бажаний стан. Наприклад, контролер для ресурсу Job відстежує обʼєкти Job (для виявлення нової роботи) та обʼєкти Pod (для запуску робіт і потім визначення, коли робота закінчена). У цьому випадку щось інше створює роботи, тоді як контролер Job створює Podʼи. + +Корисно мати прості контролери, а не один великий набір взаємозалежних циклів управління. Контролери можуть виходити з ладу, тому Kubernetes спроектовано з урахуванням цього. + +{{< note >}} +У деяких контролерах може бути кілька контролерів, які створюють або оновлюють один і той же тип обʼєкта. За лаштунками контролери Kubernetes переконуються, що вони звертають увагу лише на ресурси, повʼязані з їх контрольним ресурсом. + +Наприклад, ви можете мати ресурси Deployments і Jobs; обидва ці ресурси створюють Podʼи. Контролер Job не видаляє Podʼи, які створив ваш Deployment, оскільки є інформація ({{< glossary_tooltip term_id="label" text="мітки" >}}) яку контролери можуть використовувати для розрізнення цих Podʼів. +{{< /note >}} + +## Способи використання контролерів {#running-controllers} + +Kubernetes постачається з набором вбудованих контролерів, які працюють всередині +{{< glossary_tooltip term_id="kube-controller-manager" >}}. Ці вбудовані контролери забезпечують важливі основні функції. + +Контролер Deployment та контролер Job — це приклади контролерів, які постачаються разом з Kubernetes (контролери, вбудовані в систему). Kubernetes дозволяє вам запускати надійну панель управління, так що, якщо будь-який з вбудованих контролерів не зможе виконувати завдання, інша частина панелі управління візьме на себе його обовʼязки. + +Ви можете знайти контролери, які працюють поза панеллю управління, для розширення Kubernetes. Або, якщо ви хочете, ви можете написати новий контролер самостійно. Ви можете запустити свій власний контролер як набір Podʼів, або поза межами Kubernetes. Те, що найкраще підходить, буде залежати від того, що саме робить цей контролер. + +## {{% heading "whatsnext" %}} + +* Прочитайте про [панель уіправління Kubernetes](/docs/concepts/overview/components/#control-plane-components) +* Дізнайтеся про деякі з основних [обʼєктів Kubernetes](/docs/concepts/overview/working-with-objects/) +* Дізнайтеся більше про [API Kubernetes](/docs/concepts/overview/kubernetes-api/) +* Якщо ви хочете написати свій власний контролер, див. [Розширювані шаблони Kubernetes](/docs/concepts/extend-kubernetes/#extension-patterns) та репозиторій [sample-controller](https://github.com/kubernetes/sample-controller). diff --git a/content/uk/docs/concepts/architecture/cri.md b/content/uk/docs/concepts/architecture/cri.md new file mode 100644 index 0000000000000..93390247ce21e --- /dev/null +++ b/content/uk/docs/concepts/architecture/cri.md @@ -0,0 +1,35 @@ +--- +title: Інтерфейс середовища виконання контейнерів (CRI) +aka: + - Container Runtime Interface + - CRI +content_type: concept +weight: 60 +--- + + + +CRI — це інтерфейс втулка, який дозволяє kubelet використовувати різноманітні середовища виконання контейнерів, не маючи потреби перекомпілювати компоненти кластера. + +Для того, щоб {{}} міг запускати +{{< glossary_tooltip text="Podʼи" term_id="pod" >}} та їхні контейнери, потрібне справне {{}} на кожному вузлі в кластері. + +{{< glossary_definition prepend="Інтерфейс середовища виконання контейнерів (CRI) —" term_id="container-runtime-interface" length="all" >}} + + + +## API {#api} + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +Kubelet діє як клієнт при підключенні до середовища виконання контейнерів через gRPC. Endpointʼи служби виконання та образів повинні бути доступні в середовищі виконання контейнерів, це може бути налаштовано окремо в kubelet за допомогою прапорців командного рядка `--image-service-endpoint` [command line flags](/docs/reference/command-line-tools-reference/kubelet). + +Для Kubernetes v{{< skew currentVersion >}}, kubelet вибирає CRI `v1`. Якщо середовище виконання контейнерів не підтримує `v1` CRI, то kubelet намагається домовитися про будь-яку підтримувану старішу версію. Kubelet v{{< skew currentVersion >}} також може домовитися про CRI `v1alpha2`, але ця версія вважається застарілою. Якщо kubelet не може домовитися про підтримувану версію CRI, то kubelet припиняє спроби та не реєструє вузол. + +## Оновлення {#upgrading} + +При оновленні Kubernetes kubelet намагається автоматично вибрати останню версію CRI при перезапуску компонента. Якщо це не вдається, то відбувається відновлення згідно з зазначеними вище. Якщо потрібен перезапуск kubelet через gRPC через оновлення середовища виконання контейнерів, то середовище виконання контейнерів також повинне підтримувати вибрану спочатку версію, інакше очікується що відновлення не відбудеться. Це вимагає перезапуску kubelet. + +## {{% heading "whatsnext" %}} + +- Дізнайтеся більше про [визначення протоколу](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto) CRI diff --git a/content/uk/docs/concepts/architecture/garbage-collection.md b/content/uk/docs/concepts/architecture/garbage-collection.md new file mode 100644 index 0000000000000..478308b76866f --- /dev/null +++ b/content/uk/docs/concepts/architecture/garbage-collection.md @@ -0,0 +1,124 @@ +--- +title: Збір сміття +content_type: concept +weight: 70 +--- + + + +{{}} Це дозволяє очищати ресурси, такі як: + +* [Припиненні Podʼи](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) +* [Завершені завдання (Jobs)](/docs/concepts/workloads/controllers/ttlafterfinished/) +* [Обʼєкти без власників](#owners-dependents) +* [Невикористані контейнери та образи контейнерів](#containers-images) +* [Динамічно створені томи PersistentVolumes із політикою вилучення StorageClass Delete](/docs/concepts/storage/persistent-volumes/#delete) +* [Застарілі або прострочені запити на підпис сертифікатів (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) +* Видалені вузли в наступних сценаріях: + * У хмарі, коли кластер використовує [керування контролером хмари](/docs/concepts/architecture/cloud-controller/) + * На місці, коли кластер використовує надбудову, схожу на контролер хмари +* [Обʼєкти Node Lease](/docs/concepts/architecture/nodes/#heartbeats) + +## Власники та залежності {#owners-dependents} + +Багато обʼєктів в Kubernetes повʼязані один з одним через [*посилання на власника*](/docs/concepts/overview/working-with-objects/owners-dependents/). Посилання на власника повідомляють панелі управління, які обʼєкти залежать від інших. Kubernetes використовує посилання на власника для того, щоб дати панелі управління та іншим клієнтам API можливість очищати повʼязані ресурси перед видаленням обʼєкта. У більшості випадків Kubernetes автоматично керує посиланнями на власника. + +Власність відрізняється від [механізму міток та селекторів](/docs/concepts/overview/working-with-objects/labels/), які також використовують деякі ресурси. Наприклад, розгляньте {{}}, який створює обʼєкти `EndpointSlice`. Сервіс використовує *мітки*, щоб дозволити панелі управління визначити, які обʼєкти `EndpointSlice` використовуються для цього Сервісу. Кожен обʼєкт `EndpointSlice`, який керується Сервісом, має власників. Посилання на власника допомагають різним частинам Kubernetes уникати втручання в обʼєкти, якими вони не керують. + +{{< note >}} +Посилання на власника через простір імен заборонені зазначеною концепцією. Обʼєкти, які використовують простори імен можуть вказувати власників загального простору імен або простору імен. Власник простору імен **повинен** існувати в тому ж просторі імен, що і залежний обʼєкт. Якщо цього не відбувається, таке посилання вважається відсутнім, і залежний обʼєкт підлягає видаленню після перевірки відсутності всіх власників. + +Обʼєкти залежні від загального простору імен можуть вказувати тільки загальних власників. У v1.20+, якщо залежний обʼєкт, який залежить від класу, вказує простор імен як власника, йому не вдасться вирішити посилання на власника та його не можна буде прибрати через збирання сміття. + +У v1.20+, якщо збирач сміття виявляє недійсний перехресний простір імен `ownerReference` або кластерний залежний з `ownerReference`, що посилається на тип простору імен, повідомляється про попереджувальну подію з причиною `OwnerRefInvalidNamespace` та `involvedObject` недійсного залежного елемента. Ви можете перевірити наявність такого роду подій, запустивши `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. +{{< /note >}} + +## Каскадне видалення {#cascading-deletion} + +Kubernetes перевіряє та видаляє обʼєкти, які більше не мають власників, наприклад, Podʼи, які залишилися після видалення ReplicaSet. Коли ви видаляєте обʼєкт, ви можете контролювати, чи автоматично видаляє Kubernetes залежні обʼєкти, у процесі, що називається *каскадним видаленням*. Існують два типи каскадного видалення: + +* Каскадне видалення на передньому плані +* Каскадне видалення у фоні + +Ви також можете контролювати те, як і коли збирання сміття видаляє ресурси, які мають посилання на власника, використовуючи {{}} Kubernetes. + +### Каскадне видалення на передньому плані {#foreground-deletion} + +У каскадному видаленні на передньому плані обʼєкт власника, який видаляється, спочатку потрапляє в стан *deletion in progress*. У цьому стані стається наступне для обʼєкта власника: + +* Сервер API Kubernetes встановлює поле `metadata.deletionTimestamp` обʼєкта на час, коли обʼєкт був позначений на видалення. +* Сервер API Kubernetes також встановлює поле `metadata.finalizers` в + `foregroundDeletion`. +* Обʼєкт залишається видимим через API Kubernetes, поки не буде завершений процес видалення. + +Після того як обʼєкт власника потрапляє в стан видалення в процесі, контролер видаляє залежні обʼєкти. Після видалення всіх залежних обʼєктів контролер видаляє обʼєкт власника. На цьому етапі обʼєкт більше не є видимим в API Kubernetes. + +Під час каскадного видалення на передньому плані тільки ті залежні обʼєкти, які мають поле `ownerReference.blockOwnerDeletion=true`, блокують видалення власника. Дивіться [Використання каскадного видалення на передньому плані](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion), щоб дізнатися більше. + +### Каскадне видалення у фоні {#background-deletion} + +В каскадному видаленні у фоні сервер API Kubernetes видаляє обʼєкт власника негайно, а контролер видаляє залежні обʼєкти в фоновому режимі. Типово Kubernetes використовує каскадне видалення у фоні, якщо ви не використовуєте видалення вручну на передньому плані або не вибираєте залишити залежні обʼєкти. + +Дивіться [Використання каскадного видалення у фоні](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion), щоб дізнатися більше. + +### Залишені залежності {#orphan-dependents} + +Коли Kubernetes видаляє обʼєкт власника, залишені залежні обʼєкти називаються *залишеними* обʼєктами. Типово Kubernetes видаляє залежні обʼєкти. Щоб дізнатися, як перевизначити цю поведінку, дивіться [Видалення власників та залишені залежності](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy). + +## Збір сміття невикористаних контейнерів та образів {#containers-images} + +{{}} виконує збір сміття невикористаних образів кожні дві хвилини та невикористаних контейнерів кожну хвилину. Ви повинні уникати використання зовнішніх інструментів для збору сміття, оскільки вони можуть порушити поведінку kubelet та видаляти контейнери, які повинні існувати. + +Щоб налаштувати параметри для збору сміття невикористаних контейнерів та образів, налаштуйте kubelet за допомогою [файлу конфігурації](/docs/tasks/administer-cluster/kubelet-config-file/) та змініть параметри, повʼязані зі збором сміття, використовуючи ресурс типу [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/). + +### Життєвий цикл образу контейнера {#container-image-lifecycle} + +Kubernetes керує життєвим циклом всіх образів через свій *менеджер образів*, який є частиною kubelet, співпрацюючи з {{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}. Kubelet враховує наступні обмеження щодо використання дискового простору при прийнятті рішень про збір сміття: + +* `HighThresholdPercent` +* `LowThresholdPercent` + +Використання дискового простору вище встановленого значення `HighThresholdPercent` викликає збір сміття, який видаляє образи в порядку їх останнього використання, починаючи з найстаріших. Kubelet видаляє образи до тих пір, поки використання дискового простору не досягне значення `LowThresholdPercent`. + +#### Збір сміття для невикористаних контейнерних образів {#image-maximum-age-gc} + +{{< feature-state feature_gate_name="ImageMaximumGCAge" >}} + +Як альфа-функція, ви можете вказати максимальний час, протягом якого локальний образ може бути невикористаний, незалежно від використання дискового простору. Це налаштування kubelet, яке ви вказуєте для кожного вузла. + +Щоб налаштувати параметр, увімкніть +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `ImageMaximumGCAge` для kubelet, а також встановіть значення поля `ImageMaximumGCAge` в файлі конфігурації kubelet. + +Значення вказується як _duration_ Kubernetes; наприклад, ви можете встановити значення поля конфігурації на `3d12h`, що означає 3 дні та 12 годин. + +### Збір сміття контейнерів {#container-image-garbage-collection} + +Kubelet збирає сміття невикористаних контейнерів на основі наступних змінних, які ви можете визначити: + +* `MinAge`: мінімальний вік, при якому kubelet може видаляти + контейнер. Вимкніть, встановивши на значення `0`. +* `MaxPerPodContainer`: максимальна кількість мертвих контейнерів які кожен + Pod може мати. Вимкніть, встановивши менше `0`. +* `MaxContainers`: максимальна кількість мертвих контейнерів у кластері. + Вимкніть, встановивши менше `0`. + +Крім цих змінних, kubelet збирає сміття невизначених та видалених контейнерів, як правило, починаючи з найстарших. + +`MaxPerPodContainer` та `MaxContainers` можуть потенційно конфліктувати одне з одним в ситуаціях, де збереження максимальної кількості контейнерів на кожен Pod (`MaxPerPodContainer`) вийде за допустиму загальну кількість глобальних мертвих контейнерів (`MaxContainers`). У цій ситуації kubelet коригує `MaxPerPodContainer` для вирішення конфлікту. У найгіршому випадку може бути знижений `MaxPerPodContainer` до `1` та видалені найдавніші контейнери. Крім того, контейнери, які належать Podʼам, які були видалені, видаляються, якщо вони старше `MinAge`. + +{{}} +Kubelet збирає сміття лише для контейнерів, якими він керує. +{{}} + +## Налаштування збору сміття {#configuring-gc} + +Ви можете налаштовувати збір сміття ресурсів, налаштовуючи параметри, специфічні для контролерів, що керують цими ресурсами. На наступних сторінках показано, як налаштовувати збір сміття: + +* [Налаштування каскадного видалення обʼєктів Kubernetes](/docs/tasks/administer-cluster/use-cascading-deletion/) +* [Налаштування очищення завершених завдань (Jobs)](/docs/concepts/workloads/controllers/ttlafterfinished/) + +## {{% heading "whatsnext" %}} + +* Дізнайтеся більше про [власність обʼєктів Kubernetes](/docs/concepts/overview/working-with-objects/owners-dependents/). +* Дізнайтеся більше про [завершувачі Kubernetes](/docs/concepts/overview/working-with-objects/finalizers/). +* Дізнайтеся про [контролер TTL](/docs/concepts/workloads/controllers/ttlafterfinished/), який очищає завершені завдання. diff --git a/content/uk/docs/concepts/architecture/leases.md b/content/uk/docs/concepts/architecture/leases.md new file mode 100644 index 0000000000000..417339949b9cf --- /dev/null +++ b/content/uk/docs/concepts/architecture/leases.md @@ -0,0 +1,78 @@ +--- +title: Лізинг +content_type: concept +weight: 30 +--- + + + +Часто в розподілених системах є потреба в _лізингу_, яка забезпечує механізм блокування спільних ресурсів та координації дій між членами групи. В Kubernetes концепцію лізингу представлено обʼєктами [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) в {{< glossary_tooltip text="API Group" term_id="api-group" >}} `coordination.k8s.io`, які використовуються для критичних для системи можливостей, таких як час роботи вузлів та вибір лідера на рівні компонентів. + + + +## Час роботи вузлів {#node-heart-beats} + +Kubernetes використовує API Lease для звʼязку з пульсом kubelet вузла з API сервером Kubernetes. Для кожного `Node` існує обʼєкт `Lease` з відповідним імʼям в просторі імен `kube-node-lease`. Під капотом кожен сигнал пульсу kubelet — це запит на **оновлення** цього обʼєкта `Lease`, який оновлює поле `spec.renewTime` для оренди. Панель управління Kubernetes використовує відмітку часу цього поля для визначення доступності цього вузла. + +Дивіться [Обʼєкти Lease вузлів](/docs/concepts/architecture/nodes/#heartbeats) для отримання додаткових деталей. + +## Вибір лідера {#leader-election} + +Kubernetes також використовує лізинги для забезпечення того, що в будь-який момент часу працює лише один екземпляр компонента. Це використовується компонентами панелі управління, такими як `kube-controller-manager` та `kube-scheduler` в конфігураціях з високою доступністю, де лише один екземпляр компонента має активно працювати, тоді як інші екземпляри перебувають в режимі очікування. + +## Ідентифікація API сервера {#api-server-identity} + +{{< feature-state feature_gate_name="APIServerIdentity" >}} + +Починаючи з Kubernetes v1.26, кожен `kube-apiserver` використовує API Lease для публікації своєї ідентичності для решти системи. Хоча це само по собі не є особливо корисним, це забезпечує механізм для клієнтів для визначення кількості екземплярів `kube-apiserver`, які керують панеллю управління Kubernetes. Наявність лізингів kube-apiserver дозволяє майбутнім можливостям, які можуть потребувати координації між кожним kube-apiserver. + +Ви можете перевірити лізинги, якими володіє кожен kube-apiserver, перевіривши обʼєкти лізингу в просторі імен `kube-system` з іменем `kube-apiserver-`. Або ви можете використовувати селектор міток `apiserver.kubernetes.io/identity=kube-apiserver`: + +```shell +kubectl -n kube-system get lease -l apiserver.kubernetes.io/identity=kube-apiserver +``` + +```none +NAME HOLDER AGE +apiserver-07a5ea9b9b072c4a5f3d1c3702 apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05 5m33s +apiserver-7be9e061c59d368b3ddaf1376e apiserver-7be9e061c59d368b3ddaf1376e_84f2a85d-37c1-4b14-b6b9-603e62e4896f 4m23s +apiserver-1dfef752bcb36637d2763d1868 apiserver-1dfef752bcb36637d2763d1868_c5ffa286-8a9a-45d4-91e7-61118ed58d2e 4m43s + +``` + +Хеш SHA256, який використовується в назвах лізингу, базується на імені ОС, які бачить цей API сервер. Кожен kube-apiserver повинен бути налаштований на використання унікального імені в межах кластера. Нові екземпляри kube-apiserver, які використовують те саме імʼя хоста, захоплюють наявні лізинги за допомогою нового ідентифікатора власника, замість того щоб створювати нові обʼєкти лізингу. Ви можете перевірити імʼя хоста, використовуючи kube-apisever, перевіривши значення мітки `kubernetes.io/hostname`: + +```shell +kubectl -n kube-system get lease apiserver-07a5ea9b9b072c4a5f3d1c3702 -o yaml +``` + +```yaml +apiVersion: coordination.k8s.io/v1 +kind: Lease +metadata: + creationTimestamp: "2023-07-02T13:16:48Z" + labels: + apiserver.kubernetes.io/identity: kube-apiserver + kubernetes.io/hostname: master-1 + name: apiserver-07a5ea9b9b072c4a5f3d1c3702 + namespace: kube-system + resourceVersion: "334899" + uid: 90870ab5-1ba9-4523-b215-e4d4e662acb1 +spec: + holderIdentity: apiserver-07a5ea9b9b072c4a5f3d1c3702_0c8914f7-0f35-440e-8676-7844977d3a05 + leaseDurationSeconds: 3600 + renewTime: "2023-07-04T21:58:48.065888Z" +``` + +Прострочені лізинги від kube-apiservers, які вже не існують, прибираються новими kube-apiservers через 1 годину. + +Ви можете вимкнути лізинги ідентичності API сервера, вимкнувши +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `APIServerIdentity`. + +## Робочі навантаження {#custom-workload} + +Ваші власні робочі навантаження можуть визначити своє власне використання лізингів. Наприклад, ви можете запускати власний {{< glossary_tooltip term_id="controller" text="контролер" >}}, де первинний член чи лідер виконує операції, які його партнери не виконують. Ви визначаєте лізинг так, щоб репліки контролера могли вибирати чи обирати лідера, використовуючи API Kubernetes для координації. Якщо ви використовуєте лізинг, це гарна практика визначати імʼя лізингу, яке очевидно повʼязано з продуктом чи компонентом. Наприклад, якщо у вас є компонент з іменем Example Foo, використовуйте лізинг з іменем `example-foo`. + +Якщо оператор кластера чи інший кінцевий користувач може розгортати кілька екземплярів компонента, виберіть префікс імʼя і виберіть механізм (такий як хеш від назви Deployment), щоб уникнути конфліктів імен для лізингів. + +Ви можете використовувати інший підхід, поки він досягає того самого результату: відсутність конфліктів між різними програмними продуктами. diff --git a/content/uk/docs/concepts/architecture/mixed-version-proxy.md b/content/uk/docs/concepts/architecture/mixed-version-proxy.md new file mode 100644 index 0000000000000..f3789007c16ca --- /dev/null +++ b/content/uk/docs/concepts/architecture/mixed-version-proxy.md @@ -0,0 +1,71 @@ +--- +reviewers: +- jpbetz +title: Mixed Version Proxy +content_type: concept +weight: 220 +--- + + + +{{< feature-state feature_gate_name="UnknownVersionInteroperabilityProxy" >}} + +У Kubernetes {{< skew currentVersion >}} включено альфа-функцію, яка дозволяє {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} проксійовати запити ресурсів до інших _рівноправних_ API-серверів. Це корисно, коли існують кілька API-серверів, що працюють на різних версіях Kubernetes в одному кластері (наприклад, під час тривалого впровадження нового релізу Kubernetes). + +Це дозволяє адміністраторам кластерів налаштовувати високодоступні кластери, які можна модернізувати більш безпечно, направляючи запити на ресурси (зроблені під час оновлення) на правильний kube-apiserver. Цей проксі заважає користувачам бачити несподівані помилки 404 Not Found, які випливають з процесу оновлення. + +Цей механізм називається _Mixed Version Proxy_. + +## Активація Mixed Version Proxy {#enabling-the-mixed-version-proxy} + +Переконайтеся, що [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `UnknownVersionInteroperabilityProxy` увімкнено, коли ви запускаєте {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}: + +```shell +kube-apiserver \ +--feature-gates=UnknownVersionInteroperabilityProxy=true \ +# обовʼязкові аргументи командного рядка для цієї функції +--peer-ca-file=<шлях до сертифіката CA kube-apiserver> +--proxy-client-cert-file=<шлях до сертифіката агрегатора проксі>, +--proxy-client-key-file=<шлях до ключа агрегатора проксі>, +--requestheader-client-ca-file=<шлях до сертифіката CA агрегатора>, +# requestheader-allowed-names може бути встановлено як порожнє значення, щоб дозволити будь-яке Загальне Імʼя +--requestheader-allowed-names=<дійсні Загальні Імена для перевірки сертифікату клієнта проксі>, + +# необовʼязкові прапорці для цієї функції +--peer-advertise-ip=`IP цього kube-apiserver, яке повинно використовуватися рівноправними для проксі-запитів` +--peer-advertise-port=`порт цього kube-apiserver, який повинен використовуватися рівноправними для проксі-запитів` + +# …і інші прапорці як зазвичай +``` + +### Транспорт та автентифікація проксі між API-серверами {#transport-and-authn} + +* Вихідний kube-apiserver повторно використовує + [наявні прапорці автентифікації клієнта API-сервера](/docs/tasks/extend-kubernetes/configure-aggregation-layer/#kubernetes-apiserver-client-authentication) `--proxy-client-cert-file` та `--proxy-client-key-file` для представлення своєї ідентичності, яку перевіряє його рівноправний (цільовий kube-apiserver). Цей останній підтверджує підключення рівноправного на основі конфігурації, яку ви вказуєте за допомогою аргументу командного рядка `--requestheader-client-ca-file`. + +* Для автентифікації сертифікатів серверів призначення вам слід налаштувати пакет сертифіката організації, вказавши аргумент командного рядка `--peer-ca-file` **вихідному** API-серверу. + +### Налаштування для зʼєднання з рівноправним API-сервером {#configuring-for-peer-api-server-connectivity} + +Для встановлення мережевого розташування kube-apiserver, яке партнери будуть використовувати для проксі-запитів, використовуйте аргументи командного рядка `--peer-advertise-ip` та `--peer-advertise-port` для kube-apiserver або вказуйте ці поля в конфігураційному файлі API-сервера. Якщо ці прапорці не вказані, партнери будуть використовувати значення з аргументів командного рядка `--advertise-address` або `--bind-address` для kube-apiserver. Якщо ці прапорці теж не встановлені, використовується типовий інтерфейс хосту. + +## Mixed version proxying + +При активації Mixed version proxying [шар агрегації](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) завантажує спеціальний фільтр, який виконує такі дії: + +* Коли запит ресурсу надходить до API-сервера, який не може обслуговувати цей API (чи то тому, що він є версією, що передує введенню API, чи тому, що API вимкнено на API-сервері), API-сервер намагається надіслати запит до рівноправного API-сервера, який може обслуговувати затребуваний API. Це відбувається шляхом ідентифікації груп API / версій / ресурсів, які місцевий сервер не визнає, і спроби проксійовати ці запити до рівноправного API-сервера, який може обробити запит. +* Якщо рівноправний API-сервер не відповідає, то _source_ API-сервер відповідає помилкою 503 ("Сервіс недоступний"). + +### Як це працює під капотом {#how-it-works-under-the-hood} + +Коли API-сервер отримує запит ресурсу, він спочатку перевіряє, які API-сервери можуть обслуговувати затребуваний ресурс. Ця перевірка відбувається за допомогою внутрішнього [API зберігання версії](/docs/reference/generated/kubernetes-api/v{{< skew currentVersion >}}/#storageversioncondition-v1alpha1-internal-apiserver-k8s-io). + +* Якщо ресурс відомий API-серверу, що отримав запит (наприклад, `GET /api/v1/pods/some-pod`), запит обробляється локально. + +* Якщо для запитаного ресурсу не знайдено внутрішнього обʼєкта `StorageVersion` (наприклад, `GET /my-api/v1/my-resource`) і налаштовано APIService на проксі до API-сервера розширення, цей проксі відбувається за звичайного [процесу](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) для розширених API. + +* Якщо знайдено дійсний внутрішній обʼєкт `StorageVersion` для запитаного ресурсу (наприклад, `GET /batch/v1/jobs`) і API-сервер, який намагається обробити запит (API-сервер обробників), має вимкнений API `batch`, тоді API-сервер, який обробляє запит, витягує рівноправні API-сервери, які обслуговують відповідну групу / версію / ресурс (`api/v1/batch` у цьому випадку) за інформацією у витягнутому обʼєкті `StorageVersion`. API-сервер, який обробляє запит, потім проксіює запит до одного з вибраних рівноправних kube-apiservers які обізнані з запитаним ресурсом. + + * Якщо немає партнера, відомого для тієї групи API / версії / ресурсу, API-сервер обробників передає запит своєму власному ланцюжку обробки, який, врешті-решт, повинен повернути відповідь 404 ("Не знайдено"). + + * Якщо API-сервер обробників ідентифікував і вибрав рівноправний API-сервер, але цей останній не відповідає (з причин, таких як проблеми з мережевим зʼєднанням або data race між отриманням запиту та реєстрацією інформації партнера в панелі управління), то API-сервер обробників відповідає помилкою 503 ("Сервіс недоступний"). diff --git a/content/uk/docs/concepts/architecture/nodes.md b/content/uk/docs/concepts/architecture/nodes.md new file mode 100644 index 0000000000000..e7e111115b26a --- /dev/null +++ b/content/uk/docs/concepts/architecture/nodes.md @@ -0,0 +1,374 @@ +--- +reviewers: +- caesarxuchao +- dchen1107 +title: Вузли +aka: Nodes +content_type: concept +weight: 10 +--- + + + +Kubernetes виконує ваше {{< glossary_tooltip text="навантаження" term_id="workload" >}} шляхом розміщення контейнерів у Podʼах для запуску на _Вузлах_. Вузол може бути віртуальною або фізичною машиною, залежно від кластера. Кожен вузол керується {{< glossary_tooltip text="панеллю управління" term_id="control-plane" >}} і містить необхідні служби для запуску {{< glossary_tooltip text="Podʼів" term_id="pod" >}}. + +Зазвичай в кластері є кілька вузлів; в умовах навчання чи обмежених ресурсів може бути всього один вузол. + +[Компоненти](/docs/concepts/overview/components/#node-components) на вузлі включають {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="середовище виконання контейнерів" term_id="container-runtime" >}} та +{{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}. + + + +## Управління {#managmenet} + +Є два основних способи додавання Вузлів до {{< glossary_tooltip text="API-сервера" term_id="kube-apiserver" >}}: + +1. kubelet на вузлі самостійно реєструється в панелі управління. +2. Ви (або інший користувач) вручну додаєте обʼєкт Node. + +Після створення {{< glossary_tooltip text="обʼєкта" term_id="object" >}} Node, або якщо kubelet на вузлі самостійно реєструється, панель управління перевіряє, чи новий обʼєкт Node є дійсним. Наприклад, якщо ви спробуєте створити Вузол з наступним JSON-маніфестом: + +```json +{ + "kind": "Node", + "apiVersion": "v1", + "metadata": { + "name": "10.240.79.157", + "labels": { + "name": "my-first-k8s-node" + } + } +} +``` + +Kubernetes внутрішньо створює обʼєкт Node. Kubernetes перевіряє чи kubelet зареєструвався в API-сервері, що відповідає полю `metadata.name` Node. Якщо вузол є справним (тобто всі необхідні служби працюють), то він може запускати Podʼи. В іншому випадку цей вузол ігнорується для будь-якої діяльності кластера доки він не стане справним. + +{{< note >}} +Kubernetes зберігає обʼєкт для недійсного Вузла та продовжує перевіряти, чи він стає справним. + +Вам або {{< glossary_tooltip term_id="controller" text="контролер" >}} має явно видалити обʼєкт Node, щоб припинити цю перевірку його справності. +{{< /note >}} + +Назва обʼєкта Node повинно бути дійсним [імʼям DNS-піддомену](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +### Унікальність назв Вузлів {#node-name-uniqueness} + +[Назва](/docs/concepts/overview/working-with-objects/names#names) ідентифікує Node. Два Вузли не можуть мати однакову назву одночасно. Kubernetes також припускає, що ресурс з такою ж назвою — це той самий обʼєкт. У випадку Вузла припускається неявно, що екземпляр, який використовує ту ж назву, матиме той самий стан (наприклад, мережеві налаштування, вміст кореневого диска) та атрибути, такі як мітки вузла. Це може призвести до невідповідностей, якщо екземпляр був змінений без зміни його назви. Якщо Вузол потрібно замінити або значно оновити, наявний обʼєкт Node повинен бути видалений з API-сервера спочатку і знову доданий після оновлення. + +### Самореєстрація Вузлів {#self-registration-of-nodes} + +Коли прапорець kubelet `--register-node` є true (типово), kubelet спробує зареєструвати себе в API-сервері. Цей підхід використовується більшістю дистрибутивів. + +Для самореєстрації kubelet запускається з наступними параметрами: + +- `--kubeconfig` — Шлях до облікових даних для автентифікації на API-сервері. +- `--cloud-provider` — Як взаємодіяти з {{< glossary_tooltip text="хмарним постачальником" term_id="cloud-provider" >}} для отримання метаданих про себе. +- `--register-node` — Автоматична реєстрація в API-сервері. +- `--register-with-taints` — Реєстрація вузла з заданим списком {{< glossary_tooltip text="позначок" term_id="taint" >}} (розділених комами `<ключ>=<значення>:<ефект>`). + + Нічого не відбувається, якщо `register-node` є false. +- `--node-ip` — Необовʼязковий розділений комами список IP-адрес вузла. Можна вказати лише одну адресу для кожного роду адрес. Наприклад, у кластері з одним стеком IPv4 ви встановлюєте це значення як IPv4-адресу, яку повинен використовувати kubelet для вузла. Див. [налаштування подвійного стека IPv4/IPv6](/docs/concepts/services-networking/dual-stack/#configure-ipv4-ipv6-dual-stack) для отримання відомостей з запуску кластера з подвійним стеком. + + Якщо ви не вказали цей аргумент, kubelet використовує стандартну IPv4-адресу вузла, якщо є; якщо у вузла немає адреси IPv4, тоді kubelet використовує стандартну IPv6-адресу вузла. +- `--node-labels` - {{< glossary_tooltip text="Мітки" term_id="label" >}} для додавання при реєстрації вузла в кластері (див. обмеження міток, що накладаються [втулком доступу NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)). +- `--node-status-update-frequency` — Вказує, як часто kubelet публікує свій статус вузла на API-сервері. + +Коли увімкнено [режим авторизації Вузла](/docs/reference/access-authn-authz/node/) та [втулок доступу NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction), kubelets мають право створювати/змінювати лише свій власний ресурс Node. + +{{< note >}} +Як зазначено в розділі [Унікальність назв Вузлів](#node-name-uniqueness), коли потрібно оновити конфігурацію Вузла, добре було б знову зареєструвати вузол в API-сервері. Наприклад, якщо kubelet перезапускається з новим набором `--node-labels`, але використовується та ж назва Node, зміна не відбудеться, оскільки мітки встановлюються при реєстрації вузла. + +Podʼи, вже заплановані на Node, можуть погано поводитися або викликати проблеми, якщо конфігурація Node буде змінена при перезапуску kubelet. Наприклад, вже запущений Pod може бути позначений новими мітками, призначеними Node, тоді як інші Pod, які несумісні з цим Pod, будуть заплановані на основі цієї нової мітки. Перереєстрація вузла гарантує, що всі Podʼи будуть очищені та належним чином переплановані. +{{< /note >}} + +### Ручне адміністрування Вузлів {#manual-node-administration} + +Ви можете створювати та змінювати обʼєкти Node за допомогою {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}. + +Коли ви хочете створювати обʼєкти Node вручну, встановіть прапорець kubelet `--register-node=false`. + +Ви можете змінювати обʼєкти Node незалежно від налаштувань `--register-node`. Наприклад, ви можете встановлювати мітки на наявному Вузлі або позначати його як незапланований. + +Ви можете використовувати мітки на Вузлах разом із селекторами вузлів на Podʼах для управління плануванням. Наприклад, ви можете обмежити Pod лише можливістю запуску на +підмножині доступних вузлів. + +Позначення вузла як незапланованого перешкоджає планувальнику розміщувати нові Podʼи на цьому Вузлі, але не впливає на наявні Podʼи на Вузлі. Це корисно як підготовчий крок перед перезавантаженням вузла чи іншим обслуговуванням. + +Щоб позначити Вузол як незапланований, виконайте: + +```shell +kubectl cordon $NODENAME +``` + +Див. [Безпечне очищення вузла](/docs/tasks/administer-cluster/safely-drain-node/) для деталей. + +{{< note >}} +Podʼи, які є частиною {{< glossary_tooltip term_id="daemonset" >}}, можуть працювати на незапланованому Вузлі. Зазвичай DaemonSets надають служби, що працюють локально на Вузлі, навіть якщо він очищується від робочих навантажень. +{{< /note >}} + +## Статус Вузла {#node-status} + +Статус Вузла містить наступну інформацію: + +- [Адреси](/docs/reference/node/node-status/#addresses) +- [Умови](/docs/reference/node/node-status/#condition) +- [Місткість та Розподіленість](/docs/reference/node/node-status/#capacity) +- [Інформація](/docs/reference/node/node-status/#info) + +Ви можете використовувати `kubectl`, щоб переглядати статус Вузла та інші деталі: + +```shell +kubectl describe node <вставте-назву-вузла-тут> +``` + +Див. [Статус Вузла](/docs/reference/node/node-status/) для отримання додаткової інформації. + +## Сигнали Вузлів {#node-heartbeats} + +Сигнали, надсилані вузлами Kubernetes, допомагають вашому кластеру визначати доступність кожного вузла та вживати заходів у випадку виявлення відмов. + +Для вузлів існують дві форми сигналів: + +- Оновлення в [`.status`](/docs/reference/node/node-status/) Вузла. +- Обʼєкти [Оренди (Lease)](/docs/concepts/architecture/leases/) у просторі імен `kube-node-lease`. Кожен Вузол має асоційований обʼєкт Lease. + +## Контролер вузлів {#node-controller} + +Контролер вузлів — це компонент панелі управління Kubernetes, який керує різними аспектами роботи вузлів. + +У контролера вузла є кілька ролей у житті вузла. По-перше, він призначає блок CIDR вузлу при його реєстрації (якщо призначення CIDR увімкнено). + +По-друге, він підтримує актуальність внутрішнього списку вузлів контролера зі списком доступних машин хмарного провайдера. У разі, якщо вузол несправний, контролер вузла перевіряє у хмарному провайдері, чи ще доступний віртуальний компʼютер (VM) для цього вузла. Якщо ні, контролер вузла видаляє вузол зі свого списку вузлів. + +По-третє, контролер відповідає за моніторинг стану вузлів і: + +- У випадку, якщо вузол стає недоступним, оновлення умови `Ready` у полі `.status` Вузла. У цьому випадку контролер вузла встановлює умову `Ready` в `Unknown`. +- Якщо вузол залишається недоступним: запускає [ініційоване API вивільнення](/docs/concepts/scheduling-eviction/api-eviction/) для всіх Podʼів на недосяжному вузлі. Типово контролер вузла чекає 5 хвилин між позначенням вузла як `Unknown` та поданням першого запиту на вивільнення. + +Стандартно контролер вузла перевіряє стан кожного вузла кожні 5 секунд. Цей період можна налаштувати за допомогою прапорця `--node-monitor-period` у компоненті `kube-controller-manager`. + +### Обмеження швидкості вивільнення {#rate-limits-on-eviction} + +У більшості випадків контролер вузла обмежує швидкість вивільнення на `--node-eviction-rate` (типово 0,1) в секунду, що означає, що він не буде виводити Podʼи з більше, ніж 1 вузла кожні 10 секунд. + +Поведінка вивільнення вузла змінюється, коли вузол в певній доступності стає несправним. Контролер вузла перевіряє, яка частина вузлів в зоні є несправною (умова `Ready` — `Unknown` або `False`) у той самий час: + +- Якщо частка несправних вузлів становить принаймні `--unhealthy-zone-threshold` (типово 0,55), тоді швидкість вивільнення зменшується. +- Якщо кластер малий (тобто має менше або дорівнює `--large-cluster-size-threshold` вузлів — типово 50), тоді вивільнення припиняється. +- У іншому випадку швидкість вивільнення зменшується до `--secondary-node-eviction-rate` (типово 0,01) в секунду. + +Причина того, що ці політики реалізовані окремо для кожної зони доступності, полягає в тому, що одна зона може втратити зʼєднання з панеллю управління, тоді як інші залишаються підключеними. Якщо ваш кластер не охоплює кілька зон доступності хмарного провайдера, тоді механізм вивільнення не враховує доступність поміж зон. + +Однією з ключових причин розподілу вузлів за зонами доступності є можливість переміщення навантаження в справні зони, коли одна ціла зона виходить з ладу. Таким чином, якщо всі вузли в зоні несправні, контролер вузла виводить навантаження зі звичайною швидкістю `--node-eviction-rate`. Крайній випадок — коли всі зони повністю несправні (жоден вузол в кластері не є справним). У такому випадку контролер вузла припускає, що існує якась проблема зі зʼєднанням між панеллю управління та вузлами, і не виконує жодних вивільнень. (Якщо стався збій і деякі вузли відновились, контролер вузла виводить Podʼи з решти вузлів, які є несправними або недосяжними). + +Контролер вузла також відповідає за виведення Podʼів, що працюють на вузлах із позначками `NoExecute`, якщо ці Podʼи дозволяють таке. Контролер вузла також додає {{< glossary_tooltip text="taint" term_id="taint" >}}, відповідні проблемам вузла, таким як недосяжність вузла або неготовність вузла. Це означає, що планувальник не розміщуватиме Podʼи на несправних вузлах. + +## Відстеження місткості ресурсів {#node-capacity} + +Обʼєкти Node відстежують інформацію про ресурсну місткість вузла: наприклад, кількість доступної памʼяті та кількість процесорів. Вузли, які [реєструються самостійно](#self-registration-of-nodes), повідомляють про свою місткість під час реєстрації. Якщо ви [додаєте вузол вручну](#manual-node-administration), то вам потрібно встановити інформацію про місткість вузла при його додаванні. + +Планувальник Kubernetes {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} забезпечує, що на вузлі є достатньо ресурсів для всіх Podʼів. Планувальник перевіряє, що сума запитів контейнерів на вузлі не перевищує місткості вузла. Ця сума запитів включає всі контейнери, керовані kubelet, але не включає жодні контейнери, запущені безпосередньо середовищем виконання контейнерів, а також виключає будь-які процеси, які працюють поза контролем kubelet. + +{{< note >}} +Якщо ви хочете явно зарезервувати ресурси для не-Pod процесів, дивіться +[резервування ресурсів для системних служб](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved). +{{< /note >}} + +## Топологія вузла + +{{< feature-state feature_gate_name="TopologyManager" >}} + +Якщо ви увімкнули [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) ресурсу `TopologyManager`, то kubelet може використовувати підказки топології при прийнятті рішень щодо призначення ресурсів. Див. [Керування політиками топології на вузлі](/docs/tasks/administer-cluster/topology-manager/) +для отримання додаткової інформації. + +## Відповідне вимикання вузла {#graceful-node-shutdown} + +{{< feature-state feature_gate_name="GracefulNodeShutdown" >}} + +Kubelet намагається виявити вимикання системи вузла та завершує виконання Podʼів на вузлі. + +Kubelet забезпечує виконання нормального [процесу завершення роботи Podʼа](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) під час вимикання вузла. Під час вимикання вузла kubelet не приймає нові Podʼи (навіть якщо ці Podʼи вже призначені вузлу). + +Можливість відповідного вимикання вузла залежить від systemd, оскільки вона використовує [блокування інгібіторів systemd](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) для затримки вимкнення вузла на певний час. + +Вимикання вузла керується властивістю +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `GracefulNodeShutdown`, яка є типово увімкненою з версії 1.21. + +Зауважте, що типово обидва налаштування конфігурації, описані нижче, `shutdownGracePeriod` та `shutdownGracePeriodCriticalPods`, встановлені на нуль, таким чином, не активуючи функціональність відповідного вимикання вузла. Для активації цієї функції, два налаштування конфігурації kubelet повинні бути належним чином налаштовані та встановлені на значення, відмінні від нуля. + +Якщо systemd виявляє або повідомляє про вимикання вузла, kubelet встановлює умову `NotReady` на вузлі з причиною `"node is shutting down"`. Kube-scheduler дотримується цієї умови та не планує жодних Podʼів на цьому вузлі; очікується, що інші планувальники сторонніх постачальників дотримуватимуться такої ж логіки. Це означає, що нові Podʼи не будуть плануватися на цьому вузлі, і, отже, жоден із них не розпочне роботу. + +Kubelet **також** відхиляє Podʼи під час фази `PodAdmission`, якщо виявлено поточне +вимикання вузла, так що навіть Podʼи з {{< glossary_tooltip text="toleration" term_id="toleration" >}} для `node.kubernetes.io/not-ready:NoSchedule` не почнуть виконання там. + +Водночас коли kubelet встановлює цю умову на своєму вузлі через API, kubelet також починає завершення будь-яких Podʼів, які виконуються локально. + +Під час вимикання kubelet завершує Podʼи в два етапи: + +1. Завершує звичайні Podʼи, які виконуються на вузлі. +2. Завершує [критичні Podʼи](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) виконуються на вузлі. + +Функцію відповідного вимикання вузла налаштовується двома параметрами конфігурації kubelet: + +- `shutdownGracePeriod`: + - Визначає загальний час, протягом якого вузол повинен затримати вимикання. Це загальний термін допомогає завершити Podʼи як звичайні, так і [критичні](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). +- `shutdownGracePeriodCriticalPods`: + - Визначає термін, який використовується для завершення [критичних Podʼів](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) під час вимикання вузла. Це значення повинно бути менше за `shutdownGracePeriod`. + +{{< note >}} +Є випадки, коли вимкнення вузла було скасовано системою (або, можливо, вручну адміністратором). У будь-якому з цих випадків вузол повернеться до стану `Ready`. +Однак Podʼи, які вже розпочали процес завершення, не будуть відновлені kubelet +і їх потрібно буде перепланувати. +{{< /note >}} + +Наприклад, якщо `shutdownGracePeriod=30s`, а `shutdownGracePeriodCriticalPods=10s`, kubelet затримає вимикання вузла на 30 секунд. Під час вимикання перші 20 (30-10) секунд будуть зарезервовані для відповідного завершення звичайних Podʼів, а останні 10 секунд будуть зарезервовані для завершення [критичних Podʼів](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). + +{{< note >}} +Коли Podʼи були виведені під час відповідного вимикання вузла, вони позначаються як вимкнені. Виклик `kubectl get pods` показує стан виведених Podʼів як `Terminated`. І `kubectl describe pod` вказує, що Pod був виведений через вимикання вузла: + +```none +Reason: Terminated +Message: Pod was terminated in response to imminent node shutdown. +``` + +{{< /note >}} + +### Відповідне вимикання вузла на основі пріоритету Podʼа {#pod-priority-graceful-node-shutdown} + +{{< feature-state feature_gate_name="GracefulNodeShutdownBasedOnPodPriority" >}} + +Щоб забезпечити більше гнучкості під час відповідного вимикання вузла щодо порядку Podʼів під час вимикання, поступове вимикання вузла враховує PriorityClass для Podʼів, за умови, що ви активували цю функцію у своєму кластері. Функція дозволяє адміністраторам кластера явно визначити порядок Podʼів під час відповідного вимикання вузла на основі [priority classes](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass). + +Функція [відповідного вимикання вузла](#graceful-node-shutdown), яка описана вище, вимикає Podʼи в дві фази: звичайні Podʼи, а потім критичні Podʼи. Якщо потрібна додаткова гнучкість для явного визначення порядку Podʼи під час вимикання в більш деталізований спосіб, можна використовувати поступове вимикання вузла на основі пріоритету Podʼа. + +Коли вимикання вузла враховує пріоритет Podʼів, це дозволяє виконувати вимикання вузла у кілька етапів, кожен етап — це завершення роботи Podʼів певного класу пріоритету. Kubelet можна налаштувати з точним числом етапів та часом вимкнення для кожного етапу. + +Припустимо, що в кластері існують наступні власні [класи пріоритету Podʼа](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass): + +|Назва класу пріоритету Podʼа|Значення класу пріоритету Podʼа| +|-------------------------|------------------------| +|`custom-class-a` | 100000 | +|`custom-class-b` | 10000 | +|`custom-class-c` | 1000 | +|`звичайний/не встановлено` | 0 | + +В межах [конфігурації kubelet](/docs/reference/config-api/kubelet-config.v1beta1/) налаштування для `shutdownGracePeriodByPodPriority` може виглядати так: + +|Значення класу пріоритету Podʼа|Період вимкнення| +|------------------------|---------------| +| 100000 |10 seconds | +| 10000 |180 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + +Відповідна конфігурація YAML kubelet виглядатиме так: + +```yaml +shutdownGracePeriodByPodPriority: + - priority: 100000 + shutdownGracePeriodSeconds: 10 + - priority: 10000 + shutdownGracePeriodSeconds: 180 + - priority: 1000 + shutdownGracePeriodSeconds: 120 + - priority: 0 + shutdownGracePeriodSeconds: 60 +``` + +Вищеописана таблиця означає, що будь-який Pod зі значенням `priority` >= 100000 отримає лише 10 секунд на зупинку, будь-який Pod зі значенням >= 10000 і < 100000 отримає 180 секунд для зупинки, будь-який Pod зі значенням >= 1000 і < 10000 отримає 120 секунд для зупинки. Нарешті, всі інші Podʼи отримають 60 секунд для зупинки. + +Не обовʼязково вказувати значення, відповідні всім класам. Наприклад, можна використовувати ці налаштування: + +|Значення класу пріоритету Podʼа|Період вимкнення| +|------------------------|---------------| +| 100000 |300 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + +У випадку, коли в певному діапазоні пріоритету немає Podʼів, kubelet не чекатиме на Podʼи в тому діапазоні пріоритету. Замість цього kubelet негайно перейде до наступного діапазону значень класу пріоритету. + +Якщо ця функція активована, і не надано конфігурацію, то жодної дії з порядком не буде вжито. + +Використання цієї функції передбачає активацію [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `GracefulNodeShutdownBasedOnPodPriority`, і встановлення `ShutdownGracePeriodByPodPriority` в [kubelet config](/docs/reference/config-api/kubelet-config.v1beta1/) до потрібної конфігурації, яка містить значення класу пріоритету Podʼа та відповідні періоди вимкнення. + +{{< note >}} +Здатність щоб враховувати пріоритет Podʼа під час відповідного вимикання вузла була введена як альфа-функція в Kubernetes v1.23. У Kubernetes {{< skew currentVersion >}} функція є бета-версією та є типово активованою. +{{< /note >}} + +Метрики `graceful_shutdown_start_time_seconds` та `graceful_shutdown_end_time_seconds` виділяються під систему kubelet для моніторингу вимкнень вузлів. + +## Обробка вимкнення вузла без використання відповідного вимкнення {#non-graceful-node-shutdown} + +{{< feature-state feature_gate_name="NodeOutOfServiceVolumeDetach" >}} + +Дія вимкнення вузла може не виявитися Node Shutdown Manager вузла kubelet, чи то через те, що команда не спричинює механізм блокування інгібітора, який використовується kubelet, чи через помилку користувача, тобто ShutdownGracePeriod і +ShutdownGracePeriodCriticalPods налаштовані неправильно. Будь ласка, зверніться до вищезазначеної секції [Відповідне вимкання вузла](#graceful-node-shutdown) для отримання докладнішої інформації. + +Коли вузол вимикається, але не виявляється Node Shutdown Manager вузла kubelet, Podʼи, які є частиною {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}, залишаться в стані завершення на вимкненому вузлі і не зможуть перейти до нового робочого вузла. Це тому, що kubelet на вимкненому вузлі недоступний для видалення Podʼів, і StatefulSet не може створити новий Pod із такою ж назвою. Якщо є томи, які використовуються Podʼами, то VolumeAttachments не буде видалено з оригінального вимкненого вузла, і тому томи використовувані цими Podʼами не можуть бути приєднані до нового робочого вузла. В результаті застосунок, що виконується на StatefulSet, не може працювати належним чином. Якщо оригінальний вимкнений вузол вмикається, Podʼи будуть видалені kubelet, і нові Podʼи будуть створені на іншому робочому вузлі. Якщо оригінальний вимкнений вузол не повертається, ці Podʼи залишаться в стані завершення на вимкненому вузлі назавжди. + +Для помʼякшення вищезазначеної ситуації користувач може вручну додати позачку `node.kubernetes.io/out-of-service` із ефектом `NoExecute` чи `NoSchedule` до вузла, вказавши, що він вийшов із ладу. Якщо у {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} увімкнено +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`NodeOutOfServiceVolumeDetach`, і вузол відзначений як такий, що вийшов з ладу з такою позначкою, Podʼи на вузлі будуть насильно видалені, якщо на них немає відповідних toleration, і операції відʼєднання томів для завершення Podʼів +на вузлі відбудуться негайно. Це дозволяє Podʼам на вузлі, що вийшов із строю, швидко відновитися на іншому вузлі. + +Під час такого вимкання робота Podʼів завершується у дві фази: + +1. Насильно видаляються Podʼи, які не мають відповідних toleration `out-of-service`. +2. Негайно виконується операція відʼєднання тома для таких Podʼів. + +{{< note >}} + +- Перш ніж додавати позначку `node.kubernetes.io/out-of-service`, слід перевірити, що вузол вже перебуває в стані припиення роботи чи вимкнення (не в середині перезавантаження). +- Користувач повинен вручну видалити позначку "вийшов із строю" після того, як podʼи будуть переміщені на новий вузол, і користувач перевірив, що вимкнений вузол відновився, оскільки саме користувач додав позначку на початку. +{{< /note >}} + +## Керування swapʼом {#swap-memory} + +{{< feature-state feature_gate_name="NodeSwap" >}} + +Щоб увімкнути swap на вузлі, feature gate `NodeSwap` повинен бути активований на +kubelet, і прапорець командного рядка `--fail-swap-on` або [параметр конфігурації](/docs/reference/config-api/kubelet-config.v1beta1/) `failSwapOn` повинен бути встановлений в значення false. + +{{< warning >}} +Коли увімкнено swap, дані Kubernetes, такі як вміст обʼєктів Secret, які були записані у tmpfs, тепер можуть переноситись на диск. +{{< /warning >}} + +Користувач також може налаштувати `memorySwap.swapBehavior`, щоб вказати, як вузол буде використовувати swap. Наприклад, + +```yaml +memorySwap: + swapBehavior: UnlimitedSwap +``` + +- `UnlimitedSwap` (типово): Робочі навантаження Kubernetes можуть використовувати стільки swap, скільки вони запитують, до ліміту системи. +- `LimitedSwap`: Використання робочими навантаженнями Kubernetes swap обмежено. Тільки Podʼи Burstable QoS мають право використовувати swap. + +Якщо конфігурація для `memorySwap` не вказана, і feature gate увімкнено, типово kubelet застосовує тe ж самe поведінкe, що й налаштування `UnlimitedSwap`. + +З `LimitedSwap`, Podʼам, які не відносяться до класифікації Burstable QoS (тобто Podʼи QoS `BestEffort`/`Guaranteed`), заборонено використовувати swap. Для забезпечення гарантій безпеки і справності вузла цим Podʼам заборонено використовувати swap при включеному `LimitedSwap`. + +Перед тим як розглядати обчислення ліміту swap, необхідно визначити наступне: + +- `nodeTotalMemory`: Загальна кількість фізичної памʼяті, доступної на вузлі. +- `totalPodsSwapAvailable`: Загальний обсяг swap на вузлі, доступний для використання Podʼами (деякий swap може бути зарезервовано для системного використання). +- `containerMemoryRequest`: Запит на памʼять для контейнера. + +Ліміт swap налаштовується так: `(containerMemoryRequest / nodeTotalMemory) * totalPodsSwapAvailable`. + +Важливо враховувати, що для контейнерів у Podʼах Burstable QoS можна +відмовитися від використання swap, вказавши запити на памʼять, рівні лімітам памʼяті. Контейнери, налаштовані таким чином, не матимуть доступу до swap. + +Swap підтримується тільки з **cgroup v2**, cgroup v1 не підтримується. + +Для отримання додаткової інформації, а також для допомоги у тестуванні та надання зворотного звʼязку, будь ласка, перегляньте блог-пост [Kubernetes 1.28: NodeSwap виходить у Beta1](/blog/2023/08/24/swap-linux-beta/), [KEP-2400](https://github.com/kubernetes/enhancements/issues/4128) та його [проєкт концепції](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md). + +## {{% heading "whatsnext" %}} + +Дізнайтеся більше про наступне: + +- [Компоненти](/docs/concepts/overview/components/#node-components), з яких складається вузол. +- [Визначення API для вузла](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). +- [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) у документі з дизайну архітектури. +- [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). +- [Менеджери ресурсів вузла](/docs/concepts/policy/node-resource-managers/). +- [Управління ресурсами для вузлів з операційною системою Windows](/docs/concepts/configuration/windows-resource-management/). diff --git a/content/uk/docs/concepts/cluster-administration/_index.md b/content/uk/docs/concepts/cluster-administration/_index.md new file mode 100644 index 0000000000000..9852b203d88cc --- /dev/null +++ b/content/uk/docs/concepts/cluster-administration/_index.md @@ -0,0 +1,77 @@ +--- +title: Адміністрування кластеру +rewiewers: +- davidopp +- lavalamp +weight: 100 +content_type: concept +description: > + Деталі низького рівня, що стосуються створення та адміністрування кластера Kubernetes. +no_list: true +card: + name: setup + weight: 60 + anchors: + - anchor: "#securing-a-cluster" + title: Забезпечення роботи кластера +--- + + + +Огляд адміністрування кластера призначений для всіх, хто створює або адмініструє кластер Kubernetes. Він передбачає певний рівень знайомства з основними [концепціями](/docs/concepts/). + + + +## Планування кластера {#planning-a-cluster} + +Ознайомтеся з посібниками в розділі [Встановлення](/docs/setup/) для прикладів планування, налаштування та конфігурації кластерів Kubernetes. Рішення, перераховані в цій статті, називаються *distros*. + +{{< note >}} +Не всі distros активно підтримуються. Вибирайте distros, які були протестовані з останньою версією Kubernetes. +{{< /note >}} + +Перед вибором посібника врахуйте наступні моменти: + +* Чи хочете ви спробувати Kubernetes на своєму компʼютері, чи хочете побудувати кластер високої доступності з кількома вузлами? Вибирайте distros, які найкраще підходять для ваших потреб. +* Чи будете ви використовувати **кластер Kubernetes, розміщений на хостингу**, такому як [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), чи **створюватимете свій власний кластер**? +* Чи буде ваш кластер **на місці**, чи **в хмарі (IaaS)**? Kubernetes напряму не підтримує гібридні кластери. Замість цього ви можете налаштувати кілька кластерів. +* **Якщо ви налаштовуєте Kubernetes на місці**, розгляньте, яка [модель мережі](/docs/concepts/cluster-administration/networking/) підходить найкраще. +* Чи будете ви запускати Kubernetes на **"bare metal" обладнанні** чи на **віртуальних машинах (VMs)**? +* Ви **хочете мати робочий кластер**, чи плануєте **активний розвиток коду проєкту Kubernetes**? Якщо останнє, вибирайте distros, які активно розвиваються. Деякі distros використовують лише бінарні релізи, але пропонують більшу різноманітність вибору. +* Ознайомтеся з [компонентами](/docs/concepts/overview/components/), необхідними для запуску кластера. + +## Адміністрування кластера {#managing-a-cluster} + +* Дізнайтеся, як [керувати вузлами](/docs/concepts/architecture/nodes/). + +* Дізнайтеся, як налаштовувати та керувати [квотою ресурсів](/docs/concepts/policy/resource-quotas/) для спільних кластерів. + +## Захист кластера {#securing-a-cluster} + +* [Генерація сертифікатів](/docs/tasks/administer-cluster/certificates/) описує кроки генерації сертифікатів використовуючи різні інструменти. + +* [Оточення контейнерів Kubernetes](/docs/concepts/container-environment/) описує оточення для контейнерів, які керуються за допомогою kubelet на вузлах кластера. + +* [Керування доступом до API Kubernetes](/docs/concepts/security/controlling-access/) описує, як Kubernetes реал керування доступом до API. + +* [Автентифікація](/docs/reference/access-authn-authz/authentication/) пояснює принципи автентифікації в Kubernetes, включаючи різні методи автентифікації та налаштування. + +* [Авторизація](/docs/reference/access-authn-authz/authorization/) відрізняється від автентифікації, контролює як обробляються HTTP-запити. + +* [Використання admission-контролерів](/docs/reference/access-authn-authz/admission-controllers/) описує втулки, які перехоплюють запити до API Kubernetes після автентифікації та авторизації. + +* [Використання Sysctls в кластері Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) описує, як використовувати інструмент командного рядка `sysctl` для налаштування параметрів ядра. + +* [Аудит](/docs/tasks/debug-cluster/audit/) описує, як взаємодіяти з аудитом подій в Kubernetes. + +### Захист kubelеt {#securing-kubelet} + +* [Комунікація Control Plane—Node](/docs/concepts/architecture/control-plane-node-communication/) +* [Розгортання TLS](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) +* [Автентифікація/авторизація kubelet](/docs/reference/access-authn-authz/kubelet-authn-authz/) + +## Додаткові служби кластера {#optional-cluster-services} + +* [Інтеграція DNS](/docs/concepts/services-networking/dns-pod-service/) описує, як надавати DNS-імена безпосередньо службам Kubernetes. + +* [Логування та моніторинг активності кластера](/docs/concepts/cluster-administration/logging/) пояснює, як працює логування в Kubernetes та як його реалізувати. diff --git a/content/uk/docs/concepts/configuration/_index.md b/content/uk/docs/concepts/configuration/_index.md index 588d144f6e596..75ea8c8671ccc 100644 --- a/content/uk/docs/concepts/configuration/_index.md +++ b/content/uk/docs/concepts/configuration/_index.md @@ -1,5 +1,7 @@ --- title: "Конфігурація" weight: 80 +description: > + Ресурси, які Kubernetes надає для конфігурації `Pod`ів. --- diff --git a/content/uk/docs/concepts/configuration/manage-resources-containers.md b/content/uk/docs/concepts/configuration/manage-resources-containers.md new file mode 100644 index 0000000000000..1144df38b220b --- /dev/null +++ b/content/uk/docs/concepts/configuration/manage-resources-containers.md @@ -0,0 +1,826 @@ +--- +title: Керування ресурсами Podʼів та Контейнерів +content_type: concept +weight: 40 +feature: + title: Автоматичне пакування контейнерів + description: > + Автоматично розміщує контейнери на вузлах, враховуючи їх вимоги до ресурсів та інші обмеження, не жертвуючи при цьому доступністю. Поєднуючи критичні та некритичні завдання, можна покращити використання ресурсів разом з їх заощадженням. +--- + + + +When you specify a {{< glossary_tooltip term_id="pod" >}}, you can optionally specify how much of each resource a +{{< glossary_tooltip text="container" term_id="container" >}} needs. The most common resources to specify are CPU and memory +(RAM); there are others. + +When you specify the resource _request_ for containers in a Pod, the +{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} uses this information to decide which node to place the Pod on. +When you specify a resource _limit_ for a container, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} enforces those +limits so that the running container is not allowed to use more of that resource +than the limit you set. The kubelet also reserves at least the _request_ amount of +that system resource specifically for that container to use. + + + +## Requests and limits + +If the node where a Pod is running has enough of a resource available, it's possible (and +allowed) for a container to use more resource than its `request` for that resource specifies. +However, a container is not allowed to use more than its resource `limit`. + +For example, if you set a `memory` request of 256 MiB for a container, and that container is in +a Pod scheduled to a Node with 8GiB of memory and no other Pods, then the container can try to use +more RAM. + +If you set a `memory` limit of 4GiB for that container, the kubelet (and +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}) enforce the limit. +The runtime prevents the container from using more than the configured resource limit. For example: +when a process in the container tries to consume more than the allowed amount of memory, +the system kernel terminates the process that attempted the allocation, with an out of memory +(OOM) error. + +Limits can be implemented either reactively (the system intervenes once it sees a violation) +or by enforcement (the system prevents the container from ever exceeding the limit). Different +runtimes can have different ways to implement the same restrictions. + +{{< note >}} +If you specify a limit for a resource, but do not specify any request, and no admission-time +mechanism has applied a default request for that resource, then Kubernetes copies the limit +you specified and uses it as the requested value for the resource. +{{< /note >}} + +## Resource types + +*CPU* and *memory* are each a *resource type*. A resource type has a base unit. +CPU represents compute processing and is specified in units of [Kubernetes CPUs](#meaning-of-cpu). +Memory is specified in units of bytes. +For Linux workloads, you can specify _huge page_ resources. +Huge pages are a Linux-specific feature where the node kernel allocates blocks of memory +that are much larger than the default page size. + +For example, on a system where the default page size is 4KiB, you could specify a limit, +`hugepages-2Mi: 80Mi`. If the container tries allocating over 40 2MiB huge pages (a +total of 80 MiB), that allocation fails. + +{{< note >}} +You cannot overcommit `hugepages-*` resources. +This is different from the `memory` and `cpu` resources. +{{< /note >}} + +CPU and memory are collectively referred to as *compute resources*, or *resources*. Compute +resources are measurable quantities that can be requested, allocated, and +consumed. They are distinct from +[API resources](/docs/concepts/overview/kubernetes-api/). API resources, such as Pods and +[Services](/docs/concepts/services-networking/service/) are objects that can be read and modified +through the Kubernetes API server. + +## Resource requests and limits of Pod and container + +For each container, you can specify resource limits and requests, +including the following: + +* `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-` + +Although you can only specify requests and limits for individual containers, +it is also useful to think about the overall resource requests and limits for +a Pod. +For a particular resource, a *Pod resource request/limit* is the sum of the +resource requests/limits of that type for each container in the Pod. + +## Resource units in Kubernetes + +### CPU resource units {#meaning-of-cpu} + +Limits and requests for CPU resources are measured in *cpu* units. +In Kubernetes, 1 CPU unit is equivalent to **1 physical CPU core**, +or **1 virtual core**, depending on whether the node is a physical host +or a virtual machine running inside a physical machine. + +Fractional requests are allowed. When you define a container with +`spec.containers[].resources.requests.cpu` set to `0.5`, you are requesting half +as much CPU time compared to if you asked for `1.0` CPU. +For CPU resource units, the [quantity](/docs/reference/kubernetes-api/common-definitions/quantity/) expression `0.1` is equivalent to the +expression `100m`, which can be read as "one hundred millicpu". Some people say +"one hundred millicores", and this is understood to mean the same thing. + +CPU resource is always specified as an absolute amount of resource, never as a relative amount. For example, +`500m` CPU represents the roughly same amount of computing power whether that container +runs on a single-core, dual-core, or 48-core machine. + +{{< note >}} +Kubernetes doesn't allow you to specify CPU resources with a precision finer than +`1m` or `0.001` CPU. To avoid accidentally using an invalid CPU quantity, it's useful to specify CPU units using the milliCPU form +instead of the decimal form when using less than 1 CPU unit. + +For example, you have a Pod that uses `5m` or `0.005` CPU and would like to decrease +its CPU resources. By using the decimal form, it's harder to spot that `0.0005` CPU +is an invalid value, while by using the milliCPU form, it's easier to spot that +`0.5m` is an invalid value. +{{< /note >}} + +### Memory resource units {#meaning-of-memory} + +Limits and requests for `memory` are measured in bytes. You can express memory as +a plain integer or as a fixed-point number using one of these +[quantity](/docs/reference/kubernetes-api/common-definitions/quantity/) suffixes: +E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, +Mi, Ki. For example, the following represent roughly the same value: + +```shell +128974848, 129e6, 129M, 128974848000m, 123Mi +``` + +Pay attention to the case of the suffixes. If you request `400m` of memory, this is a request +for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`) +or 400 megabytes (`400M`). + +## Container resources example {#example-1} + +The following Pod has two containers. Both containers are defined with a request for +0.25 CPU +and 64MiB (226 bytes) of memory. Each container has a limit of 0.5 +CPU and 128MiB of memory. You can say the Pod has a request of 0.5 CPU and 128 +MiB of memory, and a limit of 1 CPU and 256MiB of memory. + +```yaml +--- +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: app + image: images.my-company.example/app:v4 + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" + - name: log-aggregator + image: images.my-company.example/log-aggregator:v6 + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" +``` + +## How Pods with resource requests are scheduled + +When you create a Pod, the Kubernetes scheduler selects a node for the Pod to +run on. Each node has a maximum capacity for each of the resource types: the +amount of CPU and memory it can provide for Pods. The scheduler ensures that, +for each resource type, the sum of the resource requests of the scheduled +containers is less than the capacity of the node. +Note that although actual memory +or CPU resource usage on nodes is very low, the scheduler still refuses to place +a Pod on a node if the capacity check fails. This protects against a resource +shortage on a node when resource usage later increases, for example, during a +daily peak in request rate. + +## How Kubernetes applies resource requests and limits {#how-pods-with-resource-limits-are-run} + +When the kubelet starts a container as part of a Pod, the kubelet passes that container's +requests and limits for memory and CPU to the container runtime. + +On Linux, the container runtime typically configures +kernel {{< glossary_tooltip text="cgroups" term_id="cgroup" >}} that apply and enforce the +limits you defined. + +- The CPU limit defines a hard ceiling on how much CPU time that the container can use. + During each scheduling interval (time slice), the Linux kernel checks to see if this + limit is exceeded; if so, the kernel waits before allowing that cgroup to resume execution. +- The CPU request typically defines a weighting. If several different containers (cgroups) + want to run on a contended system, workloads with larger CPU requests are allocated more + CPU time than workloads with small requests. +- The memory request is mainly used during (Kubernetes) Pod scheduling. On a node that uses + cgroups v2, the container runtime might use the memory request as a hint to set + `memory.min` and `memory.low`. +- The memory limit defines a memory limit for that cgroup. If the container tries to + allocate more memory than this limit, the Linux kernel out-of-memory subsystem activates + and, typically, intervenes by stopping one of the processes in the container that tried + to allocate memory. If that process is the container's PID 1, and the container is marked + as restartable, Kubernetes restarts the container. +- The memory limit for the Pod or container can also apply to pages in memory backed + volumes, such as an `emptyDir`. The kubelet tracks `tmpfs` emptyDir volumes as container + memory use, rather than as local ephemeral storage. + +If a container exceeds its memory request and the node that it runs on becomes short of +memory overall, it is likely that the Pod the container belongs to will be +{{< glossary_tooltip text="evicted" term_id="eviction" >}}. + +A container might or might not be allowed to exceed its CPU limit for extended periods of time. +However, container runtimes don't terminate Pods or containers for excessive CPU usage. + +To determine whether a container cannot be scheduled or is being killed due to resource limits, +see the [Troubleshooting](#troubleshooting) section. + +### Monitoring compute & memory resource usage + +The kubelet reports the resource usage of a Pod as part of the Pod +[`status`](/docs/concepts/overview/working-with-objects/#object-spec-and-status). + +If optional [tools for monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) +are available in your cluster, then Pod resource usage can be retrieved either +from the [Metrics API](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api) +directly or from your monitoring tools. + +## Local ephemeral storage + + +{{< feature-state for_k8s_version="v1.25" state="stable" >}} + +Nodes have local ephemeral storage, backed by +locally-attached writeable devices or, sometimes, by RAM. +"Ephemeral" means that there is no long-term guarantee about durability. + +Pods use ephemeral local storage for scratch space, caching, and for logs. +The kubelet can provide scratch space to Pods using local ephemeral storage to +mount [`emptyDir`](/docs/concepts/storage/volumes/#emptydir) + {{< glossary_tooltip term_id="volume" text="volumes" >}} into containers. + +The kubelet also uses this kind of storage to hold +[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level), +container images, and the writable layers of running containers. + +{{< caution >}} +If a node fails, the data in its ephemeral storage can be lost. +Your applications cannot expect any performance SLAs (disk IOPS for example) +from local ephemeral storage. +{{< /caution >}} + + +{{< note >}} +To make the resource quota work on ephemeral-storage, two things need to be done: + +* An admin sets the resource quota for ephemeral-storage in a namespace. +* A user needs to specify limits for the ephemeral-storage resource in the Pod spec. + +If the user doesn't specify the ephemeral-storage resource limit in the Pod spec, +the resource quota is not enforced on ephemeral-storage. + +{{< /note >}} + +Kubernetes lets you track, reserve and limit the amount +of ephemeral local storage a Pod can consume. + +### Configurations for local ephemeral storage + +Kubernetes supports two ways to configure local ephemeral storage on a node: +{{< tabs name="local_storage_configurations" >}} +{{% tab name="Single filesystem" %}} +In this configuration, you place all different kinds of ephemeral local data +(`emptyDir` volumes, writeable layers, container images, logs) into one filesystem. +The most effective way to configure the kubelet means dedicating this filesystem +to Kubernetes (kubelet) data. + +The kubelet also writes +[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) +and treats these similarly to ephemeral local storage. + +The kubelet writes logs to files inside its configured log directory (`/var/log` +by default); and has a base directory for other locally stored data +(`/var/lib/kubelet` by default). + +Typically, both `/var/lib/kubelet` and `/var/log` are on the system root filesystem, +and the kubelet is designed with that layout in mind. + +Your node can have as many other filesystems, not used for Kubernetes, +as you like. +{{% /tab %}} +{{% tab name="Two filesystems" %}} +You have a filesystem on the node that you're using for ephemeral data that +comes from running Pods: logs, and `emptyDir` volumes. You can use this filesystem +for other data (for example: system logs not related to Kubernetes); it can even +be the root filesystem. + +The kubelet also writes +[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) +into the first filesystem, and treats these similarly to ephemeral local storage. + +You also use a separate filesystem, backed by a different logical storage device. +In this configuration, the directory where you tell the kubelet to place +container image layers and writeable layers is on this second filesystem. + +The first filesystem does not hold any image layers or writeable layers. + +Your node can have as many other filesystems, not used for Kubernetes, +as you like. +{{% /tab %}} +{{< /tabs >}} + +The kubelet can measure how much local storage it is using. It does this provided +that you have set up the node using one of the supported configurations for local +ephemeral storage. + +If you have a different configuration, then the kubelet does not apply resource +limits for ephemeral local storage. + +{{< note >}} +The kubelet tracks `tmpfs` emptyDir volumes as container memory use, rather +than as local ephemeral storage. +{{< /note >}} + +{{< note >}} +The kubelet will only track the root filesystem for ephemeral storage. OS layouts that mount a separate disk to `/var/lib/kubelet` or `/var/lib/containers` will not report ephemeral storage correctly. +{{< /note >}} + +### Setting requests and limits for local ephemeral storage + +You can specify `ephemeral-storage` for managing local ephemeral storage. Each +container of a Pod can specify either or both of the following: + +* `spec.containers[].resources.limits.ephemeral-storage` +* `spec.containers[].resources.requests.ephemeral-storage` + +Limits and requests for `ephemeral-storage` are measured in byte quantities. +You can express storage as a plain integer or as a fixed-point number using one of these suffixes: +E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, +Mi, Ki. For example, the following quantities all represent roughly the same value: + +- `128974848` +- `129e6` +- `129M` +- `123Mi` + +Pay attention to the case of the suffixes. If you request `400m` of ephemeral-storage, this is a request +for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`) +or 400 megabytes (`400M`). + +In the following example, the Pod has two containers. Each container has a request of +2GiB of local ephemeral storage. Each container has a limit of 4GiB of local ephemeral +storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and +a limit of 8GiB of local ephemeral storage. 500Mi of that limit could be +consumed by the `emptyDir` volume. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: app + image: images.my-company.example/app:v4 + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + volumeMounts: + - name: ephemeral + mountPath: "/tmp" + - name: log-aggregator + image: images.my-company.example/log-aggregator:v6 + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + volumeMounts: + - name: ephemeral + mountPath: "/tmp" + volumes: + - name: ephemeral + emptyDir: + sizeLimit: 500Mi +``` + +### How Pods with ephemeral-storage requests are scheduled + +When you create a Pod, the Kubernetes scheduler selects a node for the Pod to +run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. +For more information, see +[Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). + +The scheduler ensures that the sum of the resource requests of the scheduled containers is less than the capacity of the node. + +### Ephemeral storage consumption management {#resource-emphemeralstorage-consumption} + +If the kubelet is managing local ephemeral storage as a resource, then the +kubelet measures storage use in: + +- `emptyDir` volumes, except _tmpfs_ `emptyDir` volumes +- directories holding node-level logs +- writeable container layers + +If a Pod is using more ephemeral storage than you allow it to, the kubelet +sets an eviction signal that triggers Pod eviction. + +For container-level isolation, if a container's writable layer and log +usage exceeds its storage limit, the kubelet marks the Pod for eviction. + +For pod-level isolation the kubelet works out an overall Pod storage limit by +summing the limits for the containers in that Pod. In this case, if the sum of +the local ephemeral storage usage from all containers and also the Pod's `emptyDir` +volumes exceeds the overall Pod storage limit, then the kubelet also marks the Pod +for eviction. + +{{< caution >}} +If the kubelet is not measuring local ephemeral storage, then a Pod +that exceeds its local storage limit will not be evicted for breaching +local storage resource limits. + +However, if the filesystem space for writeable container layers, node-level logs, +or `emptyDir` volumes falls low, the node +{{< glossary_tooltip text="taints" term_id="taint" >}} itself as short on local storage +and this taint triggers eviction for any Pods that don't specifically tolerate the taint. + +See the supported [configurations](#configurations-for-local-ephemeral-storage) +for ephemeral local storage. +{{< /caution >}} + +The kubelet supports different ways to measure Pod storage use: + +{{< tabs name="resource-emphemeralstorage-measurement" >}} +{{% tab name="Periodic scanning" %}} +The kubelet performs regular, scheduled checks that scan each +`emptyDir` volume, container log directory, and writeable container layer. + +The scan measures how much space is used. + +{{< note >}} +In this mode, the kubelet does not track open file descriptors +for deleted files. + +If you (or a container) create a file inside an `emptyDir` volume, +something then opens that file, and you delete the file while it is +still open, then the inode for the deleted file stays until you close +that file but the kubelet does not categorize the space as in use. +{{< /note >}} +{{% /tab %}} +{{% tab name="Filesystem project quota" %}} + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +Project quotas are an operating-system level feature for managing +storage use on filesystems. With Kubernetes, you can enable project +quotas for monitoring storage use. Make sure that the filesystem +backing the `emptyDir` volumes, on the node, provides project quota support. +For example, XFS and ext4fs offer project quotas. + +{{< note >}} +Project quotas let you monitor storage use; they do not enforce limits. +{{< /note >}} + +Kubernetes uses project IDs starting from `1048576`. The IDs in use are +registered in `/etc/projects` and `/etc/projid`. If project IDs in +this range are used for other purposes on the system, those project +IDs must be registered in `/etc/projects` and `/etc/projid` so that +Kubernetes does not use them. + +Quotas are faster and more accurate than directory scanning. When a +directory is assigned to a project, all files created under a +directory are created in that project, and the kernel merely has to +keep track of how many blocks are in use by files in that project. +If a file is created and deleted, but has an open file descriptor, +it continues to consume space. Quota tracking records that space accurately +whereas directory scans overlook the storage used by deleted files. + +If you want to use project quotas, you should: + +* Enable the `LocalStorageCapacityIsolationFSQuotaMonitoring=true` + [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) + using the `featureGates` field in the + [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) + or the `--feature-gates` command line flag. + +* Ensure that the root filesystem (or optional runtime filesystem) + has project quotas enabled. All XFS filesystems support project quotas. + For ext4 filesystems, you need to enable the project quota tracking feature + while the filesystem is not mounted. + + ```bash + # For ext4, with /dev/block-device not mounted + sudo tune2fs -O project -Q prjquota /dev/block-device + ``` + +* Ensure that the root filesystem (or optional runtime filesystem) is + mounted with project quotas enabled. For both XFS and ext4fs, the + mount option is named `prjquota`. + +{{% /tab %}} +{{< /tabs >}} + +## Extended resources + +Extended resources are fully-qualified resource names outside the +`kubernetes.io` domain. They allow cluster operators to advertise and users to +consume the non-Kubernetes-built-in resources. + +There are two steps required to use Extended Resources. First, the cluster +operator must advertise an Extended Resource. Second, users must request the +Extended Resource in Pods. + +### Managing extended resources + +#### Node-level extended resources + +Node-level extended resources are tied to nodes. + +##### Device plugin managed resources +See [Device +Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +for how to advertise device plugin managed resources on each node. + +##### Other resources + +To advertise a new node-level extended resource, the cluster operator can +submit a `PATCH` HTTP request to the API server to specify the available +quantity in the `status.capacity` for a node in the cluster. After this +operation, the node's `status.capacity` will include a new resource. The +`status.allocatable` field is updated automatically with the new resource +asynchronously by the kubelet. + +Because the scheduler uses the node's `status.allocatable` value when +evaluating Pod fitness, the scheduler only takes account of the new value after +that asynchronous update. There may be a short delay between patching the +node capacity with a new resource and the time when the first Pod that requests +the resource can be scheduled on that node. + +**Example:** + +Here is an example showing how to use `curl` to form an HTTP request that +advertises five "example.com/foo" resources on node `k8s-node-1` whose master +is `k8s-master`. + +```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 >}} +In the preceding request, `~1` is the encoding for the character `/` +in the patch path. The operation path value in JSON-Patch is interpreted as a +JSON-Pointer. For more details, see +[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3). +{{< /note >}} + +#### Cluster-level extended resources + +Cluster-level extended resources are not tied to nodes. They are usually managed +by scheduler extenders, which handle the resource consumption and resource quota. + +You can specify the extended resources that are handled by scheduler extenders +in [scheduler configuration](/docs/reference/config-api/kube-scheduler-config.v1/) + +**Example:** + +The following configuration for a scheduler policy indicates that the +cluster-level extended resource "example.com/foo" is handled by the scheduler +extender. + +- The scheduler sends a Pod to the scheduler extender only if the Pod requests + "example.com/foo". +- The `ignoredByScheduler` field specifies that the scheduler does not check + the "example.com/foo" resource in its `PodFitsResources` predicate. + +```json +{ + "kind": "Policy", + "apiVersion": "v1", + "extenders": [ + { + "urlPrefix":"", + "bindVerb": "bind", + "managedResources": [ + { + "name": "example.com/foo", + "ignoredByScheduler": true + } + ] + } + ] +} +``` + +### Consuming extended resources + +Users can consume extended resources in Pod specs like CPU and memory. +The scheduler takes care of the resource accounting so that no more than the +available amount is simultaneously allocated to Pods. + +The API server restricts quantities of extended resources to whole numbers. +Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of +_invalid_ quantities are `0.5` and `1500m`. + +{{< note >}} +Extended resources replace Opaque Integer Resources. +Users can use any domain name prefix other than `kubernetes.io` which is reserved. +{{< /note >}} + +To consume an extended resource in a Pod, include the resource name as a key +in the `spec.containers[].resources.limits` map in the container spec. + +{{< note >}} +Extended resources cannot be overcommitted, so request and limit +must be equal if both are present in a container spec. +{{< /note >}} + +A Pod is scheduled only if all of the resource requests are satisfied, including +CPU, memory and any extended resources. The Pod remains in the `PENDING` state +as long as the resource request cannot be satisfied. + +**Example:** + +The Pod below requests 2 CPUs and 1 "example.com/foo" (an extended resource). + +```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 +``` + +## PID limiting + +Process ID (PID) limits allow for the configuration of a kubelet +to limit the number of PIDs that a given Pod can consume. See +[PID Limiting](/docs/concepts/policy/pid-limiting/) for information. + +## Troubleshooting + +### My Pods are pending with event message `FailedScheduling` + +If the scheduler cannot find any node where a Pod can fit, the Pod remains +unscheduled until a place can be found. An +[Event](/docs/reference/kubernetes-api/cluster-resources/event-v1/) is produced +each time the scheduler fails to find a place for the Pod. You can use `kubectl` +to view the events for a Pod; for example: + +```shell +kubectl describe pod frontend | grep -A 9999999999 Events +``` +``` +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Warning FailedScheduling 23s default-scheduler 0/42 nodes available: insufficient cpu +``` + +In the preceding example, the Pod named "frontend" fails to be scheduled due to +insufficient CPU resource on any node. Similar error messages can also suggest +failure due to insufficient memory (PodExceedsFreeMemory). In general, if a Pod +is pending with a message of this type, there are several things to try: + +- Add more nodes to the cluster. +- Terminate unneeded Pods to make room for pending Pods. +- Check that the Pod is not larger than all the nodes. For example, if all the + nodes have a capacity of `cpu: 1`, then a Pod with a request of `cpu: 1.1` will + never be scheduled. +- Check for node taints. If most of your nodes are tainted, and the new Pod does + not tolerate that taint, the scheduler only considers placements onto the + remaining nodes that don't have that taint. + +You can check node capacities and amounts allocated with the +`kubectl describe nodes` command. For example: + +```shell +kubectl describe nodes e2e-test-node-pool-4lw4 +``` +``` +Name: e2e-test-node-pool-4lw4 +[ ... lines removed for clarity ...] +Capacity: + cpu: 2 + memory: 7679792Ki + pods: 110 +Allocatable: + cpu: 1800m + memory: 7474992Ki + pods: 110 +[ ... lines removed for clarity ...] +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 (11%) 1070Mi (13%) +``` + +In the preceding output, you can see that if a Pod requests more than 1.120 CPUs +or more than 6.23Gi of memory, that Pod will not fit on the node. + +By looking at the “Pods” section, you can see which Pods are taking up space on +the node. + +The amount of resources available to Pods is less than the node capacity because +system daemons use a portion of the available resources. Within the Kubernetes API, +each Node has a `.status.allocatable` field +(see [NodeStatus](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeStatus) +for details). + +The `.status.allocatable` field describes the amount of resources that are available +to Pods on that node (for example: 15 virtual CPUs and 7538 MiB of memory). +For more information on node allocatable resources in Kubernetes, see +[Reserve Compute Resources for System Daemons](/docs/tasks/administer-cluster/reserve-compute-resources/). + +You can configure [resource quotas](/docs/concepts/policy/resource-quotas/) +to limit the total amount of resources that a namespace can consume. +Kubernetes enforces quotas for objects in particular namespace when there is a +ResourceQuota in that namespace. +For example, if you assign specific namespaces to different teams, you +can add ResourceQuotas into those namespaces. Setting resource quotas helps to +prevent one team from using so much of any resource that this over-use affects other teams. + +You should also consider what access you grant to that namespace: +**full** write access to a namespace allows someone with that access to remove any +resource, including a configured ResourceQuota. + +### My container is terminated + +Your container might get terminated because it is resource-starved. To check +whether a container is being killed because it is hitting a resource limit, call +`kubectl describe pod` on the Pod of interest: + +```shell +kubectl describe pod simmemleak-hra99 +``` + +The output is similar to: +``` +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 +Containers: + simmemleak: + Image: saadali/simmemleak:latest + Limits: + cpu: 100m + memory: 50Mi + State: Running + Started: Tue, 07 Jul 2019 12:54:41 -0700 + Last State: Terminated + Reason: OOMKilled + Exit Code: 137 + Started: Fri, 07 Jul 2019 12:54:30 -0700 + Finished: Fri, 07 Jul 2019 12:54:33 -0700 + Ready: False + Restart Count: 5 +Conditions: + Type Status + Ready False +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 42s default-scheduler Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f + Normal Pulled 41s kubelet Container image "saadali/simmemleak:latest" already present on machine + Normal Created 41s kubelet Created container simmemleak + Normal Started 40s kubelet Started container simmemleak + Normal Killing 32s kubelet Killing container with id ead3fb35-5cf5-44ed-9ae1-488115be66c6: Need to kill Pod +``` + +In the preceding example, the `Restart Count: 5` indicates that the `simmemleak` +container in the Pod was terminated and restarted five times (so far). +The `OOMKilled` reason shows that the container tried to use more memory than its limit. + +Your next step might be to check the application code for a memory leak. If you +find that the application is behaving how you expect, consider setting a higher +memory limit (and possibly request) for that container. + +## {{% heading "whatsnext" %}} + +* Get hands-on experience [assigning Memory resources to containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/). +* Get hands-on experience [assigning CPU resources to containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/). +* Read how the API reference defines a [container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) + and its [resource requirements](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources) +* Read about [project quotas](https://www.linux.org/docs/man8/xfs_quota.html) in XFS +* Read more about the [kube-scheduler configuration reference (v1)](/docs/reference/config-api/kube-scheduler-config.v1/) +* Read more about [Quality of Service classes for Pods](/docs/concepts/workloads/pods/pod-qos/) + diff --git a/content/uk/docs/concepts/configuration/secret.md b/content/uk/docs/concepts/configuration/secret.md new file mode 100644 index 0000000000000..b235c8226ab99 --- /dev/null +++ b/content/uk/docs/concepts/configuration/secret.md @@ -0,0 +1,698 @@ +--- +reviewers: + - mikedanese +title: Secrets +content_type: concept +feature: + title: Управління Secret та налаштуваннями + description: > + Розгортання та оновлення Secrets та налаштуваннями застосунків без перебудови образу та без розкриття Secrets в конфігурації стеку. +weight: 30 +--- + + + +A Secret is an object that contains a small amount of sensitive data such as +a password, a token, or a key. Such information might otherwise be put in a +{{< glossary_tooltip term_id="pod" >}} specification or in a +{{< glossary_tooltip text="container image" term_id="image" >}}. Using a +Secret means that you don't need to include confidential data in your +application code. + +Because Secrets can be created independently of the Pods that use them, there +is less risk of the Secret (and its data) being exposed during the workflow of +creating, viewing, and editing Pods. Kubernetes, and applications that run in +your cluster, can also take additional precautions with Secrets, such as avoiding +writing sensitive data to nonvolatile storage. + +Secrets are similar to {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}} +but are specifically intended to hold confidential data. + +{{< caution >}} +Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store +(etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. +Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read +any Secret in that namespace; this includes indirect access such as the ability to create a +Deployment. + +In order to safely use Secrets, take at least the following steps: + +1. [Enable Encryption at Rest](/docs/tasks/administer-cluster/encrypt-data/) for Secrets. +2. [Enable or configure RBAC rules](/docs/reference/access-authn-authz/authorization/) with + least-privilege access to Secrets. +3. Restrict Secret access to specific containers. +4. [Consider using external Secret store providers](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver). + +For more guidelines to manage and improve the security of your Secrets, refer to +[Good practices for Kubernetes Secrets](/docs/concepts/security/secrets-good-practices). + +{{< /caution >}} + +See [Information security for Secrets](#information-security-for-secrets) for more details. + + + +## Uses for Secrets + +You can use Secrets for purposes such as the following: + +- [Set environment variables for a container](/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data). +- [Provide credentials such as SSH keys or passwords to Pods](/docs/tasks/inject-data-application/distribute-credentials-secure/#provide-prod-test-creds). +- [Allow the kubelet to pull container images from private registries](/docs/tasks/configure-pod-container/pull-image-private-registry/). + +The Kubernetes control plane also uses Secrets; for example, +[bootstrap token Secrets](#bootstrap-token-secrets) are a mechanism to +help automate node registration. + +### Use case: dotfiles in a secret volume + +You can make your data "hidden" by defining a key that begins with a dot. +This key represents a dotfile or "hidden" file. For example, when the following Secret +is mounted into a volume, `secret-volume`, the volume will contain a single file, +called `.secret-file`, and the `dotfile-test-container` will have this file +present at the path `/etc/secret-volume/.secret-file`. + +{{< note >}} +Files beginning with dot characters are hidden from the output of `ls -l`; +you must use `ls -la` to see them when listing directory contents. +{{< /note >}} + +{{% code language="yaml" file="secret/dotfile-secret.yaml" %}} + +### Use case: Secret visible to one container in a Pod + +Consider a program that needs to handle HTTP requests, do some complex business +logic, and then sign some messages with an HMAC. Because it has complex +application logic, there might be an unnoticed remote file reading exploit in +the server, which could expose the private key to an attacker. + +This could be divided into two processes in two containers: a frontend container +which handles user interaction and business logic, but which cannot see the +private key; and a signer container that can see the private key, and responds +to simple signing requests from the frontend (for example, over localhost networking). + +With this partitioned approach, an attacker now has to trick the application +server into doing something rather arbitrary, which may be harder than getting +it to read a file. + +### Alternatives to Secrets + +Rather than using a Secret to protect confidential data, you can pick from alternatives. + +Here are some of your options: + +- If your cloud-native component needs to authenticate to another application that you + know is running within the same Kubernetes cluster, you can use a + [ServiceAccount](/docs/reference/access-authn-authz/authentication/#service-account-tokens) + and its tokens to identify your client. +- There are third-party tools that you can run, either within or outside your cluster, + that manage sensitive data. For example, a service that Pods access over HTTPS, + that reveals a Secret if the client correctly authenticates (for example, with a ServiceAccount + token). +- For authentication, you can implement a custom signer for X.509 certificates, and use + [CertificateSigningRequests](/docs/reference/access-authn-authz/certificate-signing-requests/) + to let that custom signer issue certificates to Pods that need them. +- You can use a [device plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) + to expose node-local encryption hardware to a specific Pod. For example, you can schedule + trusted Pods onto nodes that provide a Trusted Platform Module, configured out-of-band. + +You can also combine two or more of those options, including the option to use Secret objects themselves. + +For example: implement (or deploy) an {{< glossary_tooltip text="operator" term_id="operator-pattern" >}} +that fetches short-lived session tokens from an external service, and then creates Secrets based +on those short-lived session tokens. Pods running in your cluster can make use of the session tokens, +and operator ensures they are valid. This separation means that you can run Pods that are unaware of +the exact mechanisms for issuing and refreshing those session tokens. + +## Types of Secret {#secret-types} + +When creating a Secret, you can specify its type using the `type` field of +the [Secret](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) +resource, or certain equivalent `kubectl` command line flags (if available). +The Secret type is used to facilitate programmatic handling of the Secret data. + +Kubernetes provides several built-in types for some common usage scenarios. +These types vary in terms of the validations performed and the constraints +Kubernetes imposes on them. + +| Built-in Type | Usage | +| ------------------------------------- |---------------------------------------- | +| `Opaque` | arbitrary user-defined data | +| `kubernetes.io/service-account-token` | ServiceAccount token | +| `kubernetes.io/dockercfg` | serialized `~/.dockercfg` file | +| `kubernetes.io/dockerconfigjson` | serialized `~/.docker/config.json` file | +| `kubernetes.io/basic-auth` | credentials for basic authentication | +| `kubernetes.io/ssh-auth` | credentials for SSH authentication | +| `kubernetes.io/tls` | data for a TLS client or server | +| `bootstrap.kubernetes.io/token` | bootstrap token data | + +You can define and use your own Secret type by assigning a non-empty string as the +`type` value for a Secret object (an empty string is treated as an `Opaque` type). + +Kubernetes doesn't impose any constraints on the type name. However, if you +are using one of the built-in types, you must meet all the requirements defined +for that type. + +If you are defining a type of Secret that's for public use, follow the convention +and structure the Secret type to have your domain name before the name, separated +by a `/`. For example: `cloud-hosting.example.net/cloud-api-credentials`. + +### Opaque Secrets + +`Opaque` is the default Secret type if you don't explicitly specify a type in +a Secret manifest. When you create a Secret using `kubectl`, you must use the +`generic` subcommand to indicate an `Opaque` Secret type. For example, the +following command creates an empty Secret of type `Opaque`: + +```shell +kubectl create secret generic empty-secret +kubectl get secret empty-secret +``` + +The output looks like: + +``` +NAME TYPE DATA AGE +empty-secret Opaque 0 2m6s +``` + +The `DATA` column shows the number of data items stored in the Secret. +In this case, `0` means you have created an empty Secret. + +### ServiceAccount token Secrets + +A `kubernetes.io/service-account-token` type of Secret is used to store a +token credential that identifies a +{{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}. This +is a legacy mechanism that provides long-lived ServiceAccount credentials to +Pods. + +In Kubernetes v1.22 and later, the recommended approach is to obtain a +short-lived, automatically rotating ServiceAccount token by using the +[`TokenRequest`](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) +API instead. You can get these short-lived tokens using the following methods: + +* Call the `TokenRequest` API either directly or by using an API client like + `kubectl`. For example, you can use the + [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) + command. +* Request a mounted token in a + [projected volume](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) + in your Pod manifest. Kubernetes creates the token and mounts it in the Pod. + The token is automatically invalidated when the Pod that it's mounted in is + deleted. For details, see + [Launch a Pod using service account token projection](/docs/tasks/configure-pod-container/configure-service-account/#launch-a-pod-using-service-account-token-projection). + +{{< note >}} +You should only create a ServiceAccount token Secret +if you can't use the `TokenRequest` API to obtain a token, +and the security exposure of persisting a non-expiring token credential +in a readable API object is acceptable to you. For instructions, see +[Manually create a long-lived API token for a ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount). +{{< /note >}} + +When using this Secret type, you need to ensure that the +`kubernetes.io/service-account.name` annotation is set to an existing +ServiceAccount name. If you are creating both the ServiceAccount and +the Secret objects, you should create the ServiceAccount object first. + +After the Secret is created, a Kubernetes {{< glossary_tooltip text="controller" term_id="controller" >}} +fills in some other fields such as the `kubernetes.io/service-account.uid` annotation, and the +`token` key in the `data` field, which is populated with an authentication token. + +The following example configuration declares a ServiceAccount token Secret: + +{{% code language="yaml" file="secret/serviceaccount-token-secret.yaml" %}} + +After creating the Secret, wait for Kubernetes to populate the `token` key in the `data` field. + +See the [ServiceAccount](/docs/concepts/security/service-accounts/) +documentation for more information on how ServiceAccounts work. +You can also check the `automountServiceAccountToken` field and the +`serviceAccountName` field of the +[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +for information on referencing ServiceAccount credentials from within Pods. + +### Docker config Secrets + +If you are creating a Secret to store credentials for accessing a container image registry, +you must use one of the following `type` values for that Secret: + +- `kubernetes.io/dockercfg`: store a serialized `~/.dockercfg` which is the + legacy format for configuring Docker command line. The Secret + `data` field contains a `.dockercfg` key whose value is the content of a + base64 encoded `~/.dockercfg` file. +- `kubernetes.io/dockerconfigjson`: store a serialized JSON that follows the + same format rules as the `~/.docker/config.json` file, which is a new format + for `~/.dockercfg`. The Secret `data` field must contain a + `.dockerconfigjson` key for which the value is the content of a base64 + encoded `~/.docker/config.json` file. + +Below is an example for a `kubernetes.io/dockercfg` type of Secret: + +{{% code language="yaml" file="secret/dockercfg-secret.yaml" %}} + +{{< note >}} +If you do not want to perform the base64 encoding, you can choose to use the +`stringData` field instead. +{{< /note >}} + +When you create Docker config Secrets using a manifest, the API +server checks whether the expected key exists in the `data` field, and +it verifies if the value provided can be parsed as a valid JSON. The API +server doesn't validate if the JSON actually is a Docker config file. + +You can also use `kubectl` to create a Secret for accessing a container +registry, such as when you don't have a Docker configuration file: + +```shell +kubectl create secret docker-registry secret-tiger-docker \ + --docker-email=tiger@acme.example \ + --docker-username=tiger \ + --docker-password=pass1234 \ + --docker-server=my-registry.example:5000 +``` + +This command creates a Secret of type `kubernetes.io/dockerconfigjson`. + +Retrieve the `.data.dockerconfigjson` field from that new Secret and decode the +data: + +```shell +kubectl get secret secret-tiger-docker -o jsonpath='{.data.*}' | base64 -d +``` + +The output is equivalent to the following JSON document (which is also a valid +Docker configuration file): + +```json +{ + "auths": { + "my-registry.example:5000": { + "username": "tiger", + "password": "pass1234", + "email": "tiger@acme.example", + "auth": "dGlnZXI6cGFzczEyMzQ=" + } + } +} +``` + +{{< caution >}} +The `auth` value there is base64 encoded; it is obscured but not secret. +Anyone who can read that Secret can learn the registry access bearer token. + +It is suggested to use [credential providers](/docs/tasks/administer-cluster/kubelet-credential-provider/) to dynamically and securely provide pull secrets on-demand. +{{< /caution >}} + +### Basic authentication Secret + +The `kubernetes.io/basic-auth` type is provided for storing credentials needed +for basic authentication. When using this Secret type, the `data` field of the +Secret must contain one of the following two keys: + +- `username`: the user name for authentication +- `password`: the password or token for authentication + +Both values for the above two keys are base64 encoded strings. You can +alternatively provide the clear text content using the `stringData` field in the +Secret manifest. + +The following manifest is an example of a basic authentication Secret: + +{{% code language="yaml" file="secret/basicauth-secret.yaml" %}} + +{{< note >}} +The `stringData` field for a Secret does not work well with server-side apply. +{{< /note >}} + +The basic authentication Secret type is provided only for convenience. +You can create an `Opaque` type for credentials used for basic authentication. +However, using the defined and public Secret type (`kubernetes.io/basic-auth`) helps other +people to understand the purpose of your Secret, and sets a convention for what key names +to expect. +The Kubernetes API verifies that the required keys are set for a Secret of this type. + +### SSH authentication Secrets + +The builtin type `kubernetes.io/ssh-auth` is provided for storing data used in +SSH authentication. When using this Secret type, you will have to specify a +`ssh-privatekey` key-value pair in the `data` (or `stringData`) field +as the SSH credential to use. + +The following manifest is an example of a Secret used for SSH public/private +key authentication: + +{{% code language="yaml" file="secret/ssh-auth-secret.yaml" %}} + +The SSH authentication Secret type is provided only for convenience. +You can create an `Opaque` type for credentials used for SSH authentication. +However, using the defined and public Secret type (`kubernetes.io/ssh-auth`) helps other +people to understand the purpose of your Secret, and sets a convention for what key names +to expect. +The Kubernetes API verifies that the required keys are set for a Secret of this type. + +{{< caution >}} +SSH private keys do not establish trusted communication between an SSH client and +host server on their own. A secondary means of establishing trust is needed to +mitigate "man in the middle" attacks, such as a `known_hosts` file added to a ConfigMap. +{{< /caution >}} + +### TLS Secrets + +The `kubernetes.io/tls` Secret type is for storing +a certificate and its associated key that are typically used for TLS. + +One common use for TLS Secrets is to configure encryption in transit for +an [Ingress](/docs/concepts/services-networking/ingress/), but you can also use it +with other resources or directly in your workload. +When using this type of Secret, the `tls.key` and the `tls.crt` key must be provided +in the `data` (or `stringData`) field of the Secret configuration, although the API +server doesn't actually validate the values for each key. + +As an alternative to using `stringData`, you can use the `data` field to provide +the base64 encoded certificate and private key. For details, see +[Constraints on Secret names and data](#restriction-names-data). + +The following YAML contains an example config for a TLS Secret: + +{{% code language="yaml" file="secret/tls-auth-secret.yaml" %}} + +The TLS Secret type is provided only for convenience. +You can create an `Opaque` type for credentials used for TLS authentication. +However, using the defined and public Secret type (`kubernetes.io/tls`) +helps ensure the consistency of Secret format in your project. The API server +verifies if the required keys are set for a Secret of this type. + +To create a TLS Secret using `kubectl`, use the `tls` subcommand: + +```shell +kubectl create secret tls my-tls-secret \ + --cert=path/to/cert/file \ + --key=path/to/key/file +``` + +The public/private key pair must exist before hand. The public key certificate for `--cert` must be .PEM encoded +and must match the given private key for `--key`. + +### Bootstrap token Secrets + +The `bootstrap.kubernetes.io/token` Secret type is for +tokens used during the node bootstrap process. It stores tokens used to sign +well-known ConfigMaps. + +A bootstrap token Secret is usually created in the `kube-system` namespace and +named in the form `bootstrap-token-` where `` is a 6 character +string of the token ID. + +As a Kubernetes manifest, a bootstrap token Secret might look like the +following: + +{{% code language="yaml" file="secret/bootstrap-token-secret-base64.yaml" %}} + +A bootstrap token Secret has the following keys specified under `data`: + +- `token-id`: A random 6 character string as the token identifier. Required. +- `token-secret`: A random 16 character string as the actual token Secret. Required. +- `description`: A human-readable string that describes what the token is + used for. Optional. +- `expiration`: An absolute UTC time using [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339) specifying when the token + should be expired. Optional. +- `usage-bootstrap-`: A boolean flag indicating additional usage for + the bootstrap token. +- `auth-extra-groups`: A comma-separated list of group names that will be + authenticated as in addition to the `system:bootstrappers` group. + +You can alternatively provide the values in the `stringData` field of the Secret +without base64 encoding them: + +{{% code language="yaml" file="secret/bootstrap-token-secret-literal.yaml" %}} + +{{< note >}} +The `stringData` field for a Secret does not work well with server-side apply. +{{< /note >}} + +## Working with Secrets + +### Creating a Secret + +There are several options to create a Secret: + +- [Use `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [Use a configuration file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [Use the Kustomize tool](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) + +#### Constraints on Secret names and data {#restriction-names-data} + +The name of a Secret object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +You can specify the `data` and/or the `stringData` field when creating a +configuration file for a Secret. The `data` and the `stringData` fields are optional. +The values for all keys in the `data` field have to be base64-encoded strings. +If the conversion to base64 string is not desirable, you can choose to specify +the `stringData` field instead, which accepts arbitrary strings as values. + +The keys of `data` and `stringData` must consist of alphanumeric characters, +`-`, `_` or `.`. All key-value pairs in the `stringData` field are internally +merged into the `data` field. If a key appears in both the `data` and the +`stringData` field, the value specified in the `stringData` field takes +precedence. + +#### Size limit {#restriction-data-size} + +Individual Secrets are limited to 1MiB in size. This is to discourage creation +of very large Secrets that could exhaust the API server and kubelet memory. +However, creation of many smaller Secrets could also exhaust memory. You can +use a [resource quota](/docs/concepts/policy/resource-quotas/) to limit the +number of Secrets (or other resources) in a namespace. + +### Editing a Secret + +You can edit an existing Secret unless it is [immutable](#secret-immutable). To +edit a Secret, use one of the following methods: + +- [Use `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#edit-secret) +- [Use a configuration file](/docs/tasks/configmap-secret/managing-secret-using-config-file/#edit-secret) + +You can also edit the data in a Secret using the [Kustomize tool](/docs/tasks/configmap-secret/managing-secret-using-kustomize/#edit-secret). However, this +method creates a new `Secret` object with the edited data. + +Depending on how you created the Secret, as well as how the Secret is used in +your Pods, updates to existing `Secret` objects are propagated automatically to +Pods that use the data. For more information, refer to [Using Secrets as files from a Pod](#using-secrets-as-files-from-a-pod) section. + +### Using a Secret + +Secrets can be mounted as data volumes or exposed as +{{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} +to be used by a container in a Pod. Secrets can also be used by other parts of the +system, without being directly exposed to the Pod. For example, Secrets can hold +credentials that other parts of the system should use to interact with external +systems on your behalf. + +Secret volume sources are validated to ensure that the specified object +reference actually points to an object of type Secret. Therefore, a Secret +needs to be created before any Pods that depend on it. + +If the Secret cannot be fetched (perhaps because it does not exist, or +due to a temporary lack of connection to the API server) the kubelet +periodically retries running that Pod. The kubelet also reports an Event +for that Pod, including details of the problem fetching the Secret. + +#### Optional Secrets {#restriction-secret-must-exist} + +When you reference a Secret in a Pod, you can mark the Secret as _optional_, +such as in the following example. If an optional Secret doesn't exist, +Kubernetes ignores it. + +{{% code language="yaml" file="secret/optional-secret.yaml" %}} + +By default, Secrets are required. None of a Pod's containers will start until +all non-optional Secrets are available. + +If a Pod references a specific key in a non-optional Secret and that Secret +does exist, but is missing the named key, the Pod fails during startup. + +### Using Secrets as files from a Pod {#using-secrets-as-files-from-a-pod} + +If you want to access data from a Secret in a Pod, one way to do that is to +have Kubernetes make the value of that Secret be available as a file inside +the filesystem of one or more of the Pod's containers. + +For instructions, refer to +[Distribute credentials securely using Secrets](/docs/tasks/inject-data-application/distribute-credentials-secure/#create-a-pod-that-has-access-to-the-secret-data-through-a-volume). + +When a volume contains data from a Secret, and that Secret is updated, Kubernetes tracks +this and updates the data in the volume, using an eventually-consistent approach. + +{{< note >}} +A container using a Secret as a +[subPath](/docs/concepts/storage/volumes#using-subpath) volume mount does not receive +automated Secret updates. +{{< /note >}} + +The kubelet keeps a cache of the current keys and values for the Secrets that are used in +volumes for pods on that node. +You can configure the way that the kubelet detects changes from the cached values. The +`configMapAndSecretChangeDetectionStrategy` field in the +[kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) controls +which strategy the kubelet uses. The default strategy is `Watch`. + +Updates to Secrets can be either propagated by an API watch mechanism (the default), based on +a cache with a defined time-to-live, or polled from the cluster API server on each kubelet +synchronisation loop. + +As a result, the total delay from the moment when the Secret is updated to the moment +when new keys are projected to the Pod can be as long as the kubelet sync period + cache +propagation delay, where the cache propagation delay depends on the chosen cache type +(following the same order listed in the previous paragraph, these are: +watch propagation delay, the configured cache TTL, or zero for direct polling). + +### Using Secrets as environment variables + +To use a Secret in an {{< glossary_tooltip text="environment variable" term_id="container-env-variables" >}} +in a Pod: + +1. For each container in your Pod specification, add an environment variable + for each Secret key that you want to use to the + `env[].valueFrom.secretKeyRef` field. +1. Modify your image and/or command line so that the program looks for values + in the specified environment variables. + +For instructions, refer to +[Define container environment variables using Secret data](/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data). + +#### Invalid environment variables {#restriction-env-from-invalid} + +If your environment variable definitions in your Pod specification are +considered to be invalid environment variable names, those keys aren't made +available to your container. The Pod is allowed to start. + +Kubernetes adds an Event with the reason set to `InvalidVariableNames` and a +message that lists the skipped invalid keys. The following example shows a Pod that refers to a Secret named `mysecret`, where `mysecret` contains 2 invalid keys: `1badkey` and `2alsobad`. + +```shell +kubectl get events +``` + +The output is similar to: + +``` +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON +0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names. +``` + +### Container image pull Secrets {#using-imagepullsecrets} + +If you want to fetch container images from a private repository, you need a way for +the kubelet on each node to authenticate to that repository. You can configure +_image pull Secrets_ to make this possible. These Secrets are configured at the Pod +level. + +#### Using imagePullSecrets + +The `imagePullSecrets` field is a list of references to Secrets in the same namespace. +You can use an `imagePullSecrets` to pass a Secret that contains a Docker (or other) image registry +password to the kubelet. The kubelet uses this information to pull a private image on behalf of your Pod. +See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +for more information about the `imagePullSecrets` field. + +##### Manually specifying an imagePullSecret + +You can learn how to specify `imagePullSecrets` from the +[container images](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +documentation. + +##### Arranging for imagePullSecrets to be automatically attached + +You can manually create `imagePullSecrets`, and reference these from a ServiceAccount. Any Pods +created with that ServiceAccount or created with that ServiceAccount by default, will get their +`imagePullSecrets` field set to that of the service account. +See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +for a detailed explanation of that process. + +### Using Secrets with static Pods {#restriction-static-pod} + +You cannot use ConfigMaps or Secrets with {{< glossary_tooltip text="static Pods" term_id="static-pod" >}}. + +## Immutable Secrets {#secret-immutable} + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + +Kubernetes lets you mark specific Secrets (and ConfigMaps) as _immutable_. +Preventing changes to the data of an existing Secret has the following benefits: + +- protects you from accidental (or unwanted) updates that could cause applications outages +- (for clusters that extensively use Secrets - at least tens of thousands of unique Secret + to Pod mounts), switching to immutable Secrets improves the performance of your cluster + by significantly reducing load on kube-apiserver. The kubelet does not need to maintain + a [watch] on any Secrets that are marked as immutable. + +### Marking a Secret as immutable {#secret-immutable-create} + +You can create an immutable Secret by setting the `immutable` field to `true`. For example, + +```yaml +apiVersion: v1 +kind: Secret +metadata: ... +data: ... +immutable: true +``` + +You can also update any existing mutable Secret to make it immutable. + +{{< note >}} +Once a Secret or ConfigMap is marked as immutable, it is _not_ possible to revert this change +nor to mutate the contents of the `data` field. You can only delete and recreate the Secret. +Existing Pods maintain a mount point to the deleted Secret - it is recommended to recreate +these pods. +{{< /note >}} + +## Information security for Secrets + +Although ConfigMap and Secret work similarly, Kubernetes applies some additional +protection for Secret objects. + +Secrets often hold values that span a spectrum of importance, many of which can +cause escalations within Kubernetes (e.g. service account tokens) and to +external systems. Even if an individual app can reason about the power of the +Secrets it expects to interact with, other apps within the same namespace can +render those assumptions invalid. + +A Secret is only sent to a node if a Pod on that node requires it. +For mounting Secrets into Pods, the kubelet stores a copy of the data into a `tmpfs` +so that the confidential data is not written to durable storage. +Once the Pod that depends on the Secret is deleted, the kubelet deletes its local copy +of the confidential data from the Secret. + +There may be several containers in a Pod. By default, containers you define +only have access to the default ServiceAccount and its related Secret. +You must explicitly define environment variables or map a volume into a +container in order to provide access to any other Secret. + +There may be Secrets for several Pods on the same node. However, only the +Secrets that a Pod requests are potentially visible within its containers. +Therefore, one Pod does not have access to the Secrets of another Pod. + +### Configure least-privilege access to Secrets + +To enhance the security measures around Secrets, Kubernetes provides a mechanism: you can +annotate a ServiceAccount as `kubernetes.io/enforce-mountable-secrets: "true"`. + +For more information, you can refer to the [documentation about this annotation](/docs/concepts/security/service-accounts/#enforce-mountable-secrets). + +{{< warning >}} +Any containers that run with `privileged: true` on a node can access all +Secrets used on that node. +{{< /warning >}} + +## {{% heading "whatsnext" %}} + +- For guidelines to manage and improve the security of your Secrets, refer to + [Good practices for Kubernetes Secrets](/docs/concepts/security/secrets-good-practices). +- Learn how to [manage Secrets using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Learn how to [manage Secrets using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- Read the [API reference](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) for `Secret` diff --git a/content/uk/docs/concepts/containers/_index.md b/content/uk/docs/concepts/containers/_index.md new file mode 100644 index 0000000000000..e4ce5ec2a9704 --- /dev/null +++ b/content/uk/docs/concepts/containers/_index.md @@ -0,0 +1,37 @@ +--- +title: Контейнери +weight: 40 +description: Технологія для упаковки застосунку разом з його залежностями оточення виконання. +reviewers: +- erictune +- thockin +content_type: concept +card: + name: concepts + weight: 50 +--- + + + +Кожен контейнер, який ви запускаєте, є повторюваним; стандартизація завдяки включеним залежностям означає, що ви отримуєте однакову поведінку, де б ви його не запускали. + +Контейнери відокремлюють застосунки від базової інфраструктури хоста Це полегшує розгортання в різних хмарних або ОС-середовищах. + +Кожен {{< glossary_tooltip text="вузол" term_id="node" >}} в кластері Kubernetes запускає контейнери, які формують +[Podʼи](/docs/concepts/workloads/pods/), призначені цьому вузлу. Контейнери розташовуються та плануються разом, щоб запускатися на тому ж вузлі. + + + +## Образи контейнерів {#container-images} + +[Образ контейнера](/docs/concepts/containers/images/) — це готовий до запуску пакунок програмного забезпечення, який містить все необхідне для запуску застосунку: код та будь-яке середовище виконання, яке він вимагає, бібліотеки застосунку та системи, та типові значення для будь-яких важливих налаштувань. + +Контейнери призначені для того, щоб бути stateless та [незмінними](https://glossary.cncf.io/immutable-infrastructure/): ви не повинні змінювати код контейнера, який вже працює. Якщо у вас є контейнеризований застосунок та ви хочете внести зміни, правильний процес полягає в тому, щоб побудувати новий образ, який включає зміни, а потім перебудувати контейнер, щоб запустити оновлений образ. + +## Середовище виконання контейнерів {#container-runtimes} + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +Зазвичай, ви можете дозволити вашому кластеру обрати стандартне середовище виконання для Podʼу. Якщо вам потрібно використовувати більше одного середовища виконання контейнерів у вашому кластері, ви можете вказати [RuntimeClass](/docs/concepts/containers/runtime-class/) для Podʼу, щоб переконатися, що Kubernetes запускає ці контейнери за допомогою певного середовища виконання. + +Ви також можете використовувати RuntimeClass для запуску різних Podʼів з однаковим контейнером, але з різними налаштуваннями. diff --git a/content/uk/docs/concepts/containers/container-environment.md b/content/uk/docs/concepts/containers/container-environment.md new file mode 100644 index 0000000000000..c127c5086d473 --- /dev/null +++ b/content/uk/docs/concepts/containers/container-environment.md @@ -0,0 +1,49 @@ +--- +reviewers: +- mikedanese +- thockin +title: Середовище контейнера +content_type: concept +weight: 20 +--- + + + +Ця сторінка описує ресурси, доступні контейнерам в середовищі контейнера. + + + + +## Середовище контейнера {#container-environment} + +Середовище контейнера Kubernetes надає кілька важливих ресурсів контейнерам: + +* Файлову систему, яка є комбінацією [образу](/docs/concepts/containers/images/) та одного чи декількох [томів](/docs/concepts/storage/volumes/). +* Інформацію про сам контейнер. +* Інформацію про інші обʼєкти в кластері. + +### Інформація про контейнер {#container-information} + +*hostname* контейнера є імʼям Pod, в якому він працює. Воно доступне через команду `hostname` або виклик функції [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) у бібліотеці libc. + +Імʼя та простір імен Pod доступні як змінні середовища через [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/). + +Змінні середовища, визначені користувачем у визначенні Pod, також доступні для контейнера, так само як будь-які статично визначені змінні середовища в образі контейнера. + +### Інформація про кластер {#cluster-information} + +Список всіх служб, які були активні при створенні контейнера, доступний цьому контейнеру як змінні середовища. Цей список обмежений службами в межах того ж простору імен, що й новий Pod контейнера, та службами керування Kubernetes. + +Для служби з імʼям *foo*, яка повʼязана з контейнером із імʼям *bar*, визначаються наступні змінні: + +```shell +FOO_SERVICE_HOST=<хост, на якому працює служба> +FOO_SERVICE_PORT=<порт, на якому працює служба> +``` + +Служби мають виділені IP-адреси які доступні для контейнера через DNS, якщо увімкнено [надбудову DNS](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/). + +## {{% heading "whatsnext" %}} + +* Дізнайтеся більше про [закріплення обробників за подіями життєвого циклу контейнера](/docs/concepts/containers/container-lifecycle-hooks/). +* Отримайте практичний досвід [прикріплення обробників до подій життєвого циклу контейнера](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). diff --git a/content/uk/docs/concepts/containers/container-lifecycle-hooks.md b/content/uk/docs/concepts/containers/container-lifecycle-hooks.md new file mode 100644 index 0000000000000..2f859b43b80c2 --- /dev/null +++ b/content/uk/docs/concepts/containers/container-lifecycle-hooks.md @@ -0,0 +1,84 @@ +--- +reviewers: +- mikedanese +- thockin +title: Хуки життєвого циклу контейнера +content_type: concept +weight: 40 +--- + + + +На цій сторінці описано, як контейнери, керовані kubelet, можуть використовувати фреймворк хука життєвого циклу контейнера для запуску коду, викликаного подіями під час управління їх життєвим циклом. + + + +## Огляд {#overview} + +Аналогічно багатьом фреймворкам програмування, які мають хуки життєвого циклу компонентів, таким як Angular, Kubernetes надає контейнерам хуки життєвого циклу. Ці хуки дозволяють контейнерам бути в курсі подій у своєму циклі управління та виконувати код, реалізований в обробнику, коли відповідний хук життєвого циклу виконується. + +## Хуки контейнера {#container-hooks} + +До контейнерів виносяться два хуки: + +`PostStart` + +Цей хук виконується негайно після створення контейнера. Однак немає гарантії, що хук виконається до ENTRYPOINT контейнера. До обробника не передаються параметри. + +`PreStop` + +Цей хук викликається негайно перед тим, як контейнер буде завершено через запит API або подію управління, таку як невдача проби на живучість/запуску, передумови, конфлікт ресурсів та інші. Звернення до хука `PreStop` не вдасться, якщо контейнер вже перебуває у стані завершення або виконання, і хук повинен завершити виконання до того, як може бути відправлений сигнал TERM для зупинки контейнера. Відлік пільгового періоду припинення Pod починається до виконання хуку `PreStop`, тому, незалежно від результату обробника, контейнер врешті-решт закінчиться протягом пільгового періоду припинення Pod. Жодні параметри не передаються обробнику. + +Докладний опис поведінки припинення роботи Podʼів можна знайти в [Припинення роботи Podʼа](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). + +### Реалізації обробника хуків {#hook-handler-implementations} + +Контейнери можуть мати доступ до хука, реалізувавши та реєструючи обробник для цього хука. Існують три типи обробників хука, які можна реалізувати для контейнерів: + +* Exec — Виконує конкретну команду, таку як `pre-stop.sh`, всередині cgroups та namespaces контейнера. Ресурси, спожиті командою, зараховуються на рахунок контейнера. +* HTTP — Виконує HTTP-запит до конкретного endpoint в контейнері. +* Sleep — Призупиняє контейнер на вказаний час. Дія "Sleep" доступна, коли [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodLifecycleSleepAction` увімкнено. + +### Виконання обробника хука {#hook-handler-execution} + +Коли викликається хук управління життєвим циклом контейнера, система управління Kubernetes виконує обробник відповідно до дії хука, `httpGet`, `tcpSocket` та `sleep` виконуються процесом kubelet, а `exec` виконується в контейнері. + +Виклики обробників хуків синхронні в межах контексту Pod, який містить контейнер. Це означає, що для хука `PostStart`, ENTRYPOINT контейнера та хук викликаються асинхронно. Однак якщо хук займає занадто багато часу або блокується, контейнер не може досягти стану `running`. + +Хуки `PreStop` не викликаються асинхронно від сигналу зупинки контейнера; хук повинен завершити своє виконання до того, як може бути відправлений сигнал TERM. Якщо хук `PreStop` затримується під час виконання, фаза Pod буде `Terminating`, і залишиться такою, поки Pod не буде вбито після закінчення його `terminationGracePeriodSeconds`. Цей період припинення роботи застосовується до загального часу, необхідного як для виконання хука `PreStop`, так і для зупинки контейнера. Якщо, наприклад, `terminationGracePeriodSeconds` дорівнює 60, і хук займає 55 секунд для завершення, а контейнер зупиняється нормально через 10 секунд після отримання сигналу, то контейнер буде вбитий перш, ніж він зможе завершити роботу, оскільки `terminationGracePeriodSeconds` менше, ніж загальний час (55+10), необхідний для цих двох подій. + +Якщо хук `PostStart` або `PreStop` не вдасться, він вбиває контейнер. + +Користувачам слід робити свої обробники хуків якомога легкими. Проте є випадки, коли довгострокові команди мають сенс, наприклад, коли потрібно зберегти стан перед зупинкою контейнера. + +### Гарантії доставки хуків {#hook-delivery-guarantees} + +Постачання хука призначено бути *принаймні одноразовим*, що означає, що хук може бути викликано кілька разів для будь-якої події, такої як для `PostStart` чи `PreStop`. Це залежить від реалізації хука. + +Як правило, здійснюються лише разові доставки. Якщо, наприклад, приймач HTTP-хука не працює і не може приймати трафік, спроба повторно надіслати не відбувається. Однак у деяких рідкісних випадках може статися подвійна доставка. Наприклад, якщо kubelet перезапускається посеред надсилання хука, хук може бути повторно відправлений після того, як kubelet повернеться. + +### Налагодження обробників хуків {#debugging-hook-handlers} + +Логи обробника хука не відображаються в подіях Pod. Якщо обробник відмовляється з будь-якої причини, він розсилає подію. Для `PostStart` це подія `FailedPostStartHook`, а для `PreStop` це подія `FailedPreStopHook`. Щоб згенерувати подію `FailedPostStartHook`, змініть [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) файл, щоб змінити команду postStart на "badcommand" та застосуйте його. Ось приклад виводу події, який ви побачите після виконання `kubectl describe pod lifecycle-demo`: + +```none +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 7s default-scheduler Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2... + Normal Pulled 6s kubelet Successfully pulled image "nginx" in 229.604315ms + Normal Pulling 4s (x2 over 6s) kubelet Pulling image "nginx" + + + Normal Created 4s (x2 over 5s) kubelet Created container lifecycle-demo-container + Normal Started 4s (x2 over 5s) kubelet Started container lifecycle-demo-container + Warning FailedPostStartHook 4s (x2 over 5s) kubelet Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n" + Normal Killing 4s (x2 over 5s) kubelet FailedPostStartHook + Normal Pulled 4s kubelet Successfully pulled image "nginx" in 215.66395ms + Warning BackOff 2s (x2 over 3s) kubelet Back-off restarting failed container +``` + +## {{% heading "whatsnext" %}} + +* Дізнайтеся більше про [Середовище контейнера](/docs/concepts/containers/container-environment/). +* Отримайте практичний досвід, [прикріплюючи обробників до подій життєвого циклу контейнера](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). diff --git a/content/uk/docs/concepts/containers/images.md b/content/uk/docs/concepts/containers/images.md new file mode 100644 index 0000000000000..6fef146568832 --- /dev/null +++ b/content/uk/docs/concepts/containers/images.md @@ -0,0 +1,346 @@ +--- +reviewers: +- erictune +- thockin +title: Образ контейнера +content_type: Концепція +weight: 10 +hide_summary: true # Окремо вказано у розділі змісту +--- + + + +Образ контейнера представляє бінарні дані, які інкапсулюють застосунок та всі його програмні залежності. Образи контейнерів — це виконувані пакунки програмного забезпечення, які можуть працювати окремо і роблять дуже чітко визначені припущення щодо свого середовища виконання. + +Зазвичай ви створюєте образ контейнера свого застосунку та розміщуєте його в реєстрі +перш ніж посилатися на нього у {{< glossary_tooltip text="Pod" term_id="pod" >}}. + +Ця сторінка надає огляд концепції образів контейнерів. + +{{< note >}} +Якщо ви шукаєте образи контейнерів для випуску Kubernetes (наприклад, v{{< skew latestVersion >}}, остання мінорна версія), відвідайте розділ [Завантаження Kubernetes](https://kubernetes.io/releases/download/). +{{< /note >}} + + + +## Назви образів {#image-names} + +Образам контейнерів зазвичай дається назва, така як `pause`, `example/mycontainer` або `kube-apiserver`. Образ також може містити імʼя хосту реєстру; наприклад: `fictional.registry.example/imagename`, а також, можливо, номер порту; наприклад: `fictional.registry.example:10443/imagename`. + +Якщо ви не вказуєте імʼя хосту реєстру, Kubernetes вважає, що ви маєте на увазі публічний реєстр образів Docker. + +Після частини назви образу ви можете додати _теґ_ (так само, якщо ви використовуєте команди типу `docker` чи `podman`). Теґи дозволяють ідентифікувати різні версії одного ряду образів. + +Теґи образів складаються з малих і великих літер, цифр, підкреслень (`_`), крапок (`.`) та тире (`-`). Є додаткові правила, де можна розмістити роздільники +символів (`_`, `-` та `.`) всередині теґу образу. Якщо ви не вказуєте теґ, Kubernetes вважає, що ви маєте на увазі теґ `latest`. + +## Оновлення образів {#updating-images} + +При першому створенні {{< glossary_tooltip text="Deployment" term_id="deployment" >}}, {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}, Pod чи іншого обʼєкта, що включає шаблон Pod, стандартна політика завантаження всіх +контейнерів у цьому Pod буде встановлена в `IfNotPresent`, якщо вона не вказана явно. Ця політика призводить до того, що {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} пропускає завантаження образів, якщо вони вже існують. + +### Політика завантаження образів {#image-pull-policy} + +`imagePullPolicy` для контейнера та теґ образу впливають на те, коли [kubelet](/docs/reference/command-line-tools-reference/kubelet/) намагається завантажити (стягнути) вказаний образ. + +Ось список значень, які можна встановити для `imagePullPolicy` та їхні ефекти: + +`IfNotPresent` +: образ завантажується лише тоді, коли він ще не присутній локально. + +`Always` +: кожен раз, коли kubelet запускає контейнер, kubelet зверетається до реєстру образів для пошуку відповідності між назвою та образом ([digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)). Якщо у kubelet є образ контейнера з цим точним хешем в кеші локально, kubelet використовує свій кеш образів; в іншому випадку kubelet завантажує образ зі знайденим хешем та використовує його для запуску контейнера. + +`Never` +: kubelet не намагається отримати образ. Якщо образ вже присутній локально, kubelet намагається запустити контейнер; в іншому випадку запуск закінчується невдачею. Див. [попередньо завантажені образи](#pre-pulled-images) для отримання деталей. + +Семантика кешування базового постачальника образів робить навіть `imagePullPolicy: Always` ефективним, якщо реєстр доступний. Ваше середовище виконання контейнерів може помітити, що шари образів вже існують на вузлі, так що їх не потрібно знову завантажувати. + +{{< note >}} +Ви повинні уникати використання теґу `:latest` при розгортанні контейнерів в промисловому оточені, оскільки важко відстежити, яка версія образів запущена, і складніше виконати відкат. + +Замість цього використовуйте інший значущий теґ, такий як `v1.42.0` і/або хеш. +{{< /note >}} + +Щоб переконатися, що Pod завжди використовує ту саму версію образів контейнерів, ви можете вказати хеш образів; замініть `:` на `@` +(наприклад, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). + +При використанні теґів образів, якщо реєстр образів змінив код, який представляє теґ вашого образу, ви могли б отримати суміш Podʼів, що запускають старий і новий код. Дайджест образу унікально ідентифікує конкретну версію образу, тому Kubernetes запускає один і той же код кожного разу, коли він запускає контейнер із вказаним імʼям образу та дайджестом. зазначення образу за допомогою дайджесту виправляє код, який ви запускаєте, так що зміна в реєстрі не може призвести до такого змішаного використання версій. + +Є сторонні [контролери допуску](/docs/reference/access-authn-authz/admission-controllers/) що змінюють Pod (і шаблони pod), коли вони створюються, так що робоче навантаження визначається на основі хешу образу, а не теґу. Це може бути корисно, якщо ви хочете переконатися, що всі ваші робочі навантаження запускають один і той самий код, незалежно від того, які зміни теґів відбуваються в реєстрі. + +#### Стандартні політики завантаження образів {#imagepullpolicy-defaulting} + +Коли ви (чи контролер) подаєте новий Pod серверу API, ваш кластер встановлює поле `imagePullPolicy` при виконанні певних умов: + +- якщо ви опускаєте поле `imagePullPolicy` та вказуєте хеш для образів контейнерів, `imagePullPolicy` автоматично встановлюється в `IfNotPresent`. +- якщо ви опускаєте поле `imagePullPolicy` та теґ для образів контейнерів є `:latest`, `imagePullPolicy` автоматично встановлюється в `Always`; +- якщо ви опускаєте поле `imagePullPolicy` та не вказуєте теґ для образів контейнерів, `imagePullPolicy` автоматично встановлюється в `Always`; +- якщо ви опускаєте поле `imagePullPolicy` та вказуєте теґ для образів контейнерів, який не є `:latest`, `imagePullPolicy` автоматично встановлюється в `IfNotPresent`. + +{{< note >}} +Значення `imagePullPolicy` контейнера завжди встановлюється при першому _створенні_ обʼєкта і не оновлюється, якщо теґ чи хеш образів пізніше зміниться. + +Наприклад, якщо ви створите Deployment з образом, теґ якого _не є_ `:latest`, і пізніше оновите образ цього Deployment до теґу `:latest`, поле `imagePullPolicy` _не_ зміниться на `Always`. Вам слід вручну змінити політику завантаження для будь-якого обʼєкта після його початкового створення. +{{< /note >}} + +#### Обов'язкове завантаження образів {#required-images-pull} + +Якщо ви хочете завжди виконувати завантаження, ви можете зробити одне з наступного: + +- Встановіть `imagePullPolicy` контейнера в `Always`. +- Опустіть `imagePullPolicy` і використовуйте `:latest` як теґ для образів; Kubernetes встановить політику в `Always` при подачі Pod. +- Опустіть `imagePullPolicy` та теґ для використання образів; Kubernetes встановить політику в `Always` при подачі Pod. +- Увімкніть контролер допуску [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages). + +### ImagePullBackOff + +Коли kubelet починає створювати контейнери для Pod за допомогою середовища виконання контейнерів, можливо, контейнер перебуває у стані [Waiting](/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting) з причини `ImagePullBackOff`. + +Статус `ImagePullBackOff` означає, що контейнер не може запуститися через те, що Kubernetes не може завантажити образ контейнера (з причин, таких як невірне імʼя образу або спроба завантаження з приватного реєстру без `imagePullSecret`). Частина `BackOff` вказує на те, що Kubernetes буде продовжувати пробувати завантажити образ зі збільшенням інтервалів між спробами. + +Kubernetes збільшує інтервал між кожною спробою до тих пір, поки не досягне вбудованого обмеження, яке становить 300 секунд (5 хвилин). + +### Завантаження образу відповідно до класу середовища виконання {#image-pull-per-runtime-class} + +{{< feature-state feature_gate_name="RuntimeClassInImageCriApi" >}} +У Kubernetes є альфа-підтримка для виконання завантаження образів на основі класу середовища виконання контейнерів Pod. + +Якщо ви увімкнете [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `RuntimeClassInImageCriApi`, kubelet вказує образи контейнерів кортежем (назва образу, обробник), а не лише назва чи хешем образу. Ваше {{< glossary_tooltip text="середовище виконання контейнерів" term_id="container-runtime" >}} може адаптувати свою поведінку залежно від обраного обробника. Завантаження образів на основі класу середовища виконання буде корисним для контейнерів, що використовують віртуальні машини, таких як контейнери Windows Hyper-V. + +## Послідовне та паралельне завантаження образів {#serial-and-parallel-image-pulls} + +Типово kubelet завантажує образи послідовно. Іншими словами, kubelet надсилає лише один запит на завантаження образу до служби образів одночасно. Інші запити на завантаження образів мають чекати, поки завершиться обробка того, який знаходиться в процесі. + +Вузли приймають рішення про завантаження образу незалежно один від одного. Навіть коли ви використовуєте послідовні запити на завантаження образів, два різні вузли можуть завантажувати один і той самий образ паралельно. + +Якщо ви хочете увімкнути паралельне завантаження образів, ви можете встановити поле `serializeImagePulls` у значення false у [конфігурації kubelet](/docs/reference/config-api/kubelet-config.v1beta1/). Зі значенням `serializeImagePulls` встановленим у false, запити на завантаження образів будуть надсилатись до служби образів негайно, і кілька образів буде завантажено одночасно. + +При увімкненні паралельного завантаження образів, будь ласка, переконайтеся, що служба образів вашого середовища виконання контейнерів може обробляти паралельне завантаження образів. + +Kubelet ніколи не завантажує кілька образів паралельно від імені одного Pod. Наприклад, якщо у вас є Pod із контейнером ініціалізації та контейнером застосунку, завантаження образів для цих двох контейнерів не буде виконуватись паралельно. Однак якщо у вас є два Podʼи, які використовують різні образи, kubelet завантажує образи паралельно для цих двох різних Podʼів, коли увімкнено паралельне завантаження образів. + +### Максимальна кількість паралельних завантажень образів {#maximum-parallel-image-pulls} + +{{< feature-state for_k8s_version="v1.27" state="alpha" >}} + +Коли `serializeImagePulls` встановлено в значення false, kubelet стандартно не обмежує максимальну кількість образів, які завантажуються одночасно. Якщо ви хочете обмежити кількість паралельних завантажень образів, ви можете встановити поле `maxParallelImagePulls` у конфігурації kubelet. Зі значенням `maxParallelImagePulls` в _n_, тільки _n_ образів можуть завантажуватися одночасно, і будь-яке завантаження образу за межами _n_ буде чекати, поки завершиться принаймні одне завантаження образу, яке вже триває. + +Обмеження кількості паралельних завантажень образів допоможе уникнути зайвого використання пропускної здатності мережі або дискових операцій вводу/виводу, коли увімкнено паралельне завантаження образів. + +Ви можете встановити `maxParallelImagePulls` на позитивне число, яке більше або рівне 1. Якщо ви встановите `maxParallelImagePulls` більше або рівне 2, ви повинні встановити `serializeImagePulls` в значення false. Kubelet не буде запущено з недійсними налаштуваннями `maxParallelImagePulls`. + +## Мультиархітектурні образи з індексами образів {#multi-architecture-images-with-image-indexes} + +Окрім надання бінарних образів, реєстр контейнерів також може обслуговувати [індекс образу контейнера](https://github.com/opencontainers/image-spec/blob/master/image-index.md). Індекс образу може посилатися на кілька [маніфестів образу](https://github.com/opencontainers/image-spec/blob/master/manifest.md) для версій контейнера, специфічних для архітектури. Ідея полягає в тому, що ви можете мати імʼя для образу (наприклад: `pause`, `example/mycontainer`, `kube-apiserver`) та дозволити різним системам отримувати правильний бінарний образ для використання на їхній архітектурі машини. + +Сам Kubernetes зазвичай називає образи контейнерів із суфіксом `-$(ARCH)`. З метою забезпечення сумісності з попередніми версіями, будь ласка, генеруйте старіші образи із суфіксами. Ідея полягає в тому, щоб створити, наприклад, образ `pause`, який має маніфест для всіх архітектур, та скажімо `pause-amd64`, який є сумісним з попередніми конфігураціями або файлами YAML, які можуть містити жорстко закодовані образи із суфіксами. + +## Використання приватних реєстрів {#using-a-private-registry} + +Приватні реєстри можуть вимагати ключі для читання образів з них. Облікові дані можна надати кількома способами: + +- Налаштування вузлів для автентифікації в приватному реєстрі + - всі Podʼи можуть читати будь-які налаштовані приватні реєстри + - вимагає конфігурації вузла адміністратором кластера +- Постачальник облікових даних Kubelet для динамічного отримання облікових даних для приватних реєстрів + - kubelet може бути налаштований для використання втулка від постачальника облікових даних для відповідного приватного реєстру. +- Попередньо завантажені образи + - всі Podʼи можуть використовувати будь-які образи, кешовані на вузлі + - вимагає доступу до кореня на всіх вузлах для налаштування +- Вказання ImagePullSecrets на Pod + - лише Podʼи, які надають власні ключі, можуть отримувати доступ до приватного реєстру +- Постачальник специфічний для вендора або локальні розширення + - якщо ви використовуєте власну конфігурацію вузла, ви (або ваш постачальник хмари) можете реалізувати власний механізм автентифікації вузла в реєстрі контейнерів. + +Ці варіанти пояснюються докладніше нижче. + +### Налаштування вузлів для автентифікації в приватному реєстрі {#configuring-nodes-to-authenticate-to-a-private-registry} + +Конкретні інструкції щодо встановлення облікових даних залежать від середовища виконання контейнерів та реєстру, який ви вибрали для використання. Вам слід звертатися до документації щодо вашого рішення для отримання найточнішої інформації. + +Для прикладу конфігурування приватного реєстру образів контейнерів дивіться завдання [Завантаження образу з приватного реєстру](/docs/tasks/configure-pod-container/pull-image-private-registry). У цьому прикладі використовується приватний реєстр в Docker Hub. + +### Постачальник облікових даних Kubelet для витягування автентифікованих образів {#kubelet-credential-provider} + +{{< note >}} +Цей підхід добре підходить, коли kubelet повинен динамічно отримувати облікові дані реєстру. Зазвичай використовується для реєстрів, наданих хмарними провайдерами, де токени автентифікації мають обмежений термін дії. +{{< /note >}} + +Ви можете налаштувати kubelet для виклику бінарного втулка, щоб динамічно отримувати облікові дані реєстру для образу контейнера. Це найнадійніший та універсальний спосіб отримання облікових даних для приватних реєстрів, але також вимагає конфігурації kubelet для його увімкнення. + +Докладніше дивіться [Налаштування постачальника облікових даних образу kubelet](/docs/tasks/administer-cluster/kubelet-credential-provider/). + +### Тлумачення файлу config.json {#config-json} + +Тлумачення `config.json` відрізняється між оригінальною реалізацією Docker та тлумаченням Kubernetes. У Docker ключі `auths` можуть вказувати тільки кореневі URL-адреси, тоді як Kubernetes дозволяє використовувати глобальні URL-адреси, а також шляхи, які відповідають префіксу. Єдиним обмеженням є те, що глобальні шаблони (`*`) повинні включати крапку (`.`) для кожного піддомену. Кількість піддоменів, що мають збіг, повинна дорівнювати кількості глобальних шаблонів (`*.`), наприклад: + +- `*.kubernetes.io` _не_ збігатиметься з `kubernetes.io`, але збігатиметься з `abc.kubernetes.io` +- `*.*.kubernetes.io` _не_ збігатиметься з `abc.kubernetes.io`, але збігатиметься з `abc.def.kubernetes.io` +- `prefix.*.io` збігатиметься з `prefix.kubernetes.io` +- `*-good.kubernetes.io` збігатиметься з `prefix-good.kubernetes.io` + +Це означає, що файл `config.json`, подібний до цього, є дійсним: + +```json +{ + "auths": { + "my-registry.io/images": { "auth": "…" }, + "*.my-registry.io/images": { "auth": "…" } + } +} +``` + +Операції отримання образів тепер будуть передавати облікові дані CRI контейнеру для кожного дійсного шаблону. Наприклад, образи контейнера, +вказані нижче, успішно збігатимуться: + +- `my-registry.io/images` +- `my-registry.io/images/my-image` +- `my-registry.io/images/another-image` +- `sub.my-registry.io/images/my-image` + +Але не: + +- `a.sub.my-registry.io/images/my-image` +- `a.b.sub.my-registry.io/images/my-image` + +Kubelet виконує операції отримання образів послідовно для кожного знайденого облікового запису. Це означає, що можливі кілька записів у `config.json` для різних шляхів: + +```json +{ + "auths": { + "my-registry.io/images": { + "auth": "…" + }, + "my-registry.io/images/subpath": { + "auth": "…" + } + } +} +``` + +Тепер, якщо контейнер вказує образ `my-registry.io/images/subpath/my-image`, +то kubelet спробує завантажити його з обох джерел автентифікації, якщо завантеження з одного з них виявиться невдалим. + +### Попередньо завантажені образи {#pre-pulled-images} + +{{< note >}} +Цей підхід підходить, якщо ви можете контролювати конфігурацію вузла. Він не буде надійно працювати, якщо ваш постачальник хмари управляє вузлами та автоматично їх замінює. +{{< /note >}} + +Типово kubelet намагається отримати кожен образ з вказаного реєстру. Однак якщо властивість `imagePullPolicy` контейнера встановлена на `IfNotPresent` або `Never`, +то використовується локальний образ (переважно або виключно, відповідно). + +Якщо ви хочете покладатися на попередньо завантажені образи як заміну автентифікації в реєстрі, вам слід переконатися, що всі вузли кластера мають однакові попередньо завантажені образи. + +Це може бути використано для попереднього завантаження певних образів для швидкості або як альтернатива автентифікації в приватному реєстрі. + +Всі Podʼи матимуть доступ на читання до будь-яких попередньо завантажених образів. + +### Вказання ImagePullSecrets для Pod {#specifying-imagepullsecrets-on-a-pod} + +{{< note >}} +Це рекомендований підхід для запуску контейнерів на основі образів з приватних реєстрів. +{{< /note >}} + +Kubernetes підтримує вказання ключів реєстру образів контейнерів для Pod. `imagePullSecrets` повинні бути всі в тому ж просторі імен, що й Pod. Зазначені Secrets повинні бути типу `kubernetes.io/dockercfg` або `kubernetes.io/dockerconfigjson`. + +#### Створення Secret з Docker-конфігом {#creating-a-secret-with-a-docker-config} + +Вам потрібно знати імʼя користувача, пароль реєстру та адресу електронної пошти клієнта для автентифікації в реєстрі, а також його імʼя хосту. Виконайте наступну команду, підставивши відповідні значення замість написів у верхньому регістрі: + +```shell +kubectl create secret docker-registry \ + --docker-server=DOCKER_REGISTRY_SERVER \ + --docker-username=DOCKER_USER \ + --docker-password=DOCKER_PASSWORD \ + --docker-email=DOCKER_EMAIL +``` + +Якщо у вас вже є файл облікових даних Docker, ніж використовувати вищезазначену +команду, ви можете імпортувати файл облікових даних як Secrets Kubernetes. [Створення Secret на основі наявних облікових даних Docker](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) пояснює, як це зробити. + +Це особливо корисно, якщо ви використовуєте кілька приватних реєстрів контейнерів, оскільки `kubectl create secret docker-registry` створює Secret, який працює лише з одним приватним реєстром. + +{{< note >}} +Podʼи можуть посилатися лише на ключі реєстру образів у своєму власному просторі імен, так що цей процес слід виконати один раз для кожного простору імен. +{{< /note >}} + +#### Посилання на imagePullSecrets для Pod {#referring-to-imagepullsecrets-on-a-pod} + +Тепер ви можете створювати Podʼи, які посилаються на цей secret, додавши розділ `imagePullSecrets` до визначення Pod. Кожен елемент у масиві `imagePullSecrets` може посилатися тільки на Secret у тому ж просторі імен. + +Наприклад: + +```shell +cat < pod.yaml +apiVersion: v1 +kind: Pod +metadata: + name: foo + namespace: awesomeapps +spec: + containers: + - name: foo + image: janedoe/awesomeapp:v1 + imagePullSecrets: + - name: myregistrykey +EOF + +cat <> ./kustomization.yaml +resources: +- pod.yaml +EOF +``` + +Це слід робити для кожного Podʼу, який використовує приватний реєстр. + +Однак налаштування цього поля можна автоматизувати, встановивши imagePullSecrets в [ресурс ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/). + +Перевірте [Додавання ImagePullSecrets до облікового запису служби](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) для докладних інструкцій. + +Ви можете використовувати це разом із `.docker/config.json` на рівні вузла. Облікові дані обʼєднанні. + +## Сценарії використання {#use-cases} + +Існує кілька рішень для конфігурації приватних реєстрів. Ось деякі типові сценарії використання та рекомендовані рішення. + +1. Кластер, в якому використовуються лише непроприєтарні (наприклад, відкриті) образи. Немає потреби приховувати образи. + - Використовуйте відкриті образи з відкритого реєстру. + - Конфігурація не потрібна. + - Деякі постачальники хмари автоматично кешують або дзеркалюють відкриті образи, що підвищує доступність та скорочує час їх отримання. +2. Кластер, в якому використовуються деякі проприєтарні образи, які повинні бути невидимими для інших компаній, але доступними для всіх користувачів кластера. + - Використовуйте приватний реєстр. + - Можлива ручна конфігурація на вузлах, які повинні мати доступ до приватного реєстру. + - Або запустіть внутрішній приватний реєстр за вашим фаєрволом з відкритим доступом на читання. + - Не потрібна конфігурація Kubernetes. + - Використовуйте сервіс реєстрації образів контейнерів, який контролює доступ до образів. + - Він працюватиме краще з автомасштабуванням кластера, ніж ручна конфігурація вузла. + - Або на кластері, де зміна конфігурації вузла незручна, використовуйте `imagePullSecrets`. +3. Кластер із проприєтарними образами, кілька з яких вимагають строгого контролю доступу. + - Переконайтеся, що [контролер доступу AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) активний. У противному випадку всі Podʼи потенційно мають доступ до всіх образів. + - Перемістіть конфіденційні дані в ресурс "Secret", а не додавайте їх в образ. +4. Багатокористувацький кластер, де кожен орендар потребує власного приватного реєстру. + - Переконайтеся, що [контролер доступу AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) активний. У противному випадку всі Podʼи всіх орендарів потенційно мають доступ до всіх образів. + - Запустіть приватний реєстр з обовʼязковою авторизацією. + - Створіть обліковий запис реєстру для кожного орендара, розмістіть його в Secret та внесіть Secret в кожний простір імен орендаря. + - Орендар додає цей Secret до imagePullSecrets кожного простору імен. + +Якщо вам потрібен доступ до декількох реєстрів, ви можете створити Secret для кожного реєстру. + +## Застарілий вбудований постачальник облікових даних kubelet + +У старших версіях Kubernetes kubelet мав пряму інтеграцію з обліковими даними хмарного постачальника. Це давало йому можливість динамічно отримувати облікові дані для реєстрів образів. + +Існувало три вбудовані реалізації інтеграції облікових записів kubelet: ACR (Azure Container Registry), ECR (Elastic Container Registry) та GCR (Google Container Registry). + +Докладніше про застарілий механізм можна прочитати в документації версії Kubernetes, яку ви використовуєте. У версіях Kubernetes від v1.26 до v{{< skew latestVersion >}} він відсутній, тому вам потрібно або: + +- налаштувати постачальника облікових записів kubelet на кожному вузлі +- вказати облікові дані для отримання образів, використовуючи `imagePullSecrets` та принаймні один Secret + +## {{% heading "whatsnext" %}} + +- Прочитайте [Специфікацію маніфеста образу OCI](https://github.com/opencontainers/image-spec/blob/master/manifest.md). +- Дізнайтеся про [збирання сміття образів контейнерів](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection). +- Дізнайтеся більше про [отримання образу з приватного реєстру](/docs/tasks/configure-pod-container/pull-image-private-registry). diff --git a/content/uk/docs/concepts/containers/runtime-class.md b/content/uk/docs/concepts/containers/runtime-class.md new file mode 100644 index 0000000000000..d002321196ca4 --- /dev/null +++ b/content/uk/docs/concepts/containers/runtime-class.md @@ -0,0 +1,136 @@ +--- +reviewers: + - tallclair + - dchen1107 +title: Клас виконання +content_type: concept +weight: 30 +hide_summary: true # Listed separately in section index +--- + + + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +Ця сторінка описує ресурс RuntimeClass та механізм вибору середовища виконання. + +RuntimeClass — це функція для вибору конфігурації середовища виконання контейнерів. Конфігурація середовища виконання контейнерів використовується для запуску контейнерів у Pod. + + + +## Мотивація {#motivation} + +Ви можете встановити різне значення RuntimeClass для різних Pod, щоб забезпечити баланс між продуктивністю та безпекою. Наприклад, якщо частина вашого завдання вимагає високого рівня підтвердження захищеності інформації, ви можете вибрати планування цих Pod так, щоб вони працювали в середовищі виконання контейнерів, яке використовує апаратну віртуалізацію. Таким чином ви скористаєтеся додатковою ізоляцією альтернативного середовища коштом деякого додаткового навантаження. + +Ви також можете використовувати RuntimeClass для запуску різних Pod з однаковим середовищем виконання, але з різними налаштуваннями. + +## Налаштування {#setup} + +1. Налаштуйте впровадження CRI на вузлах (залежить від середовища виконання). +2. Створіть відповідні ресурси RuntimeClass. + +### 1. Налаштуйте впровадження CRI на вузлах {#1-configure-the-cri-implementation-on-nodes} + +Конфігурації, доступні через RuntimeClass, залежать від конкретної реалізації інтерфейсу контейнера (CRI). Для отримання інструкцій щодо налаштування перегляньте відповідну документацію ([нижче](#cri-configuration)) для вашої реалізації CRI. + +{{< note >}} +Стандартно RuntimeClass передбачає однорідну конфігурацію вузла в усьому кластері (що означає, що всі вузли налаштовані однаковим чином щодо контейнерних середовищ). Щоб підтримувати різнорідні конфігурації вузлів, див. [Планування](#scheduling) нижче. +{{< /note >}} + +Кожна конфігурація має відповідний `handler`, на який посилається RuntimeClass. Handler повинен бути дійсним [імʼям DNS-мітки](/docs/concepts/overview/working-with-objects/names/#dns-label-names). + +### 2. Створіть відповідні ресурси RuntimeClass {#2-create-the-corresponding-runtimeclass-resources} + +Кожна конфігурація, налаштована на кроці 1, повинна мати асоційованій `handler`, який ідентифікує конфігурацію. Для кожного handler створіть обʼєкт RuntimeClass. + +Ресурс RuntimeClass наразі має всього 2 значущі поля: імʼя RuntimeClass (`metadata.name`) та handler (`handler`). Визначення обʼєкта виглядає наступним чином: + +```yaml +# RuntimeClass визначений у групі API node.k8s.io +apiVersion: node.k8s.io/v1 +kind: RuntimeClass +metadata: + # Ім'я, за яким буде викликано RuntimeClass. + # RuntimeClass - ресурс без простору імен. + name: myclass +# Ім'я відповідної конфігурації CRI +handler: myconfiguration +``` + +Імʼя обʼєкта RuntimeClass повинно бути дійсним [імʼям DNS-піддомену](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +{{< note >}} +Рекомендується обмежити операції запису RuntimeClass (create/update/patch/delete), щоб вони були доступні тільки адміністраторам кластера. Це, як правило, типове значення. Докладніше див. [Огляд авторизації](/docs/reference/access-authn-authz/authorization/). +{{< /note >}} + +## Використання {#usage} + +Після налаштування RuntimeClass для кластера, ви можете вказати `runtimeClassName` в специфікації Pod, щоб використовувати його. Наприклад: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + runtimeClassName: myclass + # ... +``` + +Це доручить kubelet використовувати названий RuntimeClass для запуску цього Podʼу. Якщо зазначений RuntimeClass не існує або CRI не може виконати відповідний handler, Pod увійде в термінальну [фазу](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed`. Шукайте відповідну [подію](/docs/tasks/debug/debug-application/debug-running-pod/) для отримання повідомлення про помилку. + +Якщо `runtimeClassName` не вказано, буде використовуватися стандартний обробник, що еквівалентно поведінці при вимкненні функції RuntimeClass. + +### Конфігурація CRI {#cri-configuration} + +Докладніше про налаштування CRI див. в [Інсталяції CRI](/docs/setup/production-environment/container-runtimes/). + +#### {{< glossary_tooltip term_id="containerd" >}} + +Обробники Runtime налаштовуються через конфігурацію containerd за шляхом +`/etc/containerd/config.toml`. Дійсні обробники налаштовуються в розділі runtimes: + +``` +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] +``` + +Докладніше див. у [документації з конфігурації](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) containerd: + +#### {{< glossary_tooltip term_id="cri-o" >}} + +Обробники Runtime налаштовуються через конфігурацію CRI-O за шляхом `/etc/crio/crio.conf`. Дійсні обробники налаштовуються в таблиці [crio.runtime](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table): + +``` +[crio.runtime.runtimes.${HANDLER_NAME}] + runtime_path = "${PATH_TO_BINARY}" +``` + +Докладніше див. у [документації з конфігурації](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md) CRI-O. + +## Планування {#scheduling} + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +Зазначаючи поле `scheduling` для RuntimeClass, ви можете встановити обмеження, щоб +забезпечити, що Podʼи, які працюють із цим RuntimeClass, плануються на вузли, які його підтримують. Якщо `scheduling` не встановлено, припускається, що цей RuntimeClass підтримується всіма вузлами. + +Щоб гарантувати, що Podʼи потрапляють на вузли, які підтримують конкретний RuntimeClass, цей набір вузлів повинен мати спільні мітки, які потім обираються полем `runtimeclass.scheduling.nodeSelector`. NodeSelector RuntimeClass обʼєднується з nodeSelector Pod під час допуску, фактично беручи перетин множини вузлів, обраних кожним. + +Якщо підтримувані вузли позначені, щоб завадити запуску інших Podʼів з іншим RuntimeClass на вузлі, ви можете додати `tolerations` до RuntimeClass. Як із `nodeSelector`, tolerations обʼєднуються з tolerations Pod у доступі, фактично беручи об'єднання множини вузлів, які влаштовують всіх. + +Щоб дізнатися більше про налаштування селектора вузла і tolerations, див. [Призначення Podʼів вузлам](/docs/concepts/scheduling-eviction/assign-pod-node/). + +### Надмірність Pod {#pod-overhead} + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Ви можете вказати ресурси _overhead_, що повʼязані із запуском Pod. Вказівка надмірності дозволяє кластеру (включаючи планувальник) враховувати це при прийнятті рішень про Podʼи та ресурси. + +Надмірність Podʼа визначається через поле `overhead` в RuntimeClass. За допомогою цього поля ви можете вказати надмірність запуску Podʼів, що використовують цей RuntimeClass, та забезпечити облік цих надмірностей в Kubernetes. + +## {{% heading "whatsnext" %}} + +- [Дизайн RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) +- [Дизайн планування RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) +- Читайте про концепцію [Надмірності Pod](/docs/concepts/scheduling-eviction/pod-overhead/) +- [Дизайн функції PodOverhead](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) diff --git a/content/uk/docs/concepts/extend-kubernetes/_index.md b/content/uk/docs/concepts/extend-kubernetes/_index.md new file mode 100644 index 0000000000000..3a8f8be44cb67 --- /dev/null +++ b/content/uk/docs/concepts/extend-kubernetes/_index.md @@ -0,0 +1,207 @@ +--- +title: Розширення можливостей Kubernetes +weight: 999 # this section should come last +description: Різні способи зміни поведінки вашого кластера Kubernetes. +reviewers: +- erictune +- lavalamp +- cheftako +- chenopis +feature: + title: Створенно щоб розширюватись + description: > + Додавайте можливості до свого кластеру Kubernetes без зміни сирців. +content_type: concept +no_list: true +--- + + + +Kubernetes добре налаштовується та розширюється. Тому випадки, коли вам потрібно робити форки та накладати патчі на Kubernetes, щоб змінити його поведінку, дуже рідкісні. + +Цей розділ описує різні способи зміни поведінки вашого кластера Kubernetes. Він призначений для {{< glossary_tooltip text="операторів" term_id="cluster-operator" >}}, які хочуть зрозуміти, як адаптувати кластер до своїх потреб свого робочого оточення. Розробники, які є потенційними {{< glossary_tooltip text="розробниками платформ" term_id="platform-developer" >}} чи {{< glossary_tooltip text="учасники" term_id="contributor" >}} проєкту Kubernetes, також знайдуть цей розділ корисним як вступ до того, які точки та шаблони розширення існують, а також їх компроміси та обмеження. + +Підходи до налаштувань можна взагалі розділити на [конфігурацію](#configuration), яка включає лише зміну аргументів командного рядка, локальних конфігураційних файлів або ресурсів API; та [розширення](#extensions), яке передбачає виконання додаткових програм, додаткових мережевих служб або обох. Цей документ в основному присвячений _розширенням_. + + + +## Конфігурація {#configuration} + +*Конфігураційні файли* та _аргументи командного рядка_ описані в розділі [Довідник](/docs/reference/) онлайн-документації, де кожен файл має свою сторінку: + +* [`kube-apiserver`](/docs/reference/command-line-tools-reference/kube-apiserver/) +* [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [`kube-scheduler`](/docs/reference/command-line-tools-reference/kube-scheduler/) +* [`kubelet`](/docs/reference/command-line-tools-reference/kubelet/) +* [`kube-proxy`](/docs/reference/command-line-tools-reference/kube-proxy/) + +Аргументи команд та файли конфігурації не завжди можуть бути змінені в службі Kubernetes, що надається постачальником, або дистрибутиві з керованою установкою. Коли їх можна змінювати, вони, як правило, змінюються лише оператором кластера. Крім того, вони можуть бути змінені в майбутніх версіях Kubernetes, і для їх налаштування може знадобитися перезапуск процесів. З цих причин їх слід використовувати лише тоді, коли немає інших варіантів. + +Вбудовані _API політики_, такі як [ResourceQuota](/docs/concepts/policy/resource-quotas/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) та доступ на основі ролей ([RBAC](/docs/reference/access-authn-authz/rbac/)), є вбудованими API Kubernetes, які надають можливості декларативного налаштування політик. API є доступними та в кластерах, які надаються провайдером, і в кластерах, якими ви керуєте самостійно. Вбудовані API політик використовують ті ж самі конвенції, що й інші ресурси Kubernetes, такі як Podʼи. Коли ви використовуєте [стабільний](/docs/reference/using-api/#api-versioning) API політик, ви отримуєте зиск від [визначеної підтримки політик](/docs/reference/using-api/deprecation-policy/) так само як й інші API Kubernetes. З цих причин використання API політик рекомендується на перевагу до _конфігураційних файлів_ та _аргументів командного рядка_, де це можливо. + +## Розширення {#extensions} + +Розширення — це компонент програмного забезпечення, який глибоко інтегрується з Kubernetes. Вони використовуються для додавання нових типів ресурсів та видів апаратного забезпечення. + +Багато адміністраторів класів Kubernetes використовують кластери, що надаються провайдерами, чи встановленими з дистрибутивів. Ці кластери вже йдуть з розширеннями. В результаті, більшість користувачів Kubernetes не потребують встановлення розширень та дуже невелика частка потребує їх створення. + +## Шаблони розширень {#extension-patterns} + +Kubernetes спроєктовано так, щоб він був автоматизований шляхом створення клієнтських застосунків. Будь-яка програма, яка може писати та читати з API Kubernetes, може надавати корисні функції автоматизації. Ці функції можуть працювати як всередині кластера, так і ззовні. Слідуючи настановам з цього посібника, ви зможете створити надійні та високопродуктивні розширення. Автоматизація, як правило, працює з будь-яким кластером Kubernetes, незалежно від того, як він був встановлений. + +Існує конкретний патерн написання клієнтських програм, які ефективно взаємодіють із Kubernetes, відомий як {{< glossary_tooltip term_id="controller" text="патерн контролера" >}}. Зазвичай контролери читають `.spec` обʼєкта, можливо виконують певні операції, а потім оновлюють `.status` обʼєкта. + +Контролери є клієнтами API Kubernetes. Коли Kubernetes сам є клієнтом та звертається до віддаленого сервісу, виклики Kubernetes є *вебхуками*. Віддалений сервіс називається *вебхук-бекендом*. Так само як і стороні контролери, вебхуки додають ще одну точку вразливості. + +{{< note >}} +Поза Kubernetes, термін «вебхук» зазвичай означає механізм асинхронного сповіщення, де вебхук звертається до сервісу з одностороннім сповіщенням до іншої системи чи компонента. В екосистемі Kubernetes, навіть асинхронний HTTP-запит часто описується як «вебхук». +{{< /note >}} + +В моделі вебхуків, Kubernetes надсилає мережеві запити до віддалених сервісів. Альтернативою є модель *бінарних втулків*, коли Kubernetes виконує бінарник (застосунок). Бінарні втулки використовуються в kublet (наприклад, [втулок зберігання CSI](https://kubernetes-csi.github.io/docs/) та [втулок мережі CNI](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)), а також в kubeсtl (дивітьс [розширення kubectl за допомогою втулків](/docs/tasks/extend-kubectl/kubectl-plugins/)). + +### Точки розширення {#extension-points} + +На цій діаграмі показано точки розширення в кластері Kubernetes та клієнти з доступом до них. + + + +{{< figure src="/docs/concepts/extend-kubernetes/extension-points.png" alt="Символічне представлення семи пронумерованих точок розширення для Kubernetes." class="diagram-large" caption="Точки розширення Kubernetes" >}} + +#### Пояснення до діаграми {#key-to-the-figure} + +1. Користувачі часто взаємодіють з API Kubernetes через `kubectl`. [Втулки](#clent-extensions) підлаштовують поведінку клієнтів. Існують загальні розширення, які можна використовувати з будь-якими клієнтами, так само як і специфічні розширення для `kubectl`. + +1. API сервер обробляє запити. Різні типи точок розширення на сервері API дозволяють автентифікувати запити або блокувати їх на основі їх вмісту, редагувати вміст та обробляти видалення. Про це в розділі [розширення API доступу](#api-access-extensions). + +1. API сервер також обслуговує різні типи ресурсів. *Вбудовані типи ресурсі*, такі як `Pod`, визначені проєктом Kubernetes та не можуть бути змінені. Дивіться [розширення API](#api-extensions) щоб дізнатися про можливості розширення API. + +2. Планувальник [вирішує](/docs/concepts/scheduling-eviction/assign-pod-node/) на якому вузлі запустити кожний Pod. Існує кілька способів розширити планування, про це в розділі [розширення планувальника](#scheduler-extensions). + +3. Більшість варіантів поведінки Kubernetes реалізовано через {{< glossary_tooltip term_id="controller" text="контролери" >}}, які є клієнтами API сервера. Контролери часто використовуються разом з нестандартними ресурсами. Дивіться [поєднання нових API з автоматизаціями](#combining-new-apis-with-automation) та [зміна вбудованих ресурсів](#changing-built-in-resources), щоб дізнатися більше. + +4. Kublet виконує контейнери на вузлах, та допомагає Podʼами виглядати як вірутальні сервери з їх власними IP в мережі кластера. [Мережеві втулки](#network-plugins) дозволяють реалізувати різні мережеві моделі. + +5. Ви можете використовувати [втулки пристроїв](#device-plugins) для використання спеціалізованих пристроїв або інших розташованих на вузлах ресурсів, та робити їх доступними для Podʼів у вашому кластері. Kublent містить підтримку для роботи з втулками пристроїв. + + Kublet також монтує {{< glossary_tooltip term_id="volume" text="томи" >}} для Podʼів та їх контейнерів. [Втулки зберігання](#storage-plugins) дозволяють реалізувати різні моделі зберігання. + +#### Вибір точки розширення {#extension-flowchart} + +Якщо ви вагаєтесь звідки розпочати, ця діаграма може допомогти вам. Зауважте, що деякі рішення можуть включати кілька типів розширень. + + + +{{< figure src="/docs/concepts/extend-kubernetes/flowchart.svg" alt="Flowchart with questions about use cases and guidance for implementers. Green circles indicate yes; red circles indicate no." class="diagram-large" caption="Діаграма-посібник для вибору методу розширення." >}} + +--- + +## Розширення клієнта {#clent-extensions} + +Втулки до `kubectl` дозволяють є окремими програмами, які можуть додавати чи замінувати поведінку певних команд. `kubectl` може інтегруватись з [втулком облікових даних](/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins). Ці розширення впливають лише на локальне оточення користувача і не можуть додавати нові політики до кластера. + +Якщо ви бажаєте розширити `kubectl`, ознаиомтесь з [розширення kubectl за допомогою втулків](/docs/tasks/extend-kubectl/kubectl-plugins/). + +## Розширення API {#api-extensions} + +### Визначення власних ресурсів {#custom-resource-definitions} + +Зважте на додавання _власних ресурсів_ у Kubernetes, якщо ви бажаєте визначити нові контролери, обʼєкти налаштування застосунків або інші декларативні API, та керувати ними використовуючи інструменти подібні до `kubectl`. + +Докладніше про Custom Resource дивіться в [розділі Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). + +### Шар агрегації API {#api-aggregation-layer} + +Ви можете використовувати [шар агрегації API](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) Kubernetes, щоб додати нові ресурси до API Kubernetes разом з додатковими службами, такими як [метрики](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/). + +### Поєднання нових API з автоматизаціями {#combining-new-apis-with-automation} + +Поєднання API власних ресурсів та циклів управління називається шаблонами {{< glossary_tooltip term_id="controller" text="контролерів" >}}. Якщо ваш контролер виконує функції оператора-людини, та розгортає інфраструктуру на основі бажаного стану, то, можливо, він також дотримується {{< glossary_tooltip term_id="operator-pattern" text="шаблону оператора" >}}. Шаблон Оператор використовується для управління конкретними застосунками; зазвичай це застосунки, які підтримують стан та вимагають уважного управління. + +Ви також можете створювати власні API та цикли управління, які керують іншими ресурсами, такими як сховище, або визначають політики (наприклад, обмеження контролю доступу). + +### Зміна вбудованих ресурсів {#changing-built-in-resources} + +Коли ви розширюєте API Kubernetes шляхом додавання власних ресурсів, ці ресурси завжди потрапляють до нової групи API. Ви не можете замінити чи змінити наявні групи API. Додавання API напряму не впливає на поведінку наявних API (таких як Podʼи), однак мають вплив на розширення API доступу. + +## Розширення API доступу {#api-access-extensions} + +Коли запит потрапляє до API сервера Kubernetes, він спочатку _автентифікується_, потім _авторизується_, і потім він потрапляє до _перевірки допуску (admission control)_ (по факту деякі запити є неавтентифікованими та отримують особливу обробку). Дивіться розділ про [керування доступу до API Kubernetes](/docs/concepts/security/controlling-access/) для отримання деталей. + +Кожен крок в процесі автентифікації/авторизації пропонує точки розширення. + +### Автентифікація {#authentication} + +[Автентифікація](/docs/reference/access-authn-authz/authentication/) зіставляє заголовки або сертифікати усіх запитів з користувачами, які зробили запит. + +Kubernetes має кілька вбудованих методів автентифікації. Крім того, він може знаходитись поза проксі-сервером автентифікації та може надсилати токени з заголовком `Authorization` до інших віддалених служб для перевірки ([вебхуки автентифікації](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)), якщо вбудовані методи не підходять. + +### Авторизація {#authorization} + +[Авторизація](/docs/reference/access-authn-authz/authorization/) визначає, чи має користувач право читати, писати чи виконувати інші дії з ресурсами API. Це відбувається на рівні всього ресурсу, а не на рівні окремих обʼєктів. + +Якщо вбудовані методи авторизації не підходять, Kubernetes може використовувати [вебхуки авторизації](/docs/reference/access-authn-authz/webhook/), що дозволяють викликати власний код для визначення, чи має користувач право виконувати дію. + +### Динамічний контроль допуску {#dynamic-admission-control} + +Після того, як запит пройшов та авторизацію, і якщо це операція запису, він також проходить через крок [контролю допуску](/docs/reference/access-authn-authz/admission-controllers/). На додачу до вбудованих кроків, є кілька розширень: + +* [Вебхуки політик образів](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) дозволяють визначити, які образи можуть бути запущені в контейнерах. +* Для прийняття довільних рішень щодо допуску можуть використовуватись загальні [вебхуки допуску](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). Деякі з вебхуків допуску змінюють дані вхідних запитів до того, як вони будуть опрацьовані Kubernetes. + +## Розширення інфраструктури {#infrastructure-extensions} + +### Втулки пристроїв {#device-plugins} + +_Втулки пристроїв_ дозволяють вузлам знаходити нові ресурси Node (на додачу до вбудованих, таких як ЦП та памʼять) за допомогою [Втулків пристроїв](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). + +### Втулки зберігання {#storage-plugins} + +Втулок {{< glossary_tooltip term_id="csi" text="Container Storage Interface" >}} (CSI) надає спосіб розширювати Kubernetes шляхом підтримки нових типів сховищ. Томи можуть знаходитись в надійних зовнішніх системах зберігання, або впроваджувати ефемерні пристрої зберігання, або можуть надавити read-only інтерфейс до інформації використовуючи парадигму роботи з файловою системою. + +Kubernetes має підтримку втулків [FlexVolume](/docs/concepts/storage/volumes/#flexvolume), які вже визнані застаріилими у v1.23 (на користь CSI). + +FlexVolume дозволяв користувачам монтувати типи томів які не підтримувались самим Kubernetes. Коли ви запускали Pod, що вимагав FlexVolume, kublet викликав відповідний FlexVolume драйвер, який виконував монтування томів. Архівована пропозиція з проєктування [FlexVolume](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md) містить більше докладної інформації про те, як все мало відбуватись. + +[ЧаПи про втулки роботи з томами в Kubernetes для постачальників рішень](https://github.com/kubernetes/community/blob/master/sig-storage/volume_plugins-faq.md#kubernetes-volume-plugins-faq-for-storage-vendors) містить загальні відомості про втулки роботи з томами в Kubernetes. + +### Мережеві втулки {#network-plugins} + +Ваш кластер Kubernetes потребує _мережеві втулки_ для того, щоб мати робочу мережу для ваших Podʼів та підтримки аспектів мережевої моделі Kubernetes. + +[Мережеві втулки](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) дозволяють Kubernetes працювати з різними мережевими топологіями та технологіями. + +### Втулки kublet image credential provider {#kublet-image-credential-provider-plugins} + +{{< feature-state for_k8s_version="1.26" state="stable" >}} + +Втулки kublet image credential provider дозволяють динамічно отримувати облікові дані для образів контейнерів з різних джерел. Облікові дані можуть бути використані для отримання образів контейнерів, які відповідають поточній конфігурації. + +Втулки можуть спілкуватись з зовнішніми службами чи використовувати локальні файли для отримання облікових даних. В такому разу kublet не треба мати статичні облікові дані для кожного реєстру, і він може підтримувати різноманітні методи та протоколи автентифікації. + +Щоб дізнатись про параметри налаштування втулка дивіться [налаштування kubelet image credential provider](/docs/tasks/administer-cluster/kubelet-image-credential-provider/). + +## Розширення планувальника {#scheduling-extensions} + +Планувальник є спеціальним типом контролера, який вирішує, на якому вузлі запустити який Pod. Стандартний планувальник можна повністю замінити, продовжуючи використовувати інші компоненти Kubernetes, або ж [кілька планувальників](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) можуть працювати разом. + +Це значне завдання, і майже всі користувачі Kubernetes вважають, що їм не потрібно змінювати планувальник. + +Ви можете контролювати активність [втулків планувальника](/docs/reference/scheduling/config/#scheduling-plugins) або асоціювати набори втулків з різними іменованими [профілями планування](/docs/reference/scheduling/config/#multiple-profiles). Ви також можете створювати свої власні втулки, які інтегруються з однією або кількома [точками розширення](/docs/concepts/scheduling-eviction/scheduling-framework/#extension-points) kube-scheduler. + +Зрештою, вбудований компонент `kube-scheduler` підтримує [вебхуки](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md), що дозволяє віддаленому HTTP-бекенду (розширенню планувальника) фільтрувати та/або пріоритизувати вузли, які kube-scheduler обирає для Podʼів. + +{{< note >}} +Ви можете впливати лише на фільтрування вузлів та їх пріоритизацію за допомогою вебхуків розширювача планувальника; інші точки розширення через інтеграцію вебхука не доступні. +{{< /note >}} + +## {{% heading "whatsnext" %}} + +* Дізнайтеся більше про розширення інфраструктури + * [Втулки пристроїв](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) + * [Мережеві втулки](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [Втулки зберігання](https://kubernetes-csi.github.io/docs/) CSI +* Дізнайтеся про [втулки kubectl](/docs/tasks/extend-kubectl/kubectl-plugins/) +* Дізнайтеся більше про [власні ресурси](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* Дізнайтеся більше про [розширення API сервера](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +* Дізнайтеся про [Динамічний контроль допуску](/docs/reference/access-authn-authz/extensible-admission-controllers/) +* Дізнайтеся про [шаблон Оператора](/docs/concepts/extend-kubernetes/operator/) diff --git a/content/uk/docs/concepts/extend-kubernetes/api-extension/_index.md b/content/uk/docs/concepts/extend-kubernetes/api-extension/_index.md new file mode 100644 index 0000000000000..16a4c714de1b7 --- /dev/null +++ b/content/uk/docs/concepts/extend-kubernetes/api-extension/_index.md @@ -0,0 +1,10 @@ +--- +title: Розширючи API Kubernetes +weight: 30 +--- + +Власні ресурси користувача є розширенням API Kubernetes. Kubernetes надає два способи додавання власних ресурсів до вашого кластера: + +* Механізм [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRD) дозволяє вам декларативно визначити новий власний API з API-групою, видом (kind) та схемою, які ви вказуєте. Панель управління Kubernetes обслуговує та обробляє зберіганням вашого власного ресурсу. CRD дозволяє створювати нові типи ресурсів для вашого кластера без написання та запуску власного API-сервера. +* [Шар агрегації](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) розташований за основним API-сервером, який діє як проксі. Таке розташування називається агрегацією API (AA), яка дозволяє вам надавати спеціалізовані реалізації для ваших власних ресурсів, написавши та розгорнувши власний API-сервер. Основний API-сервер делегує запити до вашого API-сервера для власних API, які ви вказуєте, зробивши їх доступними для всіх своїх клієнтів. + diff --git a/content/uk/docs/concepts/extend-kubernetes/compute-storage-net/_index.md b/content/uk/docs/concepts/extend-kubernetes/compute-storage-net/_index.md new file mode 100644 index 0000000000000..8e06bf5faea89 --- /dev/null +++ b/content/uk/docs/concepts/extend-kubernetes/compute-storage-net/_index.md @@ -0,0 +1,27 @@ +--- +title: Розширення обчислення, зберігання та мережі +weight: 30 +no_list: true +--- + +Цей розділ охоплює розширення вашого кластера, які не входять до складу Kubernetes. Ви можете використовувати ці розширення для розширення функціональності вузлів у вашому кластері або для створення основи для мережі, яка зʼєднує Podʼи. + +* Втулки зберігання [CSI](/docs/concepts/storage/volumes/#csi) та [FlexVolume](/docs/concepts/storage/volumes/#flexvolume) + + Втулки {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) надають можливість розширити Kubernetes підтримкою нових типів томів. Томи можуть спиратись на надійні зовнішні сховища, або надавати тимчасові сховища, або можуть надавати доступ до інформації лише для читання використовуючи парадигму файлової системи. + + Kubernetes також включає підтримку втулків [FlexVolume](/docs/concepts/storage/volumes/#flexvolume), які є застарілими з моменту випуску Kubernetes v1.23 (використовуйте CSI замість них). + + Втулки FlexVolume дозволяють користувачам монтувати типи томів, які не підтримуються нативно Kubernetes. При запуску Pod, який залежить від сховища FlexVolume, kubelet викликає бінарний втулок для монтування тому. В заархівованій [пропозиції про дизайн FlexVolume](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md) є більше деталей щодо цього підходу. + + [Kubernetes Volume Plugin FAQ для постачальників зберігання](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors) містить загальну інформацію про втулки зберігання. + +* [Втулки пристроїв](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) + + Втулки пристроїв дозволяють вузлу виявляти нові можливості Node (на додаток до вбудованих ресурсів вузла, таких як `cpu` та `memory`) та надавати ці додаткові локальні можливості вузла для Podʼів, які їх запитують. + +* [Втулки мережі](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + + Втулки мережі дозволяють Kubernetes працювати з різними топологіями та технологіями мереж. Вашому кластеру Kubernetes потрібен _втулок мережі_ для того, щоб мати працюючу мережу для Podʼів та підтримувати інші аспекти мережевої моделі Kubernetes. + + Kubernetes {{< skew currentVersion >}} сумісний з втулками {{< glossary_tooltip text="CNI" term_id="cni" >}} мережі. diff --git a/content/uk/docs/concepts/extend-kubernetes/operator.md b/content/uk/docs/concepts/extend-kubernetes/operator.md new file mode 100644 index 0000000000000..4e7f0e03e9ea2 --- /dev/null +++ b/content/uk/docs/concepts/extend-kubernetes/operator.md @@ -0,0 +1,94 @@ +--- +title: Шаблон Operator +content_type: concept +weight: 30 +--- + + + +Оператори — це розширення програмного забезпечення для Kubernetes, які використовують [власні ресурси](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) для управління застосунками та їх компонентами. Оператори дотримуються принципів Kubernetes, зокрема [control loop](/docs/concepts/architecture/controller). + + + +## Мотивація {#motivation} + +_Шаблон operator_ спрямований на досягнення ключової мети людини-оператора, яка керує сервісом або набором сервісів. Люди-оператори, які відповідають за конкретні застосунки та сервіси, мають глибокі знання про те, як система повинна себе вести, як її розгорнути та як реагувати у разі проблем. + +Люди, які запускають робочі навантаження в Kubernetes, часто хочуть використовувати автоматизацію для виконання повторюваних завдань. Шаблон operator показує, як ви можете написати код для автоматизації завдання, яке виходить за межі того, що надає сам Kubernetes. + +## Оператори в Kubernetes {#operators-in-kubernetes} + +Kubernetes створений для автоматизації. З коробки ви отримуєте багато вбудованої автоматизації від ядра Kubernetes. Ви можете використовувати Kubernetes для автоматизації розгортання та запуску робочих навантажень, *та* ви можете автоматизувати те, як це робить Kubernetes. + +Концепція {{< glossary_tooltip text="шаблону operator" term_id="operator-pattern" >}} Kubernetes дозволяє розширити поведінку кластера без зміни коду самого Kubernetes, звʼязавши {{< glossary_tooltip text="контролери" term_id="controller" >}} з одним або кількома власними ресурсами. Оператори є клієнтами API Kubernetes, які діють як контролери для [власного ресурсу](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). + +## Приклад оператора {#example} + +Деякі завдання, які можна автоматизувати за допомогою оператора, включають: + +* розгортання застосунку за запитом +* створення та відновлення резервних копій стану цього застосунку +* керування оновленнями коду застосунку разом з повʼязаними змінами, такими як схеми баз даних або додаткові налаштування +* публікація Serviceʼів для застосунків, які не підтримують Kubernetes API, для їх виявлення +* емуляція відмови в усьому або частині кластера для перевірки його стійкості +* обрання лідера для розподіленого застосунку без внутрішнього процесу такого вибору. + +Яким може бути оператор у більш детальному вигляді? Ось приклад: + +1. Власний ресурс з назвою SampleDB, який можна налаштувати в кластері. +2. Deployment, який запускає Pod, що містить частину контролера оператора. +3. Образ контейнера з кодом оператора. +4. Код контролера, який надсилає запити до панелі управління, щоб дізнатися, яким чином налаштовано ресурси SampleDB. +5. Ядром оператора є код, який говорить API серверу, які дії потрібно виконати, щоб поточний стан ресурсу SampleDB відповідав бажаному стану ресурсів. + * Якщо ви додаєте новий ресурс SampleDB, оператор створює PersistentVolumeClaim для забезпечення місця для надійного зберігання даних, StatefulSet — для запуску SampleDB, та завдання (Job) для ініціалізації бази даних. + * Якщо ви видаляєте ресурс SampleDB, оператор зробить зліпок з усіх даних, потім переконається, що ресурси StatefulSet та Volume також видалені. +6. Оператор також керує процесом створення резервних копій бази даних. Для кожного ресурсу SampleDB оператор визначає, коли потрібно створити Pod, який підʼєднається до бази даних, та зробить резервну копію. Ці Podʼи можуть використовувати ConfigMap чи Secret, що містять облікові дані для підʼєднання до бази даних. +7. Оскільки оператор призначений для надання високого рівня автоматизації для керування ресурсами, тож для цього може використовуватись додатковий код. Наприклад, код, що визначає, чи база даних працює на старій версії, та якщо так, то створює Job для оновлення бази даних. + +## Розгортання операторів {#deploying-operators} + +Найпоширеніший спосіб розгортання операторів — це додавання CustomResourceDefinition (CRD) та контролера для них до вашого кластера. Контролери мають зазвичай запускатись за межами {{< glossary_tooltip text="панелі управління" term_id="control-plane" >}} кластера, так само як ви запускаєте будь-який інший контейнеризований застосунок. Наприклад, ви можете запустити ваш контролер як Deployment. + +## Використання операторів {#using-operators} + +Після того, як ви розгорнете оператора, ви будете використовувати його, додаючи, змінюючи або видаляючи тип ресурсу, який використовує оператор. Наслідуючи наведений вище приклад, ви б налаштували розгортання для самого оператора, а потім: + +```shell +kubectl get SampleDB # пошук налаштованої бази даних + +kubectl edit SampleDB/example-database # ручна заміна деяких параметрів +``` + +…і все! Оператор візьме на себе роботу застосування змін, а такою як і підтримання сервісу у відповідному стані. + +## Створення власних операторів {#writing-operator} + +Якщо в екосистемі немає оператора, який реалізує потрібну вам поведінку, ви можете створити власний. + +Ви також можете створити оператор (тобто, Контролер) використовуючи мову або рушій виконання, який працює як [клієнт API Kubernetes](/docs/reference/using-api/client-libraries/). + +Нижче наведено кілька бібліотек та інструментів, які ви можете використовувати для написання власного хмарного оператора. + +{{% thirdparty-content %}} + +* [Charmed Operator Framework](https://juju.is/) +* [Java Operator SDK](https://github.com/java-operator-sdk/java-operator-sdk) +* [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework) +* [kube-rs](https://kube.rs/) (Rust) +* [kubebuilder](https://book.kubebuilder.io/) +* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET operator SDK) +* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) +* [Mast](https://docs.ansi.services/mast/user_guide/operator/) +* [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html) along with WebHooks that + you implement yourself +* [Operator Framework](https://operatorframework.io) +* [shell-operator](https://github.com/flant/shell-operator) + +## {{% heading "whatsnext" %}} + +* Ознайомтесь з {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [Operator White Paper](https://github.com/cncf/tag-app-delivery/blob/163962c4b1cd70d085107fc579e3e04c2e14d59c/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md). +* Дізнайтесь більше про [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* Пошукайте готові оператори в [OperatorHub](https://operatorhub.io/), що можуть відповідати вашому випадку +* [Опублікуйте](https://operatorhub.io/) свій оператор для використання іншими +* Подивіться [оригінальну статтю від CoreOS](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html), що розповідає про шаблон оператора (тут посилання на архівну версію статті) +* Ознайомтесь зі [статтею](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) від Google Cloud про найкращі практики створення операторів diff --git a/content/uk/docs/concepts/overview/_index.md b/content/uk/docs/concepts/overview/_index.md index efffaf0892adf..9de566af72b29 100644 --- a/content/uk/docs/concepts/overview/_index.md +++ b/content/uk/docs/concepts/overview/_index.md @@ -1,4 +1,104 @@ --- +reviewers: +- bgrant0607 +- mikedanese title: "Огляд" +description: > + Kubernetes — це переносима, розширювана та відкрита платформа для управління контейнеризованими навантаженнями та службами, яка полегшує як декларативне, так і автоматичне налаштування. Вона має велику та швидко зростаючу екосистему. Служби, підтримка та інструменти Kubernetes широко доступні. weight: 20 +card: + name: concepts + weight: 10 + anchor: + - anchor: "#why-you-need-kubernetes-and-what-can-it-do" + title: Чому Kubernetes? +no_list: true --- + + +Ця сторінка надає вступ до основних концепцій Kubernetes. + + + +Kubernetes — це переносима, розширювана та відкрита платформа для управління контейнеризованими навантаженнями та службами, яка полегшує як декларативне, так і автоматичне налаштування. Вона має велику та швидко зростаючу екосистему. Служби, підтримка та інструменти Kubernetes широко доступні + +Назва Kubernetes (/ˌk(j)uːbərˈnɛtɪs, Кубернетіс) походить від грецького слова, що означає особу, яка керує кораблем. K8s — це скорочення Kubernetes, яке складається з першої літери «K», потім восьми літер і, нарешті, літери «s». Google зробив Kubernetes проєктом з відкритим кодом у 2014 році. Kubernetes поєднує [понад 15 років досвіду Google](/blog/2015/04/borg-predecessor-to-kubernetes/) у роботі з контейнеризованими навантаженнями з найкращими ідеями та практиками спільноти. + +## Назад у минуле + +Погляньмо на те, чому Kubernetes настільки корисний, повернувшись в минуле. + +![Deployment evplution](/images/docs/Container_Evolution.svg) + +**Ера традиційного розгортання:** На початку, організації запускали свої застосунки на фізичних серверах. Не було можливості визначити межі ресурсів для застосунків на фізичному сервері, і це спричиняло проблеми з розподілом ресурсів. Наприклад, якщо на фізичному сервері працює кілька програм, можуть бути випадки, коли одна програма займе більшу частину ресурсів, і в результаті інші застосунки будуть працювати не так. Рішенням для цього було б запустити кожну програму на іншому фізичному сервері. Але це не масштабувалося, оскільки ресурси були недостатньо використані, і організаціям було дорого підтримувати багато фізичних серверів. + +**Ера віртуалізованого розгортання:** Як розвʼязання цієї проблеми виникла віртуалізація. Вона дозволяє запускати кілька віртуальних машин на одному фізичному сервері. Віртуалізація дозволяє ізолювати застосунки в межах віртуальних машин та надає такий рівень безпеки, що інформація з одного застосунку не може бути вільно доступною в іншому застосунку. + +Віртуалізація дозволяє краще використовувати ресурси фізичного сервера та означає кращу масштабованість, оскільки застосунки можуть бути легко додані та оновлені разом зі скороченням витрат на апаратне забезпечення. За допомогою віртуалізації ви можете представити набір фізичних ресурсів у вигляді кластера із пулом замінюваних віртуальних машин. + +Кожна віртуальна машина є компʼютером, який має всі компоненти, включаючи операційну систему, встановлену на віртуальне апаратне забезпечення. + +**Ера контейнеризації:** Контейнери подібні до віртуальних машин, але вони мають слабкішу ізоляцію і можуть використовувати спільну операційну систему поміж застосунками. Тому контейнери вважаються легшими, ніж віртуальні машини. Так само, як і віртуальні машини, контейнери мають власну файлову систему, спільно використовують ресурси ЦП, памʼять, простір процесів та інше. Оскільки вони відокремлені від базової інфраструктури, їх просто переносити між хмарами та ОС. + +Контейнери набули популярності, оскільки вони надають додаткові вигоди, такі як: + +* Гнучке створення та розгортання застосунків: підвищено простоту та ефективність створення образу контейнера порівняно з використанням образу віртуальної машини. +* Безперервна розробка, інтеграція та розгортання: забезпечує надійне та часте створення та розгортання образу контейнера зі швидким та ефективним відкатом (через незмінність образу). +* Розділення Dev та Ops: створення образів контейнерів застосунків під час створення/випуску, а не під час розгортання, тим самим застосунки відокремлюються від інфраструктури. +* Спостережуваність: не тільки відображає інформацію та метрики на рівні ОС, але й стан застосунків та інші сигнали. +* Узгодженість оточення розробки, тестування та експлуатації: все працює так само на ноутбуці, як і в хмарі. +* Переносимість між хмарами та ОС: працює на Ubuntu, RHEL, CoreOS, у приватних хмарах, основних публічних хмарах — всюди. +* Управління, орієнтоване на застосунки: підвищує рівень абстракції від запуску ОС на віртуальному обладнанні до запуску застосунків в ОС з використанням логічних ресурсів. +* Вільно повʼязані, розподілені, еластичні, звільнені мікросервіси: застосунки розбиваються на менші, незалежні частини та можуть бути розгорнуті та керовані динамічно — на відміну від монолітного стека, що працює на одній великій спеціально призначеній для цього машині. +* Ізоляція ресурсів: передбачувана продуктивність застосунків. +* Використання ресурсів: висока ефективність та щільність. + +## Чому вам потрібен Kubernetes та що він може робити?{#why-you-need-kubernetes-and-what-can-it-do} + +Контейнери — це гарний спосіб обʼєднати та запустити ваші застосунки. У промисловому середовищі вам потрібно керувати контейнерами, які запускають застосунки, і гарантувати відсутність простоїв. Наприклад, якщо контейнер падає, повинен запуститися інший контейнер. Чи не було б легше, якби такою поведінкою займалася система? + +Ось саме тут Kubernetes приходить на допомогу! Kubernetes надає вам фреймворк для надійного запуску розподілених систем. Він піклується про масштабування та відмовостійкість для ваших застосунків, забезпечує шаблони розгортання тощо. Наприклад: Kubernetes може легко керувати розгортанням канарки (canary deployment) для вашої системи. + +Kubernetes надає вам: + +* **Служби виявлення та балансування** + Kubernetes може надати доступ до контейнерів застосунків за допомогою внутрішньої IP-адреси та імені DNS. Якщо навантаження на контейнер зростає, Kubernetes може балансувати навантаження та розподіляти мережевий трафік, що робить роботу розгортання стабільно. +* **Оркестрування зберіганням** + Kubernetes дозволяє автоматично монтувати системи зберігання, такі як локальні пристрої, хмарні ресурси тощо. +* **Автоматизоване розгортання та згортання** + Ви можете описати бажаний стан вашого розгорнутого контейнера використовуючи Kubernetes, а він може змінювати стан вашого контейнера, щоб відповідати бажаному стану з певним рівнем відповідності. Наприклад, ви можете налаштувати Kubernetes так, щоб він автоматично створював контейнери з вашими застосунками для вашого розгортання, вилучав контейнери, які не використовуються та використовував їх ресурси для нових контейнерів. +* **Автоматичне пакування** + Ви надаєте Kubernetes кластер вузлів, які він може використовувати для виконання контейнеризованих завдань. Ви вказуєте Kubernetes, скільки процесорних потужностей та памʼяті (ОЗП) потрібно кожному контейнеру. Kubernetes може помістити контейнери на ваші вузли, щоб найкращим чином використовувати ресурси. +* **Самовідновлення** + Kubernetes перезапускає контейнери, які впали, заміняє контейнери, прибиває контейнери, які не відповідають визначеному користувачем стану під час перевірки, очікує готовності їх до роботи перш ніж пропонувати їх клієнтам. +* **Секрети та керування конфігураціями** + Kubernetes дозволяє зберігати та керувати чутливими даними, такими як паролі, OAuth-токени та SSH-ключі. Ви можете розгортати та оновлювати конфігурацію та секрети без перезбирання образу вашого контейнера, без розголошення секретів у вашому стеку конфігурації. +* **Пакетне виконання** + На додачу до сервісів, Kubernetes може керувати пакетним виконанням процесів та CI завдань, заміщаючи контейнери, що зазнали збою, за потреби. +* **Горизонтальне масштабування** + Масштабуйте ваші застосунки, збільшуючи чи зменшуючи кількість робочих навантажень, просто командами, за допомогою UI або автоматично залежно від використання ЦП або інших ресурсів. +* **Подвійний стек IPv4/IPv6** + Виділення адрес IPv4 та IPv6 для Podʼів та Serviceʼів. +* **Запланована розширюваність** + Додавайте нові функції до Kubernetes без зміни основного коду Kubernetes. + +## Чим не є Kubernetes? + +Kubernetes не є традиційною, все-в-одному PaaS-платформою (Platform as a Service). Оскільки Kubernetes працює на рівні контейнерів, а не апаратному рівні, він надає деякі загально прийняті функції PaaS, такі як розгортання, масштабування, балансування навантаження та дозволяє користувачам інтегрувати власні рішення для моніторингу, журналювання тощо. Однак, Kubernetes не є монолітом і ці рішення є підʼєднуваними та необовʼязковими. Kubernetes надає вам будівельні блоки, які можна зʼєднати для створення платформи для розробки, але залишає вами вибір та гнучкість саме там де вам це потрібно. + +Kubernetes: + +* Не обмежує типи підтримуваних застосунків. Kubernetes прагне підтримувати надзвичайно різноманітні робочі навантаження, включаючи робочі навантаження stateless, stateful та робочі навантаження з обробки даних. Якщо застосунок може працювати в контейнері, він повинен чудово працювати на Kubernetes. +* Не розгортає код і не збирає ваш застосунок. Робочі процеси безперервної інтеграції, доставки та розгортання (CI/CD) визначаються культурою та уподобаннями організації, а також технічними вимогами. +* Не надає служби на рівні застосунків, такі як middleware, проміжне програмне забезпечення (наприклад, шини повідомлень), фреймворки обробки даних (наприклад, Spark), бази даних (наприклад, MySQL), кеші або кластерні системи зберігання (наприклад, Ceph) як вбудовані служби. Такі компоненти можуть працювати на Kubernetes та/або бути доступні застосункам, що працюють на Kubernetes, за допомогою механізмів перенесення, таких як [Open Service Broker](https://openservicebrokerapi.org/). +* Не диктує рішення для логування, моніторингу або оповіщення. Він забезпечує деякі інтеграції як доказ концепції та механізми збору та експорту метрік. +* Не надає та не ставить вимог щодо мови/системної конфігурації (наприклад, Jsonnet). Він надає декларативний API, який може використовуватись довільними формами декларативних специфікацій. +* Не забезпечує і не приймає будь-які комплексні системи конфігурації машини, обслуговування, управління або самовідновлення. +* Крім того, Kubernetes — це не просто система оркестрування. Насправді вона усуває необхідність оркестрування. Технічним визначенням оркестрування є виконання визначеного робочого процесу: спочатку зробіть A, потім B, потім C. На відміну від цього, Kubernetes має в собі набір незалежних, складових процесів управління, які безперервно рухають поточний стан до вказаного бажаного стану. Не має значення, як ви перейдете від А до С. Централізоване управління також не потрібне. Це призводить до того, що система простіша у використанні та потужніша, надійна, стійка та розширювана. + +## {{% heading "whatsnext" %}} + +* Подивіться на [Компоненти Kubernetes](/docs/concepts/overview/components/) +* Подивіться на [API Kubernetes](/docs/concepts/overview/kubernetes-api/) +* Подивіться на [Архітектура кластера](/docs/concepts/architecture/) +* Готові [розпочати](/docs/setup/)? diff --git a/content/uk/docs/concepts/overview/components.md b/content/uk/docs/concepts/overview/components.md new file mode 100644 index 0000000000000..241d90e62e41a --- /dev/null +++ b/content/uk/docs/concepts/overview/components.md @@ -0,0 +1,129 @@ +--- +reviewers: +- lavalamp +title: Компоненти Kubernetes +content_type: concept +description: > + Кластер Kubernetes складається з компонентів, які є частиною панелі управління та набору машин, які називаються вузлами. +weight: 30 +card: + title: Компоненти кластера + name: concepts + weight: 20 +--- + + + +В результаті розгортання Kubernetes ви отримуєте кластер. +{{< glossary_definition term_id="cluster" length="all" prepend="Кластер Kubernetes — це ">}} + +Цей документ описує різні компоненти, які вам потрібні для повноцінного та працездатного кластера Kubernetes. + +{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Components of Kubernetes" caption="Компоненти кластера Kubernetes" class="diagram-large" >}} + + + +## Компоненти панелі управління {#control-plane-components} + +Компонент панелі управління приймають глобальні рішення щодо кластера (наприклад, планування), а також виявляють та реагують на події кластера (наприклад, запуск нового {{< glossary_tooltip text="Podʼу" term_id="pod" >}} якщо поле `{{< glossary_tooltip text="replicas" term_id="replica" >}}` Deploymentʼу не задовільне). + +Компоненти панелі управління можуть запускатись будь-якій машині в кластері. Однак для спрощення сценарії налаштування зазвичай запускають усі компоненти рівня керування на одній машині та не запускають контейнери користувача на цій машині. Дивіться [Створення кластера високої доступності за допомогою kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) для прикладу розгортання панелі управління, яка працює на кількох машинах. + +### 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" >}} + +Існує багато різних типів контролерів. Декілька прикладів: + +* Контролер вузла (Node controller): Відповідає за виявлення та реакцію, коли вузли виходять з ладу. +* Контролер завдань (Job controller): Спостерігає за обʼєктами Job, які представляють одноразові завдання, а потім створює + Podʼи для виконання цих завдань до завершення. +* Контролер EndpointSlice: Заповнює обʼєкти EndpointSlice (для надання звʼязку між Serviceʼами та Podʼами). +* Контролер облікового запису служби (ServiceAccount controller): Створює стандартні облікові записи служби для нових просторів імен. + +Вище наведений перелік не є вичерпним. + +### cloud-controller-manager + +{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} + +`cloud-controller-manager` запускає лише ті контролери, які є специфічними для вашого хмарного постачальника. Якщо ви використовуєте Kubernetes на власних серверах або у навчальному середовищі на своєму ПК, кластер не має менеджера хмарових контролерів. + +Так само як і з `kube-controller-manager`, `cloud-controller-manager` обʼєднує кілька логічно незалежних кілець управління в єдиний виконуваний файл, який ви запускаєте як один процес. Ви можете масштабувати його горизонтально (запускати більше одного екземпляра), щоб покращити продуктивність чи допомогти витримати випадки відмов. + +Наступні контролери можуть мати залежності від хмарного постачальника: + +* Контролер вузла (Node controller): Для перевірки хмарного постачальника з метою визначення, чи був вузол видалений у хмарі після того, як він перестав відповідати. +* Контролер маршруту (Route controller): Для налаштування маршрутів в основній інфраструктурі хмари. +* Контролер служби (Service controller): Для створення, оновлення та видалення балансувальників навантаження хмарового постачальника. + +## Компоненти вузлів {#node-components} + +Компоненти вузлів запускаються на кожному вузлі, і вони відповідають за запуск Podʼів та забезпечення середовища виконання Kubernetes. + +### kubelet + +{{< glossary_definition term_id="kubelet" length="all" >}} + +### kube-proxy + +{{< glossary_definition term_id="kube-proxy" length="all" >}} + +### Середовище виконання контейнерів (Container runtime) {#container-runtime} + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +## Доповнення {#addons} + +Доповнення використовують ресурси ({{< glossary_tooltip term_id="daemonset" >}}, {{< glossary_tooltip term_id="deployment" >}}, та інші) для реалізації функцій кластера. Оскільки вони надають функції на рівні кластера, ресурси простору імен для додатків належать до простору імен `kube-system`. + +Деякі доповнення описані нижче; за повним переліком доповнень звертайтесь до розділу [Доповнення](/docs/concepts/cluster-administration/addons/). + +### DNS + +Хоча інші додатки не є строго обовʼязковими, у всіх кластерах Kubernetes повинен бути [кластерний DNS](/docs/concepts/services-networking/dns-pod-service/), оскільки багато прикладів покладаються на його наявність. + +Кластерний DNS — це DNS-сервер, додатковий до інших DNS-серверів у вашому середовищі, який обслуговує DNS-записи для служб Kubernetes. + +Контейнери, які запускаються за допомогою Kubernetes, автоматично включають цей DNS-сервер у свій пошук DNS. + +### Web UI (Dashboard) {#web-ui-dashboard} + +[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) — це універсальний вебінтерфейс для кластерів Kubernetes. Він дозволяє користувачам керувати та розвʼязувати проблеми з застосунками, які працюють у кластері, а також самим кластером. + +### Моніторинг ресурсів контейнера {#container-resource-monitoring} + +[Моніторинг ресурсів контейнера](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) веде запис загальних метрик часових рядів +щодо контейнерів у центральній базі даних та надає інтерфейс користувача для перегляду цих даних. + +### Логування на рівні кластера {#cluster-level-logging} + +Механізм [логування на рівні кластера](/docs/concepts/cluster-administration/logging/) відповідає за збереження логів контейнерів у центральному сховищі логів з інтерфейсом пошуку/перегляду. + +### Втулки мережі {#network-plugins} + +[Втулки мережі](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins) – це програмні компоненти, які впроваджують специфікацію інтерфейсу мережі контейнера (CNI). Вони відповідають за виділення IP-адрес для Podʼів та уможливлюють їм взаємодію один з одним у межах кластера. + +## {{% heading "whatsnext" %}} + +Дізнайтесь також про: + +* [Вузли](/docs/concepts/architecture/nodes/) та [обмін трафіком між ними](/docs/concepts/architecture/control-plane-node-communication/) та панеллю управління. +* [Контролери](/docs/concepts/architecture/controller/) Kubernetes. +* [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/), який є стандартним планувальником Kubernetes. +* Офіційна [документація](https://etcd.io/docs/) etcd. +* Кілька [середовищ виконання контейнерів](/docs/setup/production-environment/container-runtimes/) в Kubernetes. +* Інтеграці з хмарними постачальниками з використанням [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/). +* Команди [kubectl](/docs/reference/generated/kubectl/kubectl-commands). diff --git a/content/uk/docs/concepts/overview/kubernetes-api.md b/content/uk/docs/concepts/overview/kubernetes-api.md new file mode 100644 index 0000000000000..ae14bd89b1fa8 --- /dev/null +++ b/content/uk/docs/concepts/overview/kubernetes-api.md @@ -0,0 +1,192 @@ +--- +reviewers: +- chenopis +title: API Kubernetes +content_type: concept +weight: 40 +description: > + API Kubernetes дозволяє отримувати та маніпулювати станом обʼєктів в Kubernetes. Основа панелі управління Kubernetes — це сервер API та відкритий API HTTP, який він надає. Користувачі, різні частини вашого кластера та зовнішні компоненти взаємодіють одне з одним через сервер API. +card: + name: концепції + weight: 30 +--- + + + +Основа Kubernetes — це {{< glossary_tooltip text="панель управління" term_id="control-plane" >}} з {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}}. Сервер API використовує API HTTP, яке дозволяє кінцевим користувачам, різним частинам вашого кластера та зовнішнім компонентам спілкуватися один з одним. + +API Kubernetes дозволяє вам отримувати та маніпулювати станом обʼєктів API в Kubernetes (наприклад: Pod, Namespace, ConfigMap та Event). + +Більшість операцій можна виконати за допомогою інтерфейсу командного рядка [kubectl](/docs/reference/kubectl/) або інших інструментів командного рядка, таких як [kubeadm](/docs/reference/setup-tools/kubeadm/), які, своєю чергою, використовують API. Однак ви також можете отримати доступ до API безпосередньо за допомогою викликів REST. + +Розгляньте використання однієї з [клієнтських бібліотек](/docs/reference/using-api/client-libraries/), якщо ви пишете застосунок для користування API Kubernetes. + + + +## Специфікація OpenAPI {#api-specification} + +Повні відомості про API задокументовано за допомогою [OpenAPI](https://www.openapis.org/). + +### OpenAPI V2 + +Сервер API Kubernetes надає обʼєднану специфікацію OpenAPI v2 через endpoint `/openapi/v2`. Ви можете запросити формат відповіді, використовуючи заголовки запиту наступним чином: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Дійсні значення заголовків запиту для запитів OpenAPI v2
ЗаголовокМожливі значенняПримітки
Accept-Encodinggzipне надання цього заголовка також допустиме
Acceptapplication/com.github.proto-openapi.spec.v2@v1.0+protobufголовним чином для внутрішньокластерного використання
application/jsonтипово
*обслуговує application/json
+ +Kubernetes реалізує альтернативний формат серіалізації на основі Protobuf, який призначений головним чином для комунікації всередині кластера. Докладніше про цей формат читайте в [пропозиції дизайну серіалізації Kubernetes Protobuf](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md) та файлах мови опису інтерфейсу (IDL) для кожної схеми, які розташовані в пакунках Go, які визначають обʼєкти API. + +### OpenAPI V3 + +{{< feature-state state="stable" for_k8s_version="v1.27" >}} + +Kubernetes підтримує публікацію опису своїх API у форматі OpenAPI v3. + +Надається endpoint `/openapi/v3` для перегляду списку всіх доступних груп/версій. Цей endpoint повертає лише JSON. Ці групи/версії вказані у наступному форматі: + +```yaml +{ + "paths": { + ..., + "api/v1": { + "serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59 + +AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF" + }, + "apis/admissionregistration.k8s.io/v1": { + "serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597" + }, + .... + } +} +``` + + +Відносні URL вказують на незмінний опис OpenAPI для поліпшення кешування на стороні клієнта. Також API-сервер встановлює відповідні заголовки кешування HTTP (`Expires` на 1 рік вперед та `Cache-Control` на `immutable`). При використанні застарілого URL API-сервер повертає перенаправлення на новий URL. + +API-сервер Kubernetes публікує специфікацію OpenAPI v3 для кожної групи версій Kubernetes через endpoint `/openapi/v3/apis//?hash=`. + +Дивіться таблицю нижче для прийнятних заголовків запиту. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Дійсні значення заголовків запиту для запитів OpenAPI v3
ЗаголовокМожливі значенняПримітки
Accept-Encodinggzipне надання цього заголовка також допустиме
Acceptapplication/com.github.proto-openapi.spec.v3@v1.0+protobufголовним чином для внутрішньокластерного використання
application/jsonза замовчуванням
*обслуговує application/json
+ +Для отримання OpenAPI V3 використовуйте реалізацію Golang, яка надається у пакунку `k8s.io/client-go/openapi3`. + +## Стійкість {#persistence} + +Kubernetes зберігає серіалізований стан обʼєктів, записуючи їх у {{< glossary_tooltip term_id="etcd" >}}. + +## Виявлення API {#api-discovery} + +Список всіх груп версій, які підтримує кластер, публікується через кінцеві точки `/api` та `/apis`. Кожна група версій також оголошує список ресурсів, які підтримуються через `/apis//` (наприклад: `/apis/rbac.authorization.k8s.io/v1alpha1`). Ці кінцеві точки використовуються kubectl для отримання списку ресурсів, які підтримує кластер. + +### Сукупне виявлення {#aggregated-discovery} + +{{< feature-state state="beta" for_k8s_version="v1.27" >}} + +Kubernetes надає бета-підтримку сукупного виявлення, публікуючи всі ресурси, які підтримує кластер, через два endpointʼи (`/api` та `/apis`) порівняно з одним для кожної групи версій. Надсилання запиту до цієї кінцевої точки різко зменшує кількість надісланих запитів для отримання виявлення середнього кластера Kubernetes. Це можна здійснити, запросивши відповідні кінцеві точки із заголовком Accept, що вказує на сукупне виявлення ресурсів: `Accept: application/json;v=v2beta1;g=apidiscovery.k8s.io;as=APIGroupDiscoveryList`. + +Цей endpoint також підтримує ETag та кодування Protobuf. + +## Групи API та версіювання {#api-groups-and-versioning} + +{{< feature-state state="stable" for_k8s_version="v1.8" >}} + +Щоб полегшити вилучення полів або перебудову представлень ресурсів, Kubernetes підтримує кілька версій API, кожна з різним API-шляхом, таким як `/api/v1` або `/apis/rbac.authorization.k8s.io/v1alpha1`. + +Версіювання робиться на рівні API, а не на рівні ресурсу чи поля, щоб забезпечити чіткий, послідовний погляд на ресурси та поведінку системи, а також для можливості керування доступом до застарілих та/або експериментальних API. + +Щоб полегшити еволюцію та розширення свого API, Kubernetes реалізує [API groups](/docs/reference/using-api/#api-groups), які можна [увімкнути або вимкнути](/docs/reference/using-api/#enabling-or-disabling). + +Ресурси API розрізняються за їхньою API-групою, типом ресурсу, простором імен (для ресурсів з підтримкою просторів імен) та назвою. Сервер API обробляє конвертацію між версіями API прозоро: всі різні версії фактично є представленням тих самих даних. Сервер API може служити тими самими базовими даними через кілька версій API. + +Наприклад, припустимо, є дві версії API, `v1` та `v1beta1`, для того самого ресурсу. Якщо ви спочатку створили обʼєкт, використовуючи версію `v1beta1` його API, ви можете згодом читати, оновлювати чи видаляти цей обʼєкт, використовуючи або версію API `v1beta1`, або версію `v1`, поки версія `v1beta1` не буде застарілою та видаленою. На цьому етапі ви можете продовжувати отримувати доступ та модифікувати обʼєкт, використовуючи API версії `v1`. + +### Зміни в API {#api-changes} + +{{< feature-state state="stable" for_k8s_version="v1.8" >}} + +Будь-яка система, яка досягла успіху, повинна рости та змінюватися, коли зʼявляються нові випадки її використання або змінюються поточні. Тому Kubernetes розробив своє API так, щоб він постійно змінювався та ріс. Проєкт Kubernetes має за мету _не_ порушувати сумісність з наявними клієнтами та забезпечити цю сумісність на тривалий час, щоб інші проєкти мали можливість адаптуватися. + +Загалом можна часто та періодично додавати нові ресурси API та нові поля ресурсів. Усунення ресурсів чи полів вимагає дотримання [політики застарівання API](/docs/reference/using-api/deprecation-policy/). + +Kubernetes твердо зобовʼязується підтримувати сумісність з офіційними API Kubernetes, як тільки вони досягнуть загальної доступності (GA), як правило, у версії API `v1`. Крім того, Kubernetes підтримує сумісність з даними, що зберігаються через _бета-версії_ API офіційних API Kubernetes, і гарантує, що дані можуть бути перетворені та доступні через версії GA API, коли функція стане стабільною. + +Якщо ви використовуєте бета-версію API, вам слід перейти до наступної бета- або стабільної версії API, якщо це API набуло зрілості. Найкращий час для цього — під час періоду застарівання бета- API, оскільки обʼєкти одночасно доступні через обидві версії API. Як тільки бета- API завершить свій період застарівання і більше не буде обслуговуватися, слід використовувати версію API-замінник. + +{{< note >}} +Попри те, що Kubernetes також ставить перед собою мету зберігати сумісність для версій _альфа_ API, в деяких випадках це неможливо. Якщо ви використовуєте будь-які альфа-версії API, перевірте примітки до випуску Kubernetes при оновленні кластера, в разі змін API, які можуть бути несумісними та вимагати видалення всіх наявних альфа-обʼєктів перед оновленням. +{{< /note >}} + +Дивіться [довідник по версіях API](/docs/reference/using-api/#api-versioning) для отримання докладнішої інформації про визначення рівня API. + +## Розширення API {#api-extension} + +API Kubernetes можна розширити одним з двох способів: + +1. [Власні ресурси](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) дозволяють декларативно визначити, як API-сервер повинен надавати вибраний вами ресурс API. +1. Ви також можете розширити API Kubernetes, реалізовуючи [шар агрегації](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). + +## {{% heading "whatsnext" %}} + +- Дізнайтеся, як розширити API Kubernetes, додаючи свій власний [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). +- [Контроль доступу до Kubernetes API](/docs/concepts/security/controlling-access/) описує, як кластер керує автентифікацією та авторизацією для доступу до API. +- Дізнайтеся про endpointʼи API, типи ресурсів та зразки з [API Reference](/docs/reference/kubernetes-api/). +- Дізнайтеся про те, що є сумісною зміною та як змінити API, в [Зміни в API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). diff --git a/content/uk/docs/concepts/overview/what-is-kubernetes.md b/content/uk/docs/concepts/overview/what-is-kubernetes.md deleted file mode 100644 index b3c52cab3be6a..0000000000000 --- a/content/uk/docs/concepts/overview/what-is-kubernetes.md +++ /dev/null @@ -1,183 +0,0 @@ ---- -title: Що таке Kubernetes? -content_type: concept -weight: 10 -card: - name: concepts - weight: 10 ---- - - - -Ця сторінка являє собою узагальнений огляд Kubernetes. - - - - -Kubernetes - це платформа з відкритим вихідним кодом для управління контейнеризованими робочими навантаженнями та супутніми службами. Її основні характеристики - кросплатформенність, розширюваність, успішне використання декларативної конфігурації та автоматизації. Вона має гігантську, швидкопрогресуючу екосистему. - - -Назва Kubernetes походить з грецької та означає керманич або пілот. Google відкрив доступ до вихідного коду проекту Kubernetes у 2014 році. Kubernetes побудовано [на базі п'ятнадцятирічного досвіду, що Google отримав, оперуючи масштабними робочими навантаженнями](https://research.google/pubs/pub43438) у купі з найкращими у своєму класі ідеями та практиками, які може запропонувати спільнота. - - -## Озираючись на першопричини - - -Повернімось назад у часі та дізнаємось, завдяки чому Kubernetes став таким корисним. - -![Еволюція розгортання](/images/docs/Container_Evolution.svg) - - -**Ера традиційного розгортання:** На початку організації запускали застосунки на фізичних серверах. Оскільки в такий спосіб не було можливості задати обмеження використання ресурсів, це спричиняло проблеми виділення та розподілення ресурсів на фізичних серверах. Наприклад: якщо багато застосунків було запущено на фізичному сервері, могли траплятись випадки, коли один застосунок забирав собі найбільше ресурсів, внаслідок чого інші програми просто не справлялись з обов'язками. Рішенням може бути запуск кожного застосунку на окремому фізичному сервері. Але такий підхід погано масштабується, оскільки ресурси не повністю використовуються; на додачу, це дорого, оскільки організаціям потрібно опікуватись багатьма фізичними серверами. - - -**Ера віртуалізованого розгортання:** Як рішення - була представлена віртуалізація. Вона дозволяє запускати численні віртуальні машини (Virtual Machines або VMs) на одному фізичному ЦПУ сервера. Віртуалізація дозволила застосункам бути ізольованими у межах віртуальних машин та забезпечувала безпеку, оскільки інформація застосунку на одній VM не була доступна застосунку на іншій VM. - - -Віртуалізація забезпечує краще використання ресурсів на фізичному сервері та кращу масштабованість, оскільки дозволяє легко додавати та оновлювати застосунки, зменшує витрати на фізичне обладнання тощо. З віртуалізацією ви можете представити ресурси у вигляді одноразових віртуальних машин. - - -Кожна VM є повноцінною машиною з усіма компонентами, включно з власною операційною системою, що запущені поверх віртуалізованого апаратного забезпечення. - - -**Ера розгортання контейнерів:** Контейнери схожі на VM, але мають спрощений варіант ізоляції і використовують спільну операційну систему для усіх застосунків. Саме тому контейнери вважаються "легкими", в порівнянні з віртуалками. Подібно до VM, контейнер має власну файлову систему, ЦПУ, пам'ять, простір процесів тощо. Оскільки контейнери вивільнені від підпорядкованої інфраструктури, їх можна легко переміщати між хмарними провайдерами чи дистрибутивами операційних систем. - -Контейнери стали популярними, бо надавали додаткові переваги, такі як: - - - -* Створення та розгортання застосунків за методологією Agile: спрощене та більш ефективне створення образів контейнерів у порівнянні до використання образів віртуальних машин. -* Безперервна розробка, інтеграція та розгортання: забезпечення надійних та безперервних збирань образів контейнерів, їх швидке розгортання та легкі відкатування (за рахунок незмінності образів). -* Розподіл відповідальності команд розробки та експлуатації: створення образів контейнерів застосунків під час збирання/релізу на противагу часу розгортання, і як наслідок, вивільнення застосунків із інфраструктури. -* Спостереження не лише за інформацією та метриками на рівні операційної системи, але й за станом застосунку та іншими сигналами. -* Однорідність середовища для розробки, тестування та робочого навантаження: запускається так само як на робочому комп'ютері, так і у хмарного провайдера. -* ОС та хмарна кросплатформність: запускається на Ubuntu, RHEL, CoreOS, у власному дата-центрі, у Google Kubernetes Engine і взагалі будь-де. -* Керування орієнтоване на застосунки: підвищення рівня абстракції від запуску операційної системи у віртуальному апаратному забезпеченні до запуску застосунку в операційній системі, використовуючи логічні ресурси. -* Нещільно зв'язані, розподілені, еластичні, вивільнені мікросервіси: застосунки розбиваються на менші, незалежні частини для динамічного розгортання та управління, на відміну від монолітної архітектури, що працює на одній великій виділеній машині. -* Ізоляція ресурсів: передбачувана продуктивність застосунку. -* Використання ресурсів: висока ефективність та щільність. - - -## Чому вам потрібен Kubernetes і що він може робити - - -Контейнери - це прекрасний спосіб упакувати та запустити ваші застосунки. У прод оточенні вам потрібно керувати контейнерами, в яких працюють застосунки, і стежити, щоб не було простою. Наприклад, якщо один контейнер припиняє роботу, інший має бути запущений йому на заміну. Чи не легше було б, якби цим керувала сама система? - - -Ось де Kubernetes приходить на допомогу! Kubernetes надає вам каркас для еластичного запуску розподілених систем. Він опікується масштабуванням та аварійним відновленням вашого застосунку, пропонує шаблони розгортань тощо. Наприклад, Kubernetes дозволяє легко створювати розгортання за стратегією canary у вашій системі. - - -Kubernetes надає вам: - - - -* **Виявлення сервісів та балансування навантаження** -Kubernetes може надавати доступ до контейнера, використовуючи DNS-ім'я або його власну IP-адресу. Якщо контейнер зазнає завеликого мережевого навантаження, Kubernetes здатний збалансувати та розподілити його таким чином, щоб якість обслуговування залишалась стабільною. -* **Оркестрація сховища інформації** -Kubernetes дозволяє вам автоматично монтувати системи збереження інформації на ваш вибір: локальні сховища, рішення від хмарних провайдерів тощо. -* **Автоматичне розгортання та відкатування** -За допомогою Kubernetes ви можете описати бажаний стан контейнерів, що розгортаються, і він регульовано простежить за виконанням цього стану. Наприклад, ви можете автоматизувати в Kubernetes процеси створення нових контейнерів для розгортання, видалення існуючих контейнерів і передачу їхніх ресурсів на новостворені контейнери. -* **Автоматичне розміщення задач** -Ви надаєте Kubernetes кластер для запуску контейнерізованих задач і вказуєте, скільки ресурсів ЦПУ та пам'яті (RAM) необхідно для роботи кожного контейнера. Kubernetes розподіляє контейнери по вузлах кластера для максимально ефективного використання ресурсів. -* **Самозцілення** -Kubernetes перезапускає контейнери, що відмовили; заміняє контейнери; зупиняє роботу контейнерів, що не відповідають на задану користувачем перевірку стану, і не повідомляє про них клієнтам, допоки ці контейнери не будуть у стані робочої готовності. -* **Управління секретами та конфігурацією** -Kubernetes дозволяє вам зберігати та керувати чутливою інформацією, такою як паролі, OAuth токени та SSH ключі. Ви можете розгортати та оновлювати секрети та конфігурацію без перезбирання образів ваших контейнерів, не розкриваючи секрети в конфігурацію стека. - - - -## Чим не є Kubernetes - - -Kubernetes не є комплексною системою PaaS (Платформа як послуга) у традиційному розумінні. Оскільки Kubernetes оперує швидше на рівні контейнерів, аніж на рівні апаратного забезпечення, деяка загальнозастосована функціональність і справді є спільною з PaaS, як-от розгортання, масштабування, розподіл навантаження, логування і моніторинг. Водночас Kubernetes не є монолітним, а вищезазначені особливості підключаються і є опціональними. Kubernetes надає будівельні блоки для створення платформ для розробників, але залишає за користувачем право вибору у важливих питаннях. - - -Kubernetes: - - - -* Не обмежує типи застосунків, що підтримуються. Kubernetes намагається підтримувати найрізноманітніші типи навантажень, включно із застосунками зі станом (stateful) та без стану (stateless), навантаження по обробці даних тощо. Якщо ваш застосунок можна контейнеризувати, він чудово запуститься під Kubernetes. -* Не розгортає застосунки з вихідного коду та не збирає ваші застосунки. Процеси безперервної інтеграції, доставки та розгортання (CI/CD) визначаються на рівні організації, та в залежності від технічних вимог. -* Не надає сервіси на рівні застосунків як вбудовані: програмне забезпечення проміжного рівня (наприклад, шина передачі повідомлень), фреймворки обробки даних (наприклад, Spark), бази даних (наприклад, MySQL), кеш, некластерні системи збереження інформації (наприклад, Ceph). Ці компоненти можуть бути запущені у Kubernetes та/або бути доступними для застосунків за допомогою спеціальних механізмів, наприклад [Open Service Broker](https://openservicebrokerapi.org/). -* Не нав'язує використання інструментів для логування, моніторингу та сповіщень, натомість надає певні інтеграційні рішення як прототипи, та механізми зі збирання та експорту метрик. -* Не надає та не змушує використовувати якусь конфігураційну мову/систему (як наприклад `Jsonnet`), натомість надає можливість використовувати API, що може бути використаний довільними формами декларативних специфікацій. -* Не надає і не запроваджує жодних систем машинної конфігурації, підтримки, управління або самозцілення. -* На додачу, Kubernetes - не просто система оркестрації. Власне кажучи, вона усуває потребу оркестрації як такої. Технічне визначення оркестрації - це запуск визначених процесів: спочатку A, за ним B, потім C. На противагу, Kubernetes складається з певної множини незалежних, складних процесів контролерів, що безперервно опрацьовують стан у напрямку, що заданий бажаною конфігурацією. Неважливо, як ви дістанетесь з пункту A до пункту C. Централізоване управління також не є вимогою. Все це виливається в систему, яку легко використовувати, яка є потужною, надійною, стійкою та здатною до легкого розширення. - - - -## {{% heading "whatsnext" %}} - - -* Перегляньте [компоненти Kubernetes](/docs/concepts/overview/components/) -* Готові [розпочати роботу](/docs/setup/)? - diff --git a/content/uk/docs/concepts/overview/working-with-objects/_index.md b/content/uk/docs/concepts/overview/working-with-objects/_index.md new file mode 100644 index 0000000000000..8d6663c2233e9 --- /dev/null +++ b/content/uk/docs/concepts/overview/working-with-objects/_index.md @@ -0,0 +1,114 @@ +--- +title: Обʼєкти в Kubernetes +content_type: concept +weight: 10 +description: > + Обʼєкти Kubernetes є постійними сутностями в системі Kubernetes. + Kubernetes використовує ці сутності для подання стану вашого кластера. + Дізнайтеся про модель обʼєктів Kubernetes та про те, як працювати з цими обʼєктами. +simple_list: true +card: + name: concepts + weight: 40 +--- + + + +Ця сторінка пояснює, як обʼєкти Kubernetes подаються в API Kubernetes, та як ви можете описати їх у форматі `.yaml`. + + + +## Розуміння обʼєктів Kubernetes {#kubernetes-objects} + +*Обʼєкти Kubernetes* є постійними сутностями в системі Kubernetes. Kubernetes використовує ці сутності для подання стану вашого кластера. Зокрема, вони можуть описувати: + +* Які контейнеризовані застосунки працюють (і на яких вузлах) +* Ресурси, доступні для цих застосунків +* Політики щодо того, як ці застосунки поводяться, такі як політики перезапуску, оновлення та стійкості до відмов + +Обʼєкт Kubernetes є "записом про наміри" — після створення обʼєкту система Kubernetes постійно працюватиме, щоб переконатися, що обʼєкт існує. Створюючи обʼєкт, ви фактично повідомляєте системі Kubernetes, ваші побажання щодо того, як має виглядати робоче навантаження вашого кластера; це *бажаний стан* вашого кластера. + +Для роботи з обʼєктами Kubernetes — чи то для створення, зміни чи видалення — вам потрібно використовувати [API Kubernetes](/docs/concepts/overview/kubernetes-api/). Наприклад, коли ви використовуєте інтерфейс командного рядка `kubectl`, CLI виконує необхідні виклики API Kubernetes за вас. Ви також можете використовувати API Kubernetes безпосередньо у ваших власних програмах за допомогою однієї з [Клієнтських бібліотек](/docs/reference/using-api/client-libraries/). + +### Специфікація та стан обʼєкта {#object-spec-and-status} + +Майже кожен обʼєкт Kubernetes містить два вкладених поля обʼєкта, які керують конфігурацією обʼєкта: *`spec`* та *`status`* обʼєкта. Для обʼєктів, які мають `spec`, вам потрібно встановити його при створенні обʼєкта, надаючи опис характеристик, які ви хочете, щоб ресурс мав: його _бажаний стан_. + +`status` описує _поточний стан_ обʼєкта, який надається та оновлюється системою Kubernetes та її компонентами. {{< glossary_tooltip text="Control plane" term_id="control-plane" >}} Kubernetes постійно та активно керує фактичним станом кожного обʼєкта, щоб він відповідав бажаному стану, який ви вказали. + +Наприклад: в Kubernetes, Deployment є обʼєктом, який може представляти застосунок, який працює на вашому кластері. При створенні Deployment ви можете встановити `spec` Deployment, щоб вказати, що ви хочете, щоб працювало три репліки застосунку. Система Kubernetes читає `spec` Deployment та запускає три екземпляри вашого застосунку — оновлюючи `status` Deployment, щоб віддзеркалювати поточний стан розгорнення. Якщо один цих екземплярів зазнає збою (зміни стану), Kubernetes відреагує на відмінність між `spec` та `status`, створивши новий екземпляр, щоб забезпечити, щоб `status` відповідав `spec`. + +З докладнішою інформацією про spec, status та metadata обʼєктів Kubernetes звертайтесь до [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md). + +### Опис обʼєктів Kubernetes {#describing-a-kubernetes-object} + +Коли ви створюєте обʼєкт Kubernetes, ви повинні визначити spec обʼєкта, який описує бажаний стан обʼєкта, а також інші відомості про обʼєкт, наприклад його назву (name). Коли ви використовуєте API Kubernetes для створення обʼєкта, чи безпосередньо, чи за допомогою `kubectl`, цей запит до API має містити ці відомості у вигляді JSON в тілі запиту. Найчастіше інформація про обʼєкт подається `kubectl` у вигляді файлу, який називається _маніфестом_. За домовленістю, маніфести обʼєктів Kubernetes подаються у форматі YAML (ви також можете використовувати JSON). Інструменти, такі як `kubectl`, перетворюють інформацію з маніфесту у JSON або інший підтримуваний формат серіалізації надсилаючи HTTP-запити до API. + +Ось приклад маніфесту, який містить обовʼязкові поля обʼєкта та його spec для Kubernetes Deployment: + +{{% code_sample file="application/deployment.yaml" %}} + +Один зі способів створення Deployment за допомогою маніфесту, подібного до показаного вище, — використання команди [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) в інтерфейсі командного рядка `kubectl`, передаючи файл `.yaml` як аргумент. Ось так: + +```shell +kubectl apply -f https://k8s.io/examples/application/deployment.yaml +``` + +Вивід буде схожий на цей: + +```output +deployment.apps/nginx-deployment created +``` + +### Обовʼязкові поля {#required-fields} + +В маніфесті (файл YAML або JSON) обʼєкта Kubernetes, який ви хочете створити, ви повинні вказати значення для наступних обовʼязкових полів: + +* `apiVersion` — версія API Kubernetes, яку ви використовуєте для створення обʼєкта +* `kind` — тип обʼєкта, який ви хочете створити +* `metadata` — відомості про обʼєкт, які дозволяють ідентифікувати обʼєкт, включаючи рядок `name`, який вказує назву обʼєкта, `UID`, та, необовʼязково, `namespace` +* `spec` — опис бажаного стану обʼєкта + +Точний формат `spec` обʼєкта є різним для кожного типу обʼєкта в Kubernetes та містить вкладені поля, що притаманні конкретному типу обʼєкта. [Kubernetes API Reference](/docs/reference/kubernetes-api/) може допомогти знайти формати для всіх типів обʼєктів, які ви хочете створити використовуючи API Kubernetes. + +Наприклад, подивіться на [поле `spec`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) для обʼєкта Pod. Для кожного Pod, поле `.spec` вказує на Pod та його бажаний стан (наприклад, назву образу контейнера для кожного контейнера всередині цього Pod). Інший приклад специфікації обʼєкта — [поле `spec`](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec) для обʼєкта StatefulSet. Для StatefulSet, поле `.spec` вказує на StatefulSet та його бажаний стан. У `.spec` StatefulSet є [template](/docs/concepts/workloads/pods/#pod-templates) для обʼєктів Pod. Цей шаблон описує Pod, які контролер StatefulSet створить, щоб задовольнити специфікацію StatefulSet. Різні типи обʼєктів Kubernetes можуть мати різні `.status`; дивіться [Kubernetes API Reference](/docs/reference/kubernetes-api/) для отримання відомостей структуру поля `.status` та його вміст для кожного типу обʼєкта. + +{{< note >}} +[Конфігурація – найкращі практики](/docs/concepts/configuration/overview/), містить інформацію про те, як писати конфігураційні файли YAML. +{{< /note >}} + +## Перевірка полів на стороні сервера {#server-side-field-validation} + +Починаючи з Kubernetes v1.25, API сервера Kubernetes може виконувати [перевірку полів на стороні сервера](/docs/reference/using-api/api-concepts/#field-validation), що дозволяє виявляти невідомі та задвоєні поля в описі обʼєктів. Це надає функціонал `kubectl --validate` на стороні сервера. + +`kubectl` використовує прапорець `--validate` для встановлення рівня перевірки полів маніфесту. Його значенням може бути `ignore`, `warn` та `strict`, також можна вказати `true` (еквівалент `strict`) та `false` (еквівалент `ignore`). Типове значення перевірки для `kubectl` — `--validate=true`. + +`Strict` +: Сувора перевірка, повертає збій під час виявлення помилок. + +`Warn` +: Перевірка виконується, але виявлення помилок призводить до виведення попереджень, а не збою. + +`Ignore` +: Перевірка на стороні сервера не виконується. + +Якщо `kubectl` не може підʼєднатися до API сервера, він використовує локальну перевірку, яка виконується на стороні клієнта. Kubernetes v1.27 та пізніші версії завжди пропонуватимуть перевірку полів; версії до v1.27, скоріш за все — ні. Якщо версія Kubernetes на вашому кластері старіша за v1.27, звіртесь з документацією до вашої версії Kubernetes. + +## {{% heading "whatsnext" %}} + +Якщо ви тільки починаєте свій шлях з Kubernetes, дізнайтесь більше про: + +* [Podʼи](/docs/concepts/workloads/pods/) — найважливіші базові обʼєкти в Kubernetes. +* [Deployment](/docs/concepts/workloads/controllers/deployment/) — ресурс, який допомагає вам керувати наборами Podʼів. +* [Контролери](/docs/concepts/architecture/controller/) в Kubernetes. +* [kubectl](/docs/reference/kubectl/) та [команди `kubectl`](/docs/reference/generated/kubectl/kubectl-commands/). + +[Керування обʼєктами в Kubernetes](/docs/concepts/overview/working-with-objects/object-management/) надає додаткову інформацію про те, як працювати використовувати `kubectl` для керування обʼєктами. Скоріш за все вам буде потрібно [встановити `kubectl`](/docs/tasks/tools/install-kubectl/), якщо тільки ви цього ще не зробили. + +Щоб дізнатись про API Kubernetes, зверніться до: + +* [Огляд API Kubernetes](/docs/reference/using-api/) + +Якщо ви хочете дізнатись про Kubernetes більше, зверніться до інших сторінок в цьому розділі: + + diff --git a/content/uk/docs/concepts/overview/working-with-objects/annotations.md b/content/uk/docs/concepts/overview/working-with-objects/annotations.md new file mode 100644 index 0000000000000..32e3f870932ef --- /dev/null +++ b/content/uk/docs/concepts/overview/working-with-objects/annotations.md @@ -0,0 +1,80 @@ +--- +title: Анотації +content_type: concept +weight: 60 +--- + + +Ви можете використовувати анотації Kubernetes, щоб додати довільні невизначені метадані до {{< glossary_tooltip text="обʼєктів" term_id="object" >}}. +Клієнти, такі як інструменти та бібліотеки, можуть отримувати ці метадані. + + + +## Додавання метаданих до обʼєктів {#attaching-metadata-to-objects} + +Ви можете використовувати як мітки, так і анотації для додавання метаданих до обʼєктів Kubernetes. Мітки можна використовувати для вибору обʼєктів та пошуку колекцій обʼєктів, які відповідають певним умовам. На відміну від цього, анотації не використовуються для ідентифікації та вибору обʼєктів. Метадані в анотації можуть бути невеликими або великими, структурованими або неструктурованими, і можуть включати символи, які не дозволяються міткам. Можна використовувати як мітки, так і анотації в метаданих того ж самого обʼєкта. + +Анотації, подібно до міток, є парами ключ/значення: + +```json +"metadata": { + "annotations": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +{{}} +Ключі та значення в парі повинні бути рядками. Іншими словами, ви не можете використовувати числові, булеві, спискові або інші типи як для ключів, так і для їх значень. +{{}} + +Ось кілька прикладів інформації, яку можна записати в анотаціях: + +* Поля, керовані декларативним рівнем конфігурації. Додавання цих полів як анотацій відмежовує їх від типових значень, встановлених клієнтами чи серверами, а також від автогенерованих полів та полів, встановлених системами автомасштабування. + +* Інформація про збірку, реліз чи образ, така як часові мітки, ідентифікатори релізу, гілка git, номера PR, хеші образу та адреса реєстру. + +* Вказівники на репозиторії логування, моніторингу, аналітики чи аудиту. + +* Інформація про клієнтську бібліотеку чи інструмент, яку можна використовувати для налагодження: наприклад, назва, версія та інформація про збірку. + +* Інформація про походження користувача чи інструменту/системи, така як URL-адреси повʼязаних обʼєктів з інших компонентів екосистеми. + +* Метадані інструменту легкого розгортання: наприклад, конфігурація чи контрольні точки. + +* Номери телефонів або пейджерів відповідальних осіб, чи записи в каталозі, які вказують, де можна знайти цю інформацію, наприклад, на вебсайті команди. + +* Директиви від кінцевого користувача до реалізації щодо зміни поведінки чи використання нестандартних функцій. + +Замість використання анотацій, ви можете зберігати цей тип інформації у зовнішній базі даних чи каталозі, але це ускладнило б створення загальних бібліотек та інструментів для впровадження, управління, інтроспекції, та подібного. + +## Синтаксис та набір символів {#syntax-and-character-set} + +_Анотації_ — це пари ключ/значення. Допустимі ключі анотацій мають два сегменти: необовʼязковий префікс і назва, розділені косою рискою (`/`). Назва є обовʼязковою та має містити не більше 63 символів, починаючи та закінчуючись буквено-цифровим символом (`[a-z0-9A-Z]`), тире (`-`), підкресленням (`_`), крапкою (`.`) та буквено-цифровими символами між ними. Префікс є необовʼязковим. Якщо вказано, префікс повинен бути піддоменом DNS: серією DNS-міток, розділених крапками (`.`), загальною довжиною не більше 253 символів, за якою слідує коса риска (`/`). + +Якщо префікс відсутній, ключ анотації вважається приватним для користувача. Автоматизовані компоненти системи (наприклад, `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` чи інші автоматизовані засоби від сторонніх розробників), які додають анотації до обʼєктів кінцевого користувача, повинні вказати префікс. + +Префікси `kubernetes.io/` та `k8s.io/` зарезервовані для основних компонентів Kubernetes. + +Наприклад, ось маніфест для Pod, який має анотацію `imageregistry: https://hub.docker.com/`: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: annotations-demo + annotations: + imageregistry: "https://hub.docker.com/" +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + +## {{% heading "whatsnext" %}} + +* Дізнайтеся більше про [Мітки та Селектори](/docs/concepts/overview/working-with-objects/labels/). +* Подивіться [Відомі мітки, Анотації та Позначення](/docs/reference/labels-annotations-taints/) diff --git a/content/uk/docs/concepts/overview/working-with-objects/common-labels.md b/content/uk/docs/concepts/overview/working-with-objects/common-labels.md new file mode 100644 index 0000000000000..f632ff713a02b --- /dev/null +++ b/content/uk/docs/concepts/overview/working-with-objects/common-labels.md @@ -0,0 +1,156 @@ +--- +title: Рекомендовані Мітки +content_type: concept +weight: 100 +--- + + +Ви можете візуалізувати та керувати обʼєктами Kubernetes за допомогою інших інструментів, ніж kubectl та панель інструментів (dashboard). Загальний набір міток дозволяє інструментам працювати між собою, описуючи обʼєкти спільним чином, який можуть розуміти всі інструменти. + +Крім підтримки інструментів, рекомендовані мітки описують застосунки так, що до них можна звертатись. + + +Метадані організовані навколо концепції _застосунку_. Kubernetes не є платформою як сервіс (PaaS) і не має формального поняття застосунку або його виконання. Замість цього застосунки є неформальними та описуються метаданими. Визначення того, що включає застосунок, є гнучким. + +{{< note >}} +Це рекомендовані мітки. Вони полегшують управління застосунками, але не обовʼязкові для будь-яких основних інструментів. +{{< /note >}} + +Спільні мітки та анотації мають спільний префікс: `app.kubernetes.io`. Мітки без префіксу є приватними для користувачів. Спільний префікс забезпечує, що спільні мітки не втручаються у власні мітки користувача. + +## Мітки {#labels} + +Щоб повною мірою скористатися цими мітками, їх слід застосовувати до кожного обʼєкта ресурсу. + +| Ключ | Опис | Приклад | Тип | +| ----------------------------------- | --------------------- | -------- | ---- | +| `app.kubernetes.io/name` | Назва застосунку | `mysql` | рядок | +| `app.kubernetes.io/instance` | Унікальна назва, що ідентифікує екземпляр застосунку | `mysql-abcxzy` | рядок | +| `app.kubernetes.io/version` | Поточна версія застосунку (наприклад, [SemVer 1.0](https://semver.org/spec/v1.0.0.html), хеш ревізії і т.д.) | `5.7.21` | рядок | +| `app.kubernetes.io/component` | Компонент всередині архітектури | `database` | рядок | +| `app.kubernetes.io/part-of` | Назва вищого рівня застосунку, частину якого складає цей | `wordpress` | рядок | +| `app.kubernetes.io/managed-by` | Інструмент, який використовується для управління операцією застосунку | `helm` | рядок | + +Щоб проілюструвати ці мітки в дії, розгляньте наступний обʼєкт {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}: + +```yaml +# Це уривок +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/managed-by: helm +``` + +## Застосунки та екземпляри застосунків {#applications-and-application-instances} + +Застосунок можна встановити один або декілька разів в кластер Kubernetes і, у деяких випадках, в тому ж просторі імен. Наприклад, WordPress можна встановити більше одного разу, де різні вебсайти є різними екземплярами WordPress. + +Назва застосунку та назва екземпляра записуються окремо. Наприклад, у WordPress є `app.kubernetes.io/name` — `wordpress`, тоді як назва екземпляра представлена як `app.kubernetes.io/instance` зі значенням `wordpress-abcxzy`. Це дозволяє ідентифікувати застосунок та його екземпляр. Кожен екземпляр застосунку повинен мати унікальну назву. + +## Приклади {#examples} + +Щоб проілюструвати різні способи використання цих міток, наведено різні приклади складності. + +### Простий Stateless Service + +Розгляньте випадок простого Stateless Serviceʼу, розгорнутого за допомогою обʼєктів `Deployment` та `Service`. Наведені нижче два уривки представляють, як можуть бути використані мітки у їх найпростішій формі. + +`Deployment` використовується для нагляду за Podʼами, які виконують сам застосунок. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxzy +... +``` + +`Service` використовується для відкриття доступу до застосунку. + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxzy +... +``` + +### Вебзастосунок із базою даних {#web-application-with-a-database} + +Розгляньмо трохи складніший застосунок: вебзастосунок (WordPress) із базою даних (MySQL), встановлений за допомогою Helm. Наведені нижче уривки ілюструють початок обʼєктів, які використовуються для розгортання цього застосунку. + +Початок цього `Deployment` використовується для WordPress: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + +`Service` використовується для відкриття доступу до WordPress: + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxzy + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + +MySQL представлено як `StatefulSet` з метаданими як для нього, так і для застосунку, до якого він належить: + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress +... +``` + +`Service` використовується для відкриття доступу до MySQL як частини WordPress: + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxzy + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/managed-by: helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress +... +``` + +З MySQL `StatefulSet` та `Service` ви побачите, що включена інформація як про MySQL, так і про WordPress. diff --git a/content/uk/docs/concepts/overview/working-with-objects/field-selectors.md b/content/uk/docs/concepts/overview/working-with-objects/field-selectors.md new file mode 100644 index 0000000000000..ae63521b94718 --- /dev/null +++ b/content/uk/docs/concepts/overview/working-with-objects/field-selectors.md @@ -0,0 +1,62 @@ +--- +title: Селектори полів +content_type: concept +weight: 70 +--- + +_Селектори полів_ дозволяють вам вибирати обʼєкти Kubernetes на основі значень одного або кількох полів ресурсу. Ось кілька прикладів запитань для селекторів полів: + +* `metadata.name=my-service` +* `metadata.namespace!=default` +* `status.phase=Pending` + +Ця команда `kubectl` вибирає всі Podʼи, для яких значення поля [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) дорівнює `Running`: + +```shell +kubectl get pods --field-selector status.phase=Running +``` + +{{< note >}} +Селектори полів, по суті, є _фільтрами_ ресурсів. Типово селектори/фільтри не застосовуються, а це означає, що вибрані всі ресурси вказаного типу. Це робить запити kubectl `kubectl get pods` та `kubectl get pods --field-selector ""` еквівалентними. +{{< /note >}} + +## Підтримувані поля {#supported-fields} + +Підтримувані селектори полів варіюються залежно від типу ресурсу Kubernetes. Усі типи ресурсів підтримують поля `metadata.name` та `metadata.namespace`. Використання селекторів до полів, що їх не підтримують, призводить до помилки. Наприклад: + +```shell +kubectl get ingress --field-selector foo.bar=baz +``` + +```none +Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace" +``` + +## Підтримувані оператори {#supported-operators} + +Ви можете використовувати оператори `=`, `==` та `!=` з селекторами полів (`=` та `==` означають те саме). Наприклад, ця команда `kubectl` вибирає всі сервіси Kubernetes, які не знаходяться в просторі імен `default`: + +```shell +kubectl get services --all-namespaces --field-selector metadata.namespace!=default +``` + +{{< note >}} +[Оператори на основі множини](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) +(`in`, `notin`, `exists`) не підтримуються для селекторів полів. +{{< /note >}} + +## Ланцюжки селекторів {#chained-selectors} + +Як і з [мітками](/docs/concepts/overview/working-with-objects/labels) та іншими селекторами, селектори полів можна складати у список, розділений комами. Ця команда `kubectl` вибирає всі Podʼи, для яких значення `status.phase` не дорівнює `Running`, а поле `spec.restartPolicy` дорівнює `Always`: + +```shell +kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always +``` + +## Кілька типів ресурсів {#multiple-resource-types} + +Ви можете використовувати селектори полів для кількох типів ресурсів. Ця команда `kubectl` вибирає всі Statefulsets та Services, які не знаходяться в просторі імен `default`: + +```shell +kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default +``` diff --git a/content/uk/docs/concepts/overview/working-with-objects/finalizers.md b/content/uk/docs/concepts/overview/working-with-objects/finalizers.md new file mode 100644 index 0000000000000..04808d9d4fc07 --- /dev/null +++ b/content/uk/docs/concepts/overview/working-with-objects/finalizers.md @@ -0,0 +1,59 @@ +--- +title: Завершувачі +content_type: concept +weight: 80 +--- + + + +{{}} + +Ви можете використовувати завершувачі для управління {{}} з {{< glossary_tooltip text="обʼєктів" term_id="object" >}} за допомогою надсилань повідомлень {{}} з вимогою виконати певні завдання з очищення перед видаленням цільового ресурсу. + +Зазвичай завершувачі не вказують код для виконання. Замість цього вони являють собою списки ключів для конкретного ресурсу, аналогічні анотаціям. Kubernetes автоматично вказує деякі завершувачі, але ви також можете вказати свої. + +## Як працюють завершувачі {#how-finalizers-work} + +При створенні ресурсу за допомогою файлу маніфесту ви можете вказати завершувачі у полі `metadata.finalizers`. Коли ви намагаєтеся видалити ресурс, сервер API, що обробляє запит на видалення, помічає значення у полі `finalizers` і робить наступне: + +* Модифікує обʼєкт, додаючи поле `metadata.deletionTimestamp` з часом, коли ви почали видалення. +* Запобігає видаленню обʼєкта, поки всі елементи не будуть видалені з його поля `metadata.finalizers`. +* Повертає код статусу `202` (HTTP "Accepted") + +Контролер, який керує цим завершувачем, помічає оновлення обʼєкта і встановлення `metadata.deletionTimestamp`, що вказує на те, що було запрошене видалення обʼєкта. Контролер потім намагається виконати вимоги, вказані для цього ресурсу завершувачами. Кожного разу, коли виконується умова завершувача, контролер видаляє цей ключ із поля `finalizers` ресурсу. Коли поле `finalizers` порожнє, обʼєкт із встановленим полем `deletionTimestamp` автоматично видаляється. Ви також можете використовувати завершувачі для запобігання видаленню некерованих ресурсів. + +Розповсюджений приклад завершувача — `kubernetes.io/pv-protection`, який запобігає +випадковому видаленню обʼєктів `PersistentVolume`. Коли обʼєкт `PersistentVolume` +використовується у Podʼі, Kubernetes додає завершувач `pv-protection`. Якщо ви +намагаєтеся видалити `PersistentVolume`, він потрапляє в стан `Terminating`, але +контролер не може видалити його через наявність завершувача. Коли Pod перестає +використовувати `PersistentVolume`, Kubernetes очищує завершувач `pv-protection`, +і контролер видаляє обʼєкт. + +{{}} + +* Коли ви видаляєте обʼєкт за допомогою `DELETE`, Kubernetes додає відмітку видалення для цього обʼєкта і тут же починає обмежувати зміни в полі `.metadata.finalizers` для обʼєкта, який тепер очікує видалення. Ви можете видаляти наявні завершувачі (видаляти запис зі списку `finalizers`), але не можете додати новий завершувач. Ви також не можете модифікувати `deletionTimestamp` для обʼєкта, якщо він вже встановлений. + +* Після запиту на видалення ви не можете відновити цей обʼєкт. Єдиний спосіб — видалити його і створити новий схожий обʼєкт. +{{}} + +## Власники, мітки та завершувачі {#owners-labels-finalizers} + +Так само як і {{}}, [посилання на власника](/docs/concepts/overview/working-with-objects/owners-dependents/) описують стосунки між обʼєктами в Kubernetes, але використовуються для іншої цілі. Коли {{}} керує обʼєктами типу Pod, він використовує мітки для відстеження змін у групах повʼязаних обʼєктів. Наприклад, коли {{}} створює один чи +декілька Podʼів, контролер Завдання додає мітки до цих Podʼів та відстежує зміни +у будь-яких Podʼах у кластері з такою ж міткою. + +Контролер Завдання також додає *посилання на власника* до цих Podʼів, посилаючись на Завдання, яке створило Podʼи. Якщо ви видаляєте Завдання, поки ці Podʼи працюють, Kubernetes використовує посилання на власника (а не мітки), щоб визначити, які Podʼи в кластері потрібно прибрати. + +Kubernetes також обробляє завершувачі, коли визначає посилання на власника ресурсу, призначене для видалення. + +У деяких ситуаціях завершувачі можуть блокувати видалення залежних обʼєктів, що може призвести до того, що цільовий обʼєкт-власник залишиться довше, ніж очікувалося, не буде повністю видалений. У таких ситуаціях вам слід перевірити завершувачі та посилання на власника, на цільового власника та залежні +обʼєкти для усунення несправностей. + +{{}} +У випадках, коли обʼєкти застрягають в стані видалення, уникайте ручного видалення завершувачів для продовження процесу видалення. Завершувачі, як правило, додаються до ресурсів з певною метою, тому примусове їх видалення може призвести до проблем у вашому кластері. Це слід робити лише тоді, коли призначення завершувача зрозуміло та може бути виконано іншим способом (наприклад, ручне очищення деякого залежного обʼєкта). +{{}} + +## {{% heading "whatsnext" %}} + +* Прочитайте [Using Finalizers to Control Deletion](/blog/2021/05/14/using-finalizers-to-control-deletion/) в блозі Kubernetes. diff --git a/content/uk/docs/concepts/overview/working-with-objects/labels.md b/content/uk/docs/concepts/overview/working-with-objects/labels.md new file mode 100644 index 0000000000000..5b3dab06d2561 --- /dev/null +++ b/content/uk/docs/concepts/overview/working-with-objects/labels.md @@ -0,0 +1,323 @@ +--- +reviewers: +- mikedanese +title: Мітки та Селектори +content_type: Концепція +weight: 40 +--- + + + +_Мітки_ — це пари ключ/значення, які прикріплені до {{< glossary_tooltip text="обʼєктів" term_id="object" >}}, таких як Pod. Мітки призначені для використання для вказівки визначних атрибутів обʼєктів, які мають значення та стосуються користувачів, але безпосередньо не вбачають семантику для основної системи. Мітки можуть бути використані для організації та вибору підмножини обʼєктів. Мітки можуть бути прикріплені до обʼєктів при їх створенні та пізніше додані та змінені в будь-який час. Кожен обʼєкт може мати набір унікальних міток ключ/значення. Кожен ключ повинен бути унікальним для даного обʼєкта. + +```json +"metadata": { + "labels": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +Мітки дозволяють є ефективними для запитів та спостережень та є ідеальними для використання в інтерфейсах користувача та інтерфейсах командного рядка. Інформацію, що не є ідентифікуючою, слід записувати за допомогою [анотацій](/docs/concepts/overview/working-with-objects/annotations/). + + + +## Мотивація {#motivation} + +Мітки дозволяють користувачам звʼязувати свої власні організаційні структури з обʼєктами системи у вільний спосіб, не вимагаючи зберігання цих звʼязків в клієнтах. + +Розгортання Service та конвеєрів обробки пакетів часто є багатомірними сутностями (наприклад, кілька розділів чи розгортань, кілька шляхів релізів, кілька рівнів, кілька мікросервісів на кожному рівні). Управління часто потребує наскрізних операцій, які порушують інкапсуляцію строго ієрархічних уявлень, особливо жорстких ієрархій, визначених інфраструктурою, а не користувачами. + +Приклади міток: + +* `"release" : "stable"`, `"release" : "canary"` +* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` +* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` +* `"partition" : "customerA"`, `"partition" : "customerB"` +* `"track" : "daily"`, `"track" : "weekly"` + +Це приклади [загальновживаних міток](/docs/concepts/overview/working-with-objects/common-labels/); ви вільні розробляти свої власні домовленості. Памʼятайте, що ключ мітки повинен бути унікальним для даного обʼєкта. + +## Синтаксис та набір символів {#syntax-and-character-set} + +_Мітки_ — це пари ключ/значення. Дійсні ключі міток мають два сегменти: необовʼязковий префікс та назву, розділені слешем (`/`). Сегмент назви є обовʼязковим і має бути не більше 63 символів, починатися та закінчуватися буквено-цифровим символом (`[a-z0-9A-Z]`) з дефісами (`-`), підкресленнями (`_`), крапками (`.`), та буквено-цифровими символами між ними. Префікс є необовʼязковим. Якщо вказаний, префікс повинен бути піддоменом DNS: серією DNS-міток, розділених крапками (`.`), не довше 253 символів загалом, за яким слідує слеш (`/`). + +Якщо префікс відсутній, ключ мітки вважається приватним для користувача. Автоматизовані компоненти системи (наприклад, `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, або інші засоби автоматизації від інших сторін), які додають мітки до обʼєктів користувача, повинні вказати префікс. + +Префікси `kubernetes.io/` та `k8s.io/` є [зарезервованими](/docs/reference/labels-annotations-taints/) для основних компонентів Kubernetes. + +Дійсне значення мітки: + +* повинно бути не більше 63 символів (може бути порожнім), +* крім порожнього значення, повинно починатися та закінчуватися буквено-цифровим символом (`[a-z0-9A-Z]`), +* може містити дефіси (`-`), підкреслення (`_`), крапки (`.`), та буквено-цифрові символи між ними. + +Наприклад, ось маніфест для Pod із двома мітками `environment: production` та `app: nginx`: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: label-demo + labels: + environment: production + app: nginx +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + +## Селектори міток {#label-selectors} + +На відміну від [назв та UID](/docs/concepts/overview/working-with-objects/names/), мітки не забезпечують унікальності. Загалом, ми очікуємо, що багато обʼєктів матимуть ті ж самі мітки. + +За допомогою _селектора міток_ користувач може ідентифікувати набір обʼєктів. Селектор міток є основним примітивом гуртування в Kubernetes. + +На цей момент API підтримує два типи селекторів: _equality-based_ та _set-based_. Селектор міток може складатися з кількох _вимог_, які розділені комами. У випадку кількох вимог всі повинні бути задоволені, таким чином кома виступає логічним +оператором _AND_ (`&&`). + +{{< note >}} +Для деяких типів API, таких як ReplicaSets, селектори міток двох екземплярів не повинні перетинатися в одному просторі імен, бо контролер може вважати це конфліктною інструкцією та не визначити, скільки реплік повинно бути присутньо. +{{< /note >}} + +{{< caution >}} +Для умов на основі рівності і на основі множини немає логічного оператора _OR_ (`||`). Переконайтеся, що ваші вирази фільтрації структуровані відповідно. +{{< /caution >}} + +### _Equality-based_ вимоги {#equality-based-requirement} + +Вимоги _Equality-_ чи _inequality-based_ дозволяють фільтрувати обʼєкти за ключами та значеннями міток. Відповідні обʼєкти повинні задовольняти всі вказані обмеження міток, хоча вони можуть мати додаткові мітки також. Допускаються три види операторів: `=`, `==`, `!=`. Перший та другий представляють _рівність_ (_equality_) і є синонімами, тоді як останній представляє _нерівність_ (_inequality_). +Наприклад: + +```ini +environment = production +tier != frontend +``` + +Перший вибирає всі ресурси з ключем `environment` та значенням `production`. Другий вибирає всі ресурси з ключем `tier` та значеннями відмінним від `frontend`, та всі ресурси без міток з ключем `tier`. Можна використовувати оператор коми для фільтрації ресурсів у `production`, іншими словами, `environment=production,tier!=frontend`. + +Один зі сценаріїв використання вимог на основі рівності використовується для Podʼів, які вказують критерії вибору вузлів. Наприклад, зразок Pod нижче вибирає вузли з міткою "`accelerator=nvidia-tesla-p100`". + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-test +spec: + containers: + - name: cuda-test + image: "registry.k8s.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 +``` + +### _Set-based_ вимоги {#set-based-requirements} + +Вимоги на основі множини дозволяють фільтрувати ключі за набором значень. Підтримуються три види операторів: `in`, `notin` та `exists` (тільки ідентифікатор ключа). Наприклад: + +```ini +environment in (production, qa) +tier notin (frontend, backend) +partition +!partition +``` + +* Перший приклад вибирає всі ресурси з ключем, рівним `environment` та значенням + рівним `production` або `qa`. +* Другий приклад вибирає всі ресурси з ключем, рівним `tier` та значеннями іншими + ніж `frontend` та `backend`, та всі ресурси без міток з ключем `tier`. +* Третій приклад вибирає всі ресурси, включаючи мітку з ключем `partition`; + значення не перевіряються. +* Четвертий приклад вибирає всі ресурси без мітки з ключем `partition`; + значення не перевіряються. + +Так само розділювач коми діє як _AND_ оператор. Таким чином, фільтрування ресурсів з ключем `partition` (без значення) та з `environment` відмінним від `qa` може бути досягнуто за допомогою `partition,environment notin (qa)`. Вимоги на основі множини є загальною формою вимог на основі рівності, оскільки `environment=production` еквівалентно `environment in (production)`; так само для `!=` та `notin`. + +Вимоги на основі множини можна комбінувати з вимогами на основі рівності. Наприклад: `partition in (customerA, customerB),environment!=qa`. + +## API + +### Фільтрація LIST та WATCH {#list-and-watch-filtering} + +Операції LIST та WATCH можуть вказати селектори міток для фільтрації наборів обʼєктів за допомогою параметра запиту. Дозволені обидві вимоги (представлені тут так, як вони з'являтимуться в рядку запиту URL): + +* вимоги на основі рівності: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` +* вимоги на основі множини: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` + +Обидва стилі селекторів міток можуть бути використані для переліку чи перегляду ресурсів через клієнта REST. Наприклад, спрямовуючись до `apiserver` за допомогою `kubectl` та використовуючи вимогу на основі рівності, можна написати: + +```shell +kubectl get pods -l environment=production,tier=frontend +``` + +чи використовуючи вимогу на основі множини: + +```shell +kubectl get pods -l 'environment in (production),tier in (frontend)' +``` + +Як вже зазначалося, вимоги на основі множини є більш виразними. Наприклад, вони можуть реалізувати оператор _OR_ в значеннях: + +```shell +kubectl get pods -l 'environment in (production, qa)' +``` + +чи обмежувати відʼємний збіг за допомогою оператора _notin_: + +```shell +kubectl get pods -l 'environment,environment notin (frontend)' +``` + +### Посилання в API-обʼєктах {#set-reference-in-api-objects} + +Деякі обʼєкти Kubernetes, такі як [`services`](/docs/concepts/services-networking/service/) та [`replicationcontrollers`](/docs/concepts/workloads/controllers/replicationcontroller/), також використовують селектори міток для вказівки наборів інших ресурсів, таких як [Podʼи](/docs/concepts/workloads/pods/). + +#### Service та ReplicationController {#service-and-replicationcontroller} + +Множина Podʼів, яку `service` вибирає, визначається селектором міток. Так само, популяція Podʼів, якою `replicationcontroller` повинен керувати, +також визначається селектором міток. + +Селектори міток для обох обʼєктів визначаються в файлах `json` або `yaml` за допомогою звʼязування та підтримуються лише _equality-based_ селектори: + +```json +"selector": { + "component" : "redis", +} +``` + +або + +```yaml +selector: + component: redis +``` + +Цей селектор (відповідно у форматі `json` або `yaml`) еквівалентний `component=redis` або `component in (redis)`. + +#### Ресурси, які підтримують вимоги на основі множин {#resources-that-support-set-based-requirements} + +Нові ресурси, такі як [`Job`](/docs/concepts/workloads/controllers/job/), [`Deployment`](/docs/concepts/workloads/controllers/deployment/), [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/), та [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/), також підтримують вимоги на основі множин. + +```yaml +selector: + matchLabels: + component: redis + matchExpressions: + - { key: tier, operator: In, values: [cache] } + - { key: environment, operator: NotIn, values: [dev] } +``` + +`matchLabels` — це звʼязування з парами `{key,value}`. Одна пара `{key,value}` у +звʼязці `matchLabels` еквівалентна елементу `matchExpressions`, де поле `key` — це "key", оператор — "In", а масив `values` містить лише "value". `matchExpressions` - це список вимог селектора для вибору Podʼів. Допустимі оператори включають In, NotIn, Exists, та DoesNotExist. Масив values повинен бути непорожнім у випадку In та NotIn. Всі вимоги, як з `matchLabels`, так і з `matchExpressions`, йдуть разом +з логічною операцією AND — всі вони повинні бути задоволені для збігу. + +#### Вибір множини вузлів {#selecting-sets-of-nodes} + +Одним з варіантів використання селекторів на мітках є обмеження множини вузлів, на які може бути заплановано Pod. Дивіться документацію щодо [вибору вузла](/docs/concepts/scheduling-eviction/assign-pod-node/) для отримання докладнішої інформації. + +## Ефективне використання міток {#using-labels-effectively} + +Ви можете застосовувати одну мітку до будь-яких ресурсів, але це не завжди є найкращою практикою. Є багато сценаріїв, де слід використовувати кілька міток для розрізнення наборів ресурсів один від одного. + +Наприклад, різні застосунки можуть використовувати різні значення для мітки `app`, +але багаторівневий застосунок, такий як [приклад гостьової книги](https://github.com/kubernetes/examples/tree/master/guestbook/), додатково повинен відрізняти кожний рівень. Фронтенд може мати наступні мітки: + +```yaml +labels: + app: guestbook + tier: frontend +``` + +тоді як Redis master та replica можуть мати різні мітки `tier`, і, можливо, навіть +додаткову мітку `role`: + +```yaml +labels: + app: guestbook + tier: backend + role: master +``` + +та + +```yaml +labels: + app: guestbook + tier: backend + role: replica +``` + +Мітки дозволяють розрізняти ресурси по будь-якому виміру, зазначеному міткою: + +```shell +kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml +kubectl get pods -Lapp -Ltier -Lrole +``` + +```none +NAME READY STATUS RESTARTS AGE APP TIER ROLE +guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend +guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend +guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend +guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master +guestbook-redis-replica-2q2yf 1/1 Running 0 1m guestbook backend replica +guestbook-redis-replica-qgazl 1/1 Running 0 1m guestbook backend replica +my-nginx-divi2 1/1 Running 0 29m nginx +my-nginx-o0ef1 1/1 Running 0 29m nginx +``` + +```shell +kubectl get pods -lapp=guestbook,role=replica +``` + +```none +NAME READY STATUS RESTARTS AGE +guestbook-redis-replica-2q2yf 1/1 Running 0 3m +guestbook-redis-replica-qgazl 1/1 Running 0 3m +``` + +## Оновлення міток {#updating-labels} + +Іноді вам може знадобитися переозначити наявні Podʼи та інші ресурси перед створенням нових ресурсів. Це можна зробити за допомогою `kubectl label`. Наприклад, якщо ви хочете позначити всі свої NGINX Podʼи як рівень фронтенду, виконайте: + +```shell +kubectl label pods -l app=nginx tier=fe +``` + +```none +pod/my-nginx-2035384211-j5fhi labeled +pod/my-nginx-2035384211-u2c7e labeled +pod/my-nginx-2035384211-u3t6x labeled +``` + +Спочатку фільтруються всі Podʼи з міткою "app=nginx", а потім вони позначаються як "tier=fe". Щоб переглянути Podʼи, які ви позначили, виконайте: + +```shell +kubectl get pods -l app=nginx -L tier +``` + +```none +NAME READY STATUS RESTARTS AGE TIER +my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe +my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe +my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe +``` + +Це виводить всі Podʼи "app=nginx", з додатковим стовпчиком міток рівня Podʼів (вказаним за допомогою `-L` або `--label-columns`). + +Для отримання додаткової інформації, будь ласка, див. [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label). + +## {{% heading "whatsnext" %}} + +* Дізнайтеся, як [додати мітку до вузла](/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node) +* Знайдіть [Відомі мітки, Анотації та Ознаки](/docs/reference/labels-annotations-taints/) +* Перегляньте [Рекомендовані мітки](/docs/concepts/overview/working-with-objects/common-labels/) +* [Застосовуйте стандарти безпеки для Podʼів з мітками простору імен](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) +* Прочитайте блог про [Написання контролера для міток Podʼу](/blog/2021/06/21/writing-a-controller-for-pod-labels/) diff --git a/content/uk/docs/concepts/overview/working-with-objects/names.md b/content/uk/docs/concepts/overview/working-with-objects/names.md new file mode 100644 index 0000000000000..64862b7538459 --- /dev/null +++ b/content/uk/docs/concepts/overview/working-with-objects/names.md @@ -0,0 +1,97 @@ +--- +reviewers: +- mikedanese +- thockin +title: Назви та Ідентифікатори Обʼєктів +content_type: Концепція +weight: 30 +--- + + + +Кожен {{< glossary_tooltip text="обʼєкт" term_id="object" >}} у вашому кластері має [_Назву_](#names), яка є унікальною для цього типу ресурсу. Кожен обʼєкт Kubernetes також має [_UID_](#uids), який є унікальним в усьому вашому кластеру. + +Наприклад, ви можете мати лише один обʼєкт Pod із назвою `myapp-1234` в [просторі імен](/docs/concepts/overview/working-with-objects/namespaces/) з такою ж назвою, а також ви можете мати один обʼєкт Pod та один Deployment із назвами `myapp-1234` кожен. + +Для неунікальних атрибутів, наданих користувачем, Kubernetes надає [мітки (labels)](/docs/concepts/overview/working-with-objects/labels/) та [анотації (annotations)](/docs/concepts/overview/working-with-objects/annotations/). + + + +## Назви {#names} + +{{< glossary_definition term_id="name" length="all" >}} + +**Назви повинні бути унікальними між усіма [версіями API](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) того ж самого ресурсу. Ресурси API відрізняються своєю API-групою, типом ресурсу, простором імен (для ресурсів із просторами імен) та назвою. Іншими словами, версія API не має значення в цьому контексті.** + +{{< note >}} +У випадках, коли обʼєкти представляють фізичний обʼєкт, наприклад, Node, що представляє фізичний хост, коли хост перестворюється з тією ж самою назвою без видалення та перестворення Node, Kubernetes розглядає новий хост як старий, що може призвести до неузгодженостей. +{{< /note >}} + +Нижче наведено чотири типи обмежень на назви ресурсів, які часто використовуються. + +### Назви DNS-піддоменів {#dns-subdomain-names} + +Більшість типів ресурсів потребують назви, яку можна використовувати як DNS-піддомен згідно з [RFC 1123](https://tools.ietf.org/html/rfc1123). Це означає, що назва повинна: + +- містити не більше 253 символів +- містити лише буквено-цифрові символи, '-' чи '.' в нижньому регістрі +- починатися буквено-цифровим символом +- закінчуватися буквено-цифровим символом + +### Назви міток RFC 1123 {#dns-label-names} + +Деякі типи ресурсів вимагають, щоб їх назви відповідали стандарту DNS як визначено в [RFC 1123](https://tools.ietf.org/html/rfc1123). Це означає, що назва повинна: + +- містити не більше 63 символів +- містити лише буквено-цифрові символи чи '-' в нижньому регістрі +- починатися буквено-цифровим символом +- закінчуватися буквено-цифровим символом + +### Назви міток RFC 1035 {#rfc-1035-label-names} + +Деякі типи ресурсів вимагають, щоб їх назви відповідали стандарту DNS як визначено в [RFC 1035](https://tools.ietf.org/html/rfc1035). Це означає, що назва повинна: + +- містити не більше 63 символів +- містити лише буквено-цифрові символи чи '-' в нижньому регістрі +- починатися алфавітним символом +- закінчуватися буквено-цифровим символом + +{{< note >}} +Єдина відмінність між стандартами RFC 1035 та RFC 1123 полягає у тому, що мітки RFC 1123 можуть починатися з цифри, тоді як мітки RFC 1035 можуть починатися +лише з літери алфавіту в нижньому регістрі. +{{< /note >}} + +### Назви сегментів шляху {#path-segment-names} + +Деякі типи ресурсів вимагають, щоб їх назви можна було безпечно кодувати як сегмент шляху. Іншими словами, назва не може бути "." або "..", і вона не може +містити "/" або "%". + +Ось приклад маніфесту для Pod із назвою `nginx-demo`. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx-demo +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + +{{< note >}} +Деякі типи ресурсів мають додаткові обмеження на їх назви. +{{< /note >}} + +## UID + +{{< glossary_definition term_id="uid" length="all" >}} + +UID Kubernetes — це унікальні ідентифікатори, також відомі як UUID (узгоджені універсальні ідентифікатори). UUID стандартизовані згідно з ISO/IEC 9834-8 та ITU-T X.667. + +## {{% heading "whatsnext" %}} + +- Дізнайтеся більше про [мітки (labels)](/docs/concepts/overview/working-with-objects/labels/) та [анотації (annotations)](/docs/concepts/overview/working-with-objects/annotations/) в Kubernetes. +- Перегляньте документ [Ідентифікатори та Назви в Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md). diff --git a/content/uk/docs/concepts/overview/working-with-objects/namespaces.md b/content/uk/docs/concepts/overview/working-with-objects/namespaces.md new file mode 100644 index 0000000000000..16fbc2918b842 --- /dev/null +++ b/content/uk/docs/concepts/overview/working-with-objects/namespaces.md @@ -0,0 +1,132 @@ +--- +reviewers: +- derekwaynecarr +- mikedanese +- thockin +title: Простори імен +aka: + - Namespaces +content_type: concept +weight: 45 +--- + + + +В Kubernetes _простори імен_ (_namespaces_) забезпечують механізм для ізоляції груп ресурсів в межах одного кластера. Імена ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Засноване на просторах імен обмеження застосовується лише до {{< glossary_tooltip text="обʼєктів" term_id="object" >}}, які входять до простору імен _(наприклад, Deployments, Services тощо)_, а не до обʼєктів, що поширюються на весь кластер _(наприклад, StorageClass, Вузли, PersistentVolumes тощо)_. + + + +## Коли використовувати кілька просторів імен {#when-to-use-multiple-namespaces} + +Простори імен призначені для використання в середовищах з багатьма користувачами, розподіленими в різні команди чи проєкти. Для кластерів з кількома десятками користувачів вам, ймовірно, не потрібно створювати або думати про простори імен. Почніть використовувати простори імен, коли ви потребуєте функції, які вони забезпечують. + +Простори імен визначають область імен. Назви ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Простори імен не можуть бути вкладені один в одного, і кожен ресурс Kubernetes може бути лише в одному просторі імен. + +Простори імен — це спосіб розділити ресурси кластера між кількома користувачами (за допомогою [квот ресурсів](/docs/concepts/policy/resource-quotas/)). + +Не обовʼязково використовувати кілька просторів імен для відокремлення трохи відмінних ресурсів, таких як різні версії одного й того ж програмного забезпечення: використовуйте {{< glossary_tooltip text="мітки" term_id="label" >}} для розрізнення ресурсів в межах одного простору імен. + +{{< note >}} +Для промислового кластера розгляньте можливість _не_ використовувати простір імен `default`. Замість цього створюйте і використовуйте інші простори імен. +{{< /note >}} + +## Початкові простори імен {#initial-namespaces} + +Після запуску в Kubernetes є чотирьох початкових простори імен: + +`default` +: Kubernetes включає цей простір імен, щоб ви могли почати використовувати новий кластер без попереднього створення простору імен. + +`kube-node-lease` +: Цей простір імен містить обʼєкти [Оренди](/docs/concepts/architecture/leases/), повʼязані з кожним вузлом. Обʼєкти оренди дозволяють kubelet відправляти [імпульси](/docs/concepts/architecture/nodes/#heartbeats), щоб панель управління могла виявити відмову вузла. + +`kube-public` +: Цей простір імен може бути прочитаний _усіма_ клієнтами (включаючи тих, які не автентифіковані). Цей простір імен в основному призначений для внутрішнього використання кластером, у випадку, коли деякі ресурси повинні бути видимими та доступними публічно по всьому кластеру. Публічний аспект цього простору імен — це лише домовленість, яка не є обовʼязковою. + +`kube-system` +: Простір імен для обʼєктів, створених системою Kubernetes. + +## Робота з просторами імен {#working-with-namespaces} + +Створення та видалення просторів імен описано в [документації з адміністрування просторів імен](/docs/tasks/administer-cluster/namespaces). + +{{< note >}} + Уникайте створення просторів імен із префіксом `kube-`, оскільки він зарезервований для системних просторів імен Kubernetes. +{{< /note >}} + +### Перегляд просторів імен {#viewing-namespaces} + +Ви можете переглянути поточні простори імен у кластері за допомогою: + +```shell +kubectl get namespace +``` + +```none +NAME STATUS AGE +default Active 1d +kube-node-lease Active 1d +kube-public Active 1d +kube-system Active 1d +``` + +### Встановлення простору імен для запиту {#setting-the-namespace-for-a-request} + +Щоб встановити простір імен для поточного запиту, використовуйте прапорець `--namespace`. + +Наприклад: + +```shell +kubectl run nginx --image=nginx --namespace= +kubectl get pods --namespace= +``` + +### Встановлення обраного простору імен {#setting-the-namespace-preference} + +Ви можете постійно зберігати простір імен для всіх подальших команд kubectl в даному +контексті. + +```shell +kubectl config set-context --current --namespace= +# Перевірте його +kubectl config view --minify | grep namespace: +``` + +## Простори імен та DNS {#namespaces-and-dns} + +При створенні [Service](/docs/concepts/services-networking/service/), створюється відповідний [DNS запис](/docs/concepts/services-networking/dns-pod-service/). Цей запис має форму `..svc.cluster.local`, що означає, +що якщо контейнер використовує тільки ``, він буде звертатись до сервісу, який є локальним для простору імен. Це корисно для використання одного і того ж конфігураційного файлу в кількох просторах імен, таких як Development, Staging та Production. Якщо вам потрібно досягти обʼєкта в іншому просторі імен, вам слід використовувати повне кваліфіковане доменне імʼя (FQDN). + +Отже, всі імена просторів імен повинні бути дійсними +[DNS-мітками згідно RFC 1123](/docs/concepts/overview/working-with-objects/names/#dns-label-names). + +{{< warning >}} +Створюючи простори імен із тими ж назвами, що і [публічні домени верхнього рівня (TLD)](https://data.iana.org/TLD/tlds-alpha-by-domain.txt), Serviceʼи в цих просторах імен можуть мати короткі імена DNS, які перетинаються з публічними записами DNS. Завдання з будь-якого простору імен, яке виконує DNS-запит без [крапки в кінці](https://datatracker.ietf.org/doc/html/rfc1034#page-8) буде перенаправлено на ці сервіси, отримуючи перевагу над публічним DNS. + +Для помʼякшення цього обмеження скоротіть привілеї для створення просторів імен довіреним користувачам. Якщо необхідно, ви можете додатково налаштувати сторонні перевірки на забезпечення безпеки, такі як [обробники доступу](/docs/reference/access-authn-authz/extensible-admission-controllers/), щоб блокувати створення будь-якого простору імен з іменем [публічних TLD](https://data.iana.org/TLD/tlds-alpha-by-domain.txt). +{{< /warning >}} + +## Не всі обʼєкти мають простори імен {#not-all-objects-are-in-a-namespace} + +Більшість ресурсів Kubernetes (наприклад, pods, services, replication controllers та інші) є в деяких просторах імен. Однак ресурси простору імен самі не перебувають в просторі імен. І ресурси низького рівня, такі як [nodes](/docs/concepts/architecture/nodes/) та [persistentVolumes](/docs/concepts/storage/persistent-volumes/), не перебувають в жодному просторі імен. + +Щоб переглянути, які ресурси Kubernetes є в просторі імен, а які — ні: + +```shell +# В просторі імен +kubectl api-resources --namespaced=true + +# Не в просторі імен +kubectl api-resources --namespaced=false +``` + +## Автоматичне маркування {#automatic-labeling} + +{{< feature-state for_k8s_version="1.22" state="stable" >}} + +Панель управління Kubernetes встановлює незмінювану {{< glossary_tooltip text="мітку" term_id="label" >}} `kubernetes.io/metadata.name` для всіх просторів імен. Значення мітки — це назва простору імен. + +## {{% heading "whatsnext" %}} + +* Дізнайтеся більше про [створення нового простору імен](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). +* Дізнайтеся більше про [видалення простору імен](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace). diff --git a/content/uk/docs/concepts/overview/working-with-objects/object-management.md b/content/uk/docs/concepts/overview/working-with-objects/object-management.md new file mode 100644 index 0000000000000..2dc3727b73808 --- /dev/null +++ b/content/uk/docs/concepts/overview/working-with-objects/object-management.md @@ -0,0 +1,149 @@ +--- +title: Управління обʼєктами Kubernetes +content_type: concept +weight: 20 +--- + + +Інструмент командного рядка `kubectl` підтримує кілька різних способів створення та управління {{< glossary_tooltip text="обʼєктами" term_id="object" >}} Kubernetes. Цей документ надає огляд різних підходів. Для отримання деталей щодо управління обʼєктами за допомогою Kubectl читайте [Книгу Kubectl](https://kubectl.docs.kubernetes.io). + + + +## Техніки управління {#management-techniques} + +{{< warning >}} +Обʼєкт Kubernetes повинен управлятися лише з використанням однієї техніки. Змішування різних технік для того самого обʼєкта призводить до невизначеної поведінки. +{{< /warning >}} + +| Техніка управління | Діє на | Рекомендоване середовище | Підтримувані інструменти | Крива навчання | +|----------------------------------|----------------------|------------------------|--------------------------|----------------| +| Імперативні команди | Живі обʼєкти | Проєкти розробки | 1+ | Налегша | +| Імперативна конфігурація обʼєктів| Окремі файли | Продуктові проєкти | 1 | Середня | +| Декларативна конфігурація обʼєктів| Теки файлів | Продуктові проєкти | 1+ | Найскладніша | + +## Імперативні команди {#imperative-commands} + +При використанні імперативних команд користувач працює безпосередньо з живими обʼєктами в кластері. Користувач надає операції команді `kubectl` у вигляді аргументів чи прапорців. + +Це рекомендований спосіб початку роботи або виконання одноразового завдання в кластері. Оскільки цей метод працює безпосередньо з живими обʼєктами, він не зберігає жодної історичної конфігурації. + +### Приклади {#examples} + +Запустіть екземпляр контейнера nginx, створивши обʼєкт розгортання (Deployment): + +```sh +kubectl create deployment nginx --image nginx +``` + +### Компроміси {#trade-offs} + +Переваги порівняно із конфігуруванням обʼєктів: + +- Команди виражені як одне слово дії. +- Команди вимагають лише одного кроку для внесення змін до кластера. + +Недоліки порівняно із конфігуруванням обʼєктів: + +- Команди не інтегруються з процесами перегляду змін. +- Команди не надають логів аудиту, повʼязаних зі змінами. +- Команди не надають джерела записів, окрім того, що є на живому сервері. +- Команди не надають шаблону для створення нових обʼєктів. + +## Імперативне конфігурування обʼєктів {#imperative-object-configuration} + +У імперативній конфігурації обʼєктів команда `kubectl` вказує операцію (створити, замінити інше), необовʼязкові прапорці та принаймні одне імʼя файлу. Зазначений файл повинен містити повне визначення обʼєкта у форматі YAML або JSON. + +Див. [API-довідник](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) для отримання докладніших відомостей щодо визначення обʼєктів. + +{{< warning >}} +Імперативна команда `replace` замінює поточну специфікацію на нову, вилучаючи всі зміни обʼєкта, які відсутні в файлі конфігурації. Цей підхід не повинен використовуватися із типами ресурсів, специфікації яких оновлюються незалежно від файлу конфігурації. Наприклад, у служб типу `LoadBalancer` поле `externalIPs` оновлюється незалежно від конфігурації кластера. +{{< /warning >}} + +### Приклади {#examples-1} + +Створити обʼєкти, визначені у файлі конфігурації: + +```sh +kubectl create -f nginx.yaml +``` + +Видалити обʼєкти, визначені у двох файлах конфігурації: + +```sh +kubectl delete -f nginx.yaml -f redis.yaml +``` + +Оновити обʼєкти, визначені у файлі конфігурації, перезаписавши живу конфігурацію: + +```sh +kubectl replace -f nginx.yaml +``` + +### Компроміси {#trade-offs-1} + +Переваги порівняно з імперативними командами: + +- Конфігурація обʼєктів може зберігатися у системі контролю версій, такій як Git. +- Конфігурація обʼєктів може інтегруватися з процесами, такими як перегляд змін перед публікацією та аудитом. +- Конфігурація обʼєктів надає шаблон для створення нових обʼєктів. + +Недоліки порівняно з імперативними командами: + +- Конфігурація обʼєктів потребує базового розуміння схеми обʼєкта. +- Конфігурація обʼєктів потребує додаткового кроку у вигляді написання файлу YAML. + +Переваги порівняно із декларативною конфігурацією обʼєктів: + +- Поведінка імперативної конфігурації обʼєктів простіша та її легше зрозуміти. +- З версії Kubernetes 1.5 імперативна конфігурація обʼєктів більш зріла. + +Недоліки порівняно із декларативною конфігурацією обʼєктів: + +- Імперативна конфігурація обʼєктів працює краще з файлами, а не з теками. +- Оновлення живих обʼєктів повинно відображатися у файлах конфігурації, або вони будуть втрачені під час наступної заміни. + +## Декларативна конфігурація обʼєктів {#declarative-object-configuration} + +При використанні декларативної конфігурації обʼєктів користувач працює з конфігураційними файлами обʼєктів, збереженими локально, проте користувач не визначає операції, які слід виконати над файлами. Операції створення, оновлення та видалення автоматично визначаються для кожного обʼєкта за допомогою `kubectl`. Це дозволяє працювати з теками, де для різних обʼєктів можуть бути потрібні різні операції. + +{{< note >}} +Декларативна конфігурація обʼєктів зберігає зміни, внесені іншими учасниками, навіть якщо зміни не зливаються назад у файл конфігурації обʼєкта. Це можливо за допомогою використання операції API `patch` для запису тільки спостережуваних відмінностей, замість використання операції `replace` для заміни всього файлу конфігурації обʼєкта. +{{< /note >}} + +### Приклади {#examples-2} + +Обробити всі файли конфігурації обʼєктів у каталозі `configs` та створити або внести патчі до живих обʼєктів. Спочатку ви можете використовувати `diff`, щоб побачити, які зміни будуть внесені, а потім застосовувати: + +```sh +kubectl diff -f configs/ +kubectl apply -f configs/ +``` + +Рекурсивно обробити теки: + +```sh +kubectl diff -R -f configs/ +kubectl apply -R -f configs/ +``` + +### Компроміси {#trade-offs-2} + +Переваги порівняно з імперативною конфігурацією обʼєктів: + +- Зміни, внесені безпосередньо в живі обʼєкти, зберігаються, навіть якщо вони не зливаються назад у файли конфігурації. +- Декларативна конфігурація обʼєктів краще підтримує роботу з теками та автоматично визначає типи операцій (створення, патч, видалення) для кожного обʼєкта. + +Недоліки порівняно з імперативною конфігурацією обʼєктів: + +- Декларативна конфігурація обʼєктів важко налагоджувати, і результати її роботи важко зрозуміти, коли вони несподівані. +- Часткові оновлення за допомогою відміток створюють складні операції злиття та накладання патчів. + +## {{% heading "whatsnext" %}} + +- [Управління обʼєктами Kubernetes за допомогою імперативних команд](/docs/tasks/manage-kubernetes-objects/imperative-command/) +- [Імперативне управління обʼєктами Kubernetes за допомогою файлів конфігурації](/docs/tasks/manage-kubernetes-objects/imperative-config/) +- [Декларативне управління обʼєктами Kubernetes за допомогою файлів конфігурації](/docs/tasks/manage-kubernetes-objects/declarative-config/) +- [Декларативне управління обʼєктами Kubernetes за допомогою Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/) +- [Довідник команд Kubectl](/docs/reference/generated/kubectl/kubectl-commands/) +- [Книга Kubectl](https://kubectl.docs.kubernetes.io) +- [Довідник API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/uk/docs/concepts/overview/working-with-objects/owners-dependents.md b/content/uk/docs/concepts/overview/working-with-objects/owners-dependents.md new file mode 100644 index 0000000000000..c452f0ad3383b --- /dev/null +++ b/content/uk/docs/concepts/overview/working-with-objects/owners-dependents.md @@ -0,0 +1,42 @@ +--- +title: Власники та Залежності +content_type: concept +weight: 90 +--- + + + +В Kubernetes деякі {{< glossary_tooltip text="обʼєкти" term_id="object" >}} є +*власниками* інших обʼєктів. Наприклад, {{}} є власником групи Podʼів. Ці обʼєкти, якими володіють, є *залежними* від свого власника. + +Власність відрізняється від [механізму міток та селекторів](/docs/concepts/overview/working-with-objects/labels/), який також використовують деякі ресурси. Наприклад, розгляньте Service, який створює обʼєкти `EndpointSlice`. Service використовує {{}} щоби панель управління могла +визначити, які обʼєкти `EndpointSlice` використовуються для цього Service. Крім того, до міток, кожен `EndpointSlice`, який керується від імені Service, має +посилання на власника. Посилання на власника допомагають різним частинам Kubernetes уникати втручання в обʼєкти, якими вони не керують. + +## Посилання на власника в специфікаціях обʼєктів {#owner-references-in-object-specifications} + +Залежні обʼєкти мають поле `metadata.ownerReferences`, яке містить посилання на їх власника. Дійсне посилання на власника складається з назви обʼєкта та {{}} в межах того ж {{}}, що й залежний обʼєкт. Kubernetes автоматично встановлює значення цього поля для обʼєктів, які є залежностями інших обʼєктів, таких як ReplicaSets, DaemonSets, Deployments, Jobs and CronJobs, та ReplicationControllers. Ви також можете налаштувати ці звʼязки вручну, змінивши значення цього поля. Однак зазвичай цього не потрібно робити, і можна дозволити Kubernetes автоматично керувати цими звʼязками. + +Залежні обʼєкти також мають поле `ownerReferences.blockOwnerDeletion`, яке має булеве значення і контролює, чи можуть певні залежні обʼєкти блокувати збір сміття, що видаляє їх власника. Kubernetes автоматично встановлює це поле в `true`, якщо {{}} (наприклад, контролер Deployment) встановлює значення поля `metadata.ownerReferences`. Ви також можете встановити значення поля `blockOwnerDeletion` вручну, щоб контролювати, які залежні обʼєкти блокують збір сміття. + +Контролер доступу Kubernetes контролює доступ користувачів для зміни цього поля для залежних ресурсів на основі прав видалення власника. Це керування перешкоджає несанкціонованим користувачам затримувати видалення обʼєкта-власника. + +{{< note >}} +Посилання на власника поза межами простору імен заборонені. Залежні обʼєкти в просторі імен можуть вказувати власників або на рівні кластера, або в тому ж просторі імен. Якщо цього не відбувається, посилання на власника розглядається як відсутнє, і залежний обʼєкт може бути видалений, якщо всі власники визначено як відсутні. + +Обʼєкти в просторі імен можуть вказувати тільки власників в межах кластера. У версії v1.20+, якщо обʼєкт в просторі імен вказує обʼєкт кластера як власника, він розглядається як обʼєкт з нерозвʼязаним посиланням на власника і не може бути вилучений. + +У v1.20+, якщо збирач сміття виявляє недійсний перехресний простір імен `ownerReference` або залежний обʼєкт на рівні кластера з `ownerReference`, що посилається на тип простору імен, зʼявляється повідомлення з попередженням з причиною `OwnerRefInvalidNamespace` та `involvedObject` про недійсного залежного. Ви можете перевірити наявність такого роду подій (Event), запустивши `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. +{{< /note >}} + +## Власність та завершувачі {#ownership-and-finalizers} + +Коли ви наказуєте Kubernetes видалити ресурс, сервер API дозволяє керуючому контролеру обробити будь-які [правила завершувача](/docs/concepts/overview/working-with-objects/finalizers/) для ресурсу. {{}} запобігають випадковому видаленню ресурсів, які вашому кластеру можуть ще бути потрібні для коректної роботи. Наприклад, якщо ви намагаєтеся видалити [PersistentVolume](/docs/concepts/storage/persistent-volumes/), який все ще використовується Podʼом, видалення не відбувається негайно, оскільки `PersistentVolume` має завершувач `kubernetes.io/pv-protection`. Замість цього [том](/docs/concepts/storage/volumes/) залишається в стані `Terminating` до тих пір, поки Kubernetes не очистить завершувач, що відбувається тільки після того, як `PersistentVolume` більше не привʼязаний до Podʼа. + +Kubernetes також додає завершувачів до ресурсу-власника, коли ви використовуєте або [переднє або інше каскадне видалення](/docs/concepts/architecture/garbage-collection/#cascading-deletion). При передньому видаленні додається завершувач `foreground`, так що контролер повинен видалити залежні ресурси, які також мають `ownerReferences.blockOwnerDeletion=true`, перш ніж він видалить власника. Якщо ви вказуєте політику видалення покинутих ресурсів (сиріт), Kubernetes додає завершувач `orphan`, так що контролер ігнорує залежні ресурси після того, як він видаляє обʼєкт-власника. + +## {{% heading "whatsnext" %}} + +* Дізнайтеся більше про [завершувачі Kubernetes](/docs/concepts/overview/working-with-objects/finalizers/). +* Дізнайтеся про [збір сміття](/docs/concepts/architecture/garbage-collection). +* Прочитайте API-довідник про [метадані обʼєкта](/docs/reference/kubernetes-api/common-definitions/object-meta/#System). diff --git a/content/uk/docs/concepts/policy/_index.md b/content/uk/docs/concepts/policy/_index.md new file mode 100644 index 0000000000000..7c35dc7cfda30 --- /dev/null +++ b/content/uk/docs/concepts/policy/_index.md @@ -0,0 +1,69 @@ +--- +title: "Політики" +weight: 90 +no_list: true +description: > + Керування безпекою та найкращі практики застосування політик. +--- + + + +Політики Kubernetes — це конфігурації, які керують поведінкою інших конфігурацій чи ресурсів. Kubernetes надає кілька різних рівнів політик, про які можна дізнатися в цьому розділі. + + + +## Застосування політик за допомогою обʼєктів API {#apply-policies-using-api-objects} + +Деякі обʼєкти API виступають як політики. Ось деякі приклади: + +* [NetworkPolicies](/docs/concepts/services-networking/network-policies/) можуть бути використані для обмеження вхідного та вихідного трафіку для робочого навантаження. +* [LimitRanges](/docs/concepts/policy/limit-range/) керують обмеженнями розподілу ресурсів між різними типами обʼєктів. +* [ResourceQuotas](/docs/concepts/policy/resource-quotas/) обмежують споживання ресурсів для {{< glossary_tooltip text="простору імен" term_id="namespace" >}}. + +## Застосування політик за допомогою admission-контролерів {#apply-policies-using-admission-controllers} + +{{< glossary_tooltip text="Admission контролер" term_id="admission-controller" >}} працює в API-сервері та може перевіряти або змінювати запити до API. Деякі admission-контролери виступають як політики. Наприклад, admission-контролер [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) змінює новий обʼєкт Pod, щоб встановити політику завантаження образу на `Always`. + +У Kubernetes є кілька вбудованих admission-контролерів, які можна налаштувати за допомогою прапорця `--enable-admission-plugins` API-сервера. + +Детальні відомості про admission-контролери, з повним списком доступних admission-контролерів, ви знайдете в окремому розділі: + +* [Admission контролери](/docs/reference/access-authn-authz/admission-controllers/) + +## Застосування політик за допомогою ValidatingAdmissionPolicy {#apply-policies-using-validating-admission-policy} + +Перевірка політик допуску дозволяє виконувати налаштовані перевірки в API-сервері за допомогою мови виразів Common Expression Language (CEL). Наприклад, `ValidatingAdmissionPolicy` може бути використаний для заборони використання образів з теґом `latest`. + +`ValidatingAdmissionPolicy` працює з запитом до API та може бути використаний для блокування, аудиту та попередження користувачів про невідповідні конфігурації. + +Детальні відомості про API `ValidatingAdmissionPolicy` з прикладами ви знайдете в окремому розділі: + +* [Перевірка політик допуску](/docs/reference/access-authn-authz/validating-admission-policy/) + +## Застосування політик за допомогою динамічного контролю допуску {#apply-policies-using-dynamic-admission-control} + +Контролери динамічного допуску (або вхідні вебхуки) працюють поза API-сервером як окремі застосунки, які реєструються для отримання запитів вебхуків для виконання перевірки або зміни запитів до API. + +Контролери динамічного допуску можуть бути використані для застосування політик до запитів до API та спрацьовувати інші робочі процеси на основі політик. Контролер динамічного допуску може виконувати складні перевірки, включаючи ті, які вимагають отримання інших ресурсів кластера та зовнішніх даних. Наприклад, звірка перевірки образу може виконувати пошук даних у реєстрах OCI для перевірки підписів та атестації образу контейнерів. + +Детальні відомості про динамічний контроль допуску ви знайдете в окремому розділі: + +* [Динамічний контроль допуску](/docs/reference/access-authn-authz/extensible-admission-controllers/) + +### Реалізації {#implementations-admission-control} + +{{% thirdparty-content %}} + +Контролери динамічного допуску, які виступають як гнучкі рушії політик, розробляються в екосистемі Kubernetes, серед них: + +* [Kubewarden](https://github.com/kubewarden) +* [Kyverno](https://kyverno.io) +* [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) +* [Polaris](https://polaris.docs.fairwinds.com/admission-controller/) + +## Застосування політик за конфігурацій Kubelet {#apply-policies-using-kubelet-configuration} + +Kubeletʼи дозволяють налаштовувати політики для кожного робочого вузла. Деякі конфігурації Kubeletʼів працюють як політики: + +* [Резурвування та ліміти Process ID](/docs/concepts/policy/pid-limiting/) використовуються для обмеження та резервування PID. +* [Менеджер ресурсів вузлів](/docs/concepts/policy/node-resource-manager/) може бути використаний для керування обчислювальними ресурсами, ресурсами памʼяті та ресурсами пристроїв для високопропускних та критичних до затримок робочих навантажень. diff --git a/content/uk/docs/concepts/scheduling-eviction/_index.md b/content/uk/docs/concepts/scheduling-eviction/_index.md new file mode 100644 index 0000000000000..3e9c4f70f9ddb --- /dev/null +++ b/content/uk/docs/concepts/scheduling-eviction/_index.md @@ -0,0 +1,32 @@ +--- +title: "Планування, Випередження та Вивільнення" +weight: 95 +content_type: concept +description: > + У Kubernetes планування означає забезпечення відповідності робочих навантажень (Pods) вузлам (Nodes), щоб kubelet міг їх запустити. Випередження — це процес припинення роботи Podʼів з низьким пріоритетом, щоб Podʼи з вищим пріоритетом могли розміщуватися на вузлах. Вивільнення — це процес проактивного припинення роботи одного або кількох Podʼів на вузлах з нестачею ресурсів. +no_list: true +--- + +У Kubernetes планування означає забезпечення відповідності {{< glossary_tooltip text="Podʼів" term_id="pod" >}} вузлам ({{< glossary_tooltip text="Nodes" term_id="node" >}}), щоб {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} міг їх запустити. Випередження — це процес припинення роботи Podʼів з низьким {{< glossary_tooltip text="пріоритетом" term_id="pod-priority" >}}, щоб Podʼи з вищим пріоритетом могли розміщуватися на вузлах. Вивільнення — це процес проактивного припинення роботи одного або кількох Podʼів на вузлах. + +## Планування {#scheduling} + +* [Планувальник Kubernetes](/docs/concepts/scheduling-eviction/kube-scheduler/) +* [Призначення Podʼів вузлам](/docs/concepts/scheduling-eviction/assign-pod-node/) +* [Витрати ресурсів на Pod](/docs/concepts/scheduling-eviction/pod-overhead/) +* [Топологія обмежень розподілу Podʼів](/docs/concepts/scheduling-eviction/topology-spread-constraints/) +* [Заплямованість та Толерантність](/docs/concepts/scheduling-eviction/taint-and-toleration/) +* [Фреймворк планування](/docs/concepts/scheduling-eviction/scheduling-framework) +* [Динамічний розподіл ресурсів](/docs/concepts/scheduling-eviction/dynamic-resource-allocation) +* [Налаштування продуктивності планувальника](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* [Пакування ресурсів для розширених ресурсів](/docs/concepts/scheduling-eviction/resource-bin-packing/) +* [Готовність планування Pod](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/) +* [Descheduler](https://github.com/kubernetes-sigs/descheduler#descheduler-for-kubernetes) + +## Переривання роботи Podʼу {#pod-disruption} + +{{}} + +* [Пріоритет та Випередження Podʼів](/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [Вивільнення внаслідок тиску на вузол](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [Вивільнення, ініційоване API](/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/uk/docs/concepts/security/_index.md b/content/uk/docs/concepts/security/_index.md new file mode 100644 index 0000000000000..2561b0442e631 --- /dev/null +++ b/content/uk/docs/concepts/security/_index.md @@ -0,0 +1,6 @@ +--- +title: "Безпека" +weight: 85 +description: > + Концепції для забезпечення безпеки ваших хмарних робочих навантажень. +--- \ No newline at end of file diff --git a/content/uk/docs/concepts/services-networking/_index.md b/content/uk/docs/concepts/services-networking/_index.md index 634694311a433..d8fd6c52582e7 100644 --- a/content/uk/docs/concepts/services-networking/_index.md +++ b/content/uk/docs/concepts/services-networking/_index.md @@ -1,4 +1,37 @@ --- title: "Сервіси, балансування навантаження та мережа" weight: 60 +description: > + Концепції та ресурси, що лежать в основі роботи в мережі в Kubernetes. --- + +## Мережева модель Kubernetes {#the-kubernetes-network-model} + +Кожен [`Pod`](/docs/concepts/workloads/pods/) в Kubernetes отримує свою власну унікальну в межах кластера IP-адресу. Це означає, що вам не потрібно явним чином налаштовувати звʼязок між Podʼами і ви, майже ніколи, не відчуватимете потреби вручну призначати відповідність портів контейнерів портам хосту. Це створює чисту, зворотньосумісну модель, де `Pod`ʼи можна вважати подібними до віртуальних машин або фізичних серверів, з точки зору виділення портів, іменування, виявлення служб та [балансування навантаження](/docs/concepts/services-networking/ingress/#load-balancing), конфігурації застосунків та міграції. + +Kubernetes накладає наступні фундаментальні вимоги до будь-якої реалізації мережі (з урахуванням будь-якої цілеспрямованої політики сегментації мережі): + +* Podʼи можуть спілкуватися з усіма іншими Podʼами на будь-якому іншому [вузлі](/docs/concepts/architecture/nodes/) без NAT +* Агенти на вузлі (наприклад, системні служби, kubelet) можуть спілкуватися з усіма Podʼами на цьому вузлі + +Примітка: Для тих платформ, які підтримують Podʼи, що працюють в мережі вузла (наприклад, Linux), коли Podʼи приєднуються до мережі вузла вони все ще можуть спілкуватися з усіма Podʼами на всіх вузлах без NAT. + +Ця модель не тільки менш складна в цілому, але вона в основному сумісна з бажанням Kubernetes забезпечити безпроблемним перенесення застосунків з віртуальних машин в контейнери. Якщо ваша робота раніше виконувалася у віртуальній машині, ваша віртуальна машина мала IP-адресу та могла спілкуватися з іншими віртуальними машинами у вашому проєкті. Це та ж сама базова модель. + +IP-адреси Kubernetes існують на рівні `Pod` — контейнери всередині `Pod` спільно використовують свої мережеві простори імен, включаючи їх IP-адреси та MAC-адреси. Це означає, що контейнери всередині `Pod` можуть мати доступ до портів один одного через `localhost`. Це також означає, що контейнери всередині `Pod` повинні координувати використання портів, але це не відрізняється від процесів у віртуальній машині. Ця модель називається "IP-на-кожен-Pod". + +Те, як це реалізовано, залежить від середовища виконання контейнерів в кожному конкретному випадку. + +Можна запросити порти на самому вузлі (`Node`), які переспрямувати до вашого `Pod`ʼу. Це називається "портами на вузлі", але досить нішева операція. Те як це реалізовано, залежить від середовища виконання контейнерів в кожному конкретному випадку. `Pod` сам по собі не бачить існування чи відсутності портів хосту. + +Мережа Kubernetes розвʼязує чотири проблеми: + +* Контейнери в Pod [використовують мережу для спілкування](/docs/concepts/services-networking/dns-pod-service/) використовучи loopback. +* [Service](/docs/concepts/services-networking/service/) API дозволяє вам [використовувати застосунок, що працює в Pod](/docs/tutorials/services/connect-applications-service/), щоб до нього можна було б дістатись ззовні вашого кластера. +* [Ingress](/docs/concepts/services-networking/ingress/) надає додаткові можливості спеціально для надання доступу до HTTP-застосунків, вебсайтів та API. +* [Gateway API](/docs/concepts/services-networking/gateway/) є {{}}, який надає виразний, розширюваний та орієнтований на ролі різновиди API для моделювання мережевих служб. +* Ви також можете використовувати Services для [публікації служб лише для внутрішнього використання в вашому кластері](/docs/concepts/services-networking/service-traffic-policy/). + +Посібник [Поєднання застосунків за допомогою служб](/docs/tutorials/services/connect-applications-service/) пояснює, як використовувати `Service` для забезпечення взаємодії між застосунками в Kubernetes. + +[Мережі в кластері](/docs/concepts/cluster-administration/networking/) пояснює, як вибрати та налаштувати мережевий стек для вашого кластера, включаючи огляд різних технологій. diff --git a/content/uk/docs/concepts/services-networking/dual-stack.md b/content/uk/docs/concepts/services-networking/dual-stack.md new file mode 100644 index 0000000000000..2dccf5562f3f9 --- /dev/null +++ b/content/uk/docs/concepts/services-networking/dual-stack.md @@ -0,0 +1,315 @@ +--- +title: Подвійний стек IPv4/IPv6 +description: >- + Kubernetes дозволяє налаштувати мережеве зʼєднання з одним стеком IPv4, з одним стеком IPv6 або з подвійним стеком з обома сімействами мереж. Ця сторінка пояснює, як це зробити. +feature: + title: Подвійний стек IPv4/IPv6 + description: > + Виділення адрес IPv4 та IPv6 для Подів та Сервісів +content_type: concept +reviewers: + - lachie83 + - khenidak + - aramase + - bridgetkromhout +weight: 90 +--- + + + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +IPv4/IPv6 dual-stack networking enables the allocation of both IPv4 and IPv6 addresses to +{{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}. + +IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluster starting in +1.21, allowing the simultaneous assignment of both IPv4 and IPv6 addresses. + + + +## Supported Features + +IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features: + +* Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod) +* IPv4 and IPv6 enabled Services +* Pod off-cluster egress routing (eg. the Internet) via both IPv4 and IPv6 interfaces + +## Prerequisites + +The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack Kubernetes clusters: + +* Kubernetes 1.20 or later + + For information about using dual-stack services with earlier + Kubernetes versions, refer to the documentation for that version + of Kubernetes. + +* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide + Kubernetes nodes with routable IPv4/IPv6 network interfaces) +* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that + supports dual-stack networking. + +## Configure IPv4/IPv6 dual-stack + +To configure IPv4/IPv6 dual-stack, set dual-stack cluster network assignments: + +* kube-apiserver: + * `--service-cluster-ip-range=,` +* kube-controller-manager: + * `--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 +* kube-proxy: + * `--cluster-cidr=,` +* kubelet: + * `--node-ip=,` + * This option is required for bare metal dual-stack nodes (nodes that do not define a + cloud provider with the `--cloud-provider` flag). If you are using a cloud provider + and choose to override the node IPs chosen by the cloud provider, set the + `--node-ip` option. + * (The legacy built-in cloud providers do not support dual-stack `--node-ip`.) + +{{< 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 + +You can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both. + +The address family of a Service defaults to the address family of the first service cluster IP +range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver). + +When you define a Service you can optionally configure it as dual stack. To specify the behavior you want, you +set the `.spec.ipFamilyPolicy` field to one of the following values: + +* `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, + using the first configured service cluster IP range. +* `PreferDualStack`: + * Allocates IPv4 and IPv6 cluster IPs for the Service. +* `RequireDualStack`: Allocates Service `.spec.ClusterIPs` from both IPv4 and IPv6 address ranges. + * Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family + of the first element in the `.spec.ipFamilies` array. + +If you would like to define which IP family to use for single stack or define the order of IP +families for dual-stack, you can choose the address families by setting an optional field, +`.spec.ipFamilies`, on the Service. + +{{< note >}} +The `.spec.ipFamilies` field is conditionally mutable: you can add or remove a secondary +IP address family, but you cannot change the primary IP address family of an existing Service. +{{< /note >}} + +You can set `.spec.ipFamilies` to any of the following array values: + +- `["IPv4"]` +- `["IPv6"]` +- `["IPv4","IPv6"]` (dual stack) +- `["IPv6","IPv4"]` (dual stack) + +The first family you list is used for the legacy `.spec.ClusterIP` field. + +### Dual-stack Service configuration scenarios + +These examples demonstrate the behavior of various dual-stack Service configuration scenarios. + +#### Dual-stack options on new Services + +1. This Service specification does not explicitly define `.spec.ipFamilyPolicy`. When you create + this Service, Kubernetes assigns a cluster IP for the Service from the first configured + `service-cluster-ip-range` and sets the `.spec.ipFamilyPolicy` to `SingleStack`. ([Services + without selectors](/docs/concepts/services-networking/service/#services-without-selectors) and + [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors + will behave in this same way.) + + {{% code_sample file="service/networking/dual-stack-default-svc.yaml" %}} + +1. This Service specification explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. When + you create this Service on a dual-stack cluster, Kubernetes assigns both IPv4 and IPv6 + addresses for the service. The control plane updates the `.spec` for the Service to record the IP + address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned + IP addresses; `.spec.ClusterIP` is a secondary field with its value calculated from + `.spec.ClusterIPs`. + + * For the `.spec.ClusterIP` field, the control plane records the IP address that is from the + same address family as the first service cluster IP range. + * On a single-stack cluster, the `.spec.ClusterIPs` and `.spec.ClusterIP` fields both only list + one address. + * On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy` + behaves the same as `PreferDualStack`. + + {{% code_sample file="service/networking/dual-stack-preferred-svc.yaml" %}} + +1. This Service specification explicitly defines `IPv6` and `IPv4` in `.spec.ipFamilies` as well + as defining `PreferDualStack` in `.spec.ipFamilyPolicy`. When Kubernetes assigns an IPv6 and + IPv4 address in `.spec.ClusterIPs`, `.spec.ClusterIP` is set to the IPv6 address because that is + the first element in the `.spec.ClusterIPs` array, overriding the default. + + {{% code_sample file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" %}} + +#### Dual-stack defaults on existing Services + +These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster +where Services already exist. (Upgrading an existing cluster to 1.21 or beyond will enable +dual-stack.) + +1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are + configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set + `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP + will be stored in `.spec.ClusterIPs`. + + {{% code_sample file="service/networking/dual-stack-default-svc.yaml" %}} + + You can validate this behavior by using kubectl to inspect an existing service. + + ```shell + kubectl get svc my-service -o yaml + ``` + + ```yaml + apiVersion: v1 + kind: Service + metadata: + labels: + app.kubernetes.io/name: MyApp + name: my-service + spec: + clusterIP: 10.0.197.123 + clusterIPs: + - 10.0.197.123 + ipFamilies: + - IPv4 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 80 + selector: + app.kubernetes.io/name: MyApp + type: ClusterIP + status: + loadBalancer: {} + ``` + +1. When dual-stack is enabled on a cluster, existing + [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors are + configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set + `.spec.ipFamilies` to the address family of the first service cluster IP range (configured via the + `--service-cluster-ip-range` flag to the kube-apiserver) even though `.spec.ClusterIP` is set to + `None`. + + {{% code_sample file="service/networking/dual-stack-default-svc.yaml" %}} + + You can validate this behavior by using kubectl to inspect an existing headless service with selectors. + + ```shell + kubectl get svc my-service -o yaml + ``` + + ```yaml + apiVersion: v1 + kind: Service + metadata: + labels: + app.kubernetes.io/name: MyApp + name: my-service + spec: + clusterIP: None + clusterIPs: + - None + ipFamilies: + - IPv4 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 80 + selector: + app.kubernetes.io/name: MyApp + ``` + +#### Switching Services between single-stack and dual-stack + +Services can be changed from single-stack to dual-stack and from dual-stack to single-stack. + +1. To change a Service from single-stack to dual-stack, change `.spec.ipFamilyPolicy` from + `SingleStack` to `PreferDualStack` or `RequireDualStack` as desired. When you change this + Service from single-stack to dual-stack, Kubernetes assigns the missing address family so that the + Service now has IPv4 and IPv6 addresses. + + Edit the Service specification updating the `.spec.ipFamilyPolicy` from `SingleStack` to `PreferDualStack`. + + Before: + + ```yaml + spec: + ipFamilyPolicy: SingleStack + ``` + + After: + + ```yaml + spec: + ipFamilyPolicy: PreferDualStack + ``` + +1. To change a Service from dual-stack to single-stack, change `.spec.ipFamilyPolicy` from + `PreferDualStack` or `RequireDualStack` to `SingleStack`. When you change this Service from + dual-stack to single-stack, Kubernetes retains only the first element in the `.spec.ClusterIPs` + array, and sets `.spec.ClusterIP` to that IP address and sets `.spec.ipFamilies` to the address + family of `.spec.ClusterIPs`. + +### Headless Services without selector + +For [Headless Services without selectors](/docs/concepts/services-networking/service/#without-selectors) +and without `.spec.ipFamilyPolicy` explicitly set, the `.spec.ipFamilyPolicy` field defaults to +`RequireDualStack`. + +### Service type LoadBalancer + +To provision a dual-stack load balancer for your Service: + +* Set the `.spec.type` field to `LoadBalancer` +* Set `.spec.ipFamilyPolicy` field to `PreferDualStack` or `RequireDualStack` + +{{< note >}} +To use a dual-stack `LoadBalancer` type Service, your cloud provider must support IPv4 and IPv6 +load balancers. +{{< /note >}} + +## Egress traffic + +If you want to enable egress traffic in order to reach off-cluster destinations (eg. the public +Internet) from a Pod that uses non-publicly routable IPv6 addresses, you need to enable the Pod to +use a publicly routed IPv6 address via a mechanism such as transparent proxying or IP +masquerading. The [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) project +supports IP masquerading on dual-stack clusters. + +{{< note >}} +Ensure your {{< glossary_tooltip text="CNI" term_id="cni" >}} provider supports IPv6. +{{< /note >}} + +## Windows support + +Kubernetes on Windows does not support single-stack "IPv6-only" networking. However, +dual-stack IPv4/IPv6 networking for pods and nodes with single-family services +is supported. + +You can use IPv4/IPv6 dual-stack networking with `l2bridge` networks. + +{{< note >}} +Overlay (VXLAN) networks on Windows **do not** support dual-stack networking. +{{< /note >}} + +You can read more about the different network modes for Windows within the +[Networking on Windows](/docs/concepts/services-networking/windows-networking#network-modes) topic. + +## {{% heading "whatsnext" %}} + +* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking +* [Enable dual-stack networking using kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) + diff --git a/content/uk/docs/concepts/services-networking/service.md b/content/uk/docs/concepts/services-networking/service.md new file mode 100644 index 0000000000000..cf07306b3b9b0 --- /dev/null +++ b/content/uk/docs/concepts/services-networking/service.md @@ -0,0 +1,1034 @@ +--- +reviewers: +- bprashanth +title: Сервіси +feature: + title: Виявлення сервісів та балансування навантаження + description: > + Не потрібно змінювати свій застосунок, щоб використовувати незнайомий механізм виявлення сервісів. Kubernetes надає Podʼам власні IP-адреси та єдине DNS-імʼя для набору Podʼів, а також може балансувати навантаження між ними. +description: >- + Надайте доступ до застосунку, що працює в кластері, за допомогою однієї точки доступу, навіть якщо робота розподілена між декількома бекендами. +content_type: concept +weight: 10 +--- + + + + +{{< glossary_definition term_id="service" length="short" prepend="In Kubernetes, a Service is" >}} + +A key aim of Services in Kubernetes is that you don't need to modify your existing +application to use an unfamiliar service discovery mechanism. +You can run code in Pods, whether this is a code designed for a cloud-native world, or +an older app you've containerized. You use a Service to make that set of Pods available +on the network so that clients can interact with it. + +If you use a {{< glossary_tooltip term_id="deployment" >}} to run your app, +that Deployment can create and destroy Pods dynamically. From one moment to the next, +you don't know how many of those Pods are working and healthy; you might not even know +what those healthy Pods are named. +Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are created and destroyed +to match the desired state of your cluster. Pods are ephemeral resources (you should not +expect that an individual Pod is reliable and durable). + +Each Pod gets its own IP address (Kubernetes expects network plugins to ensure this). +For a given Deployment in your cluster, the set of Pods running in one moment in +time could be different from the set of Pods running that application a moment later. + +This leads to a problem: if some set of Pods (call them "backends") provides +functionality to other Pods (call them "frontends") inside your cluster, +how do the frontends find out and keep track of which IP address to connect +to, so that the frontend can use the backend part of the workload? + +Enter _Services_. + + + +## Services in Kubernetes + +The Service API, part of Kubernetes, is an abstraction to help you expose groups of +Pods over a network. Each Service object defines a logical set of endpoints (usually +these endpoints are Pods) along with a policy about how to make those pods accessible. + +For example, consider a stateless image-processing backend which is running with +3 replicas. Those replicas are fungible—frontends do not care which backend +they use. While the actual Pods that compose the backend set may change, the +frontend clients should not need to be aware of that, nor should they need to keep +track of the set of backends themselves. + +The Service abstraction enables this decoupling. + +The set of Pods targeted by a Service is usually determined +by a {{< glossary_tooltip text="selector" term_id="selector" >}} that you +define. +To learn about other ways to define Service endpoints, +see [Services _without_ selectors](#services-without-selectors). + +If your workload speaks HTTP, you might choose to use an +[Ingress](/docs/concepts/services-networking/ingress/) to control how web traffic +reaches that workload. +Ingress is not a Service type, but it acts as the entry point for your +cluster. An Ingress lets you consolidate your routing rules into a single resource, so +that you can expose multiple components of your workload, running separately in your +cluster, behind a single listener. + +The [Gateway](https://gateway-api.sigs.k8s.io/#what-is-the-gateway-api) API for Kubernetes +provides extra capabilities beyond Ingress and Service. You can add Gateway to your cluster - +it is a family of extension APIs, implemented using +{{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} - +and then use these to configure access to network services that are running in your cluster. + +### Cloud-native service discovery + +If you're able to use Kubernetes APIs for service discovery in your application, +you can query the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +for matching EndpointSlices. Kubernetes updates the EndpointSlices for a Service +whenever the set of Pods in a Service changes. + +For non-native applications, Kubernetes offers ways to place a network port or load +balancer in between your application and the backend Pods. + +Either way, your workload can use these [service discovery](#discovering-services) +mechanisms to find the target it wants to connect to. + +## Defining a Service + +A Service is an {{< glossary_tooltip text="object" term_id="object" >}} +(the same way that a Pod or a ConfigMap is an object). You can create, +view or modify Service definitions using the Kubernetes API. Usually +you use a tool such as `kubectl` to make those API calls for you. + +For example, suppose you have a set of Pods that each listen on TCP port 9376 +and are labelled as `app.kubernetes.io/name=MyApp`. You can define a Service to +publish that TCP listener: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 +``` + +Applying this manifest creates a new Service named "my-service" with the default +ClusterIP [service type](#publishing-services-service-types). The Service +targets TCP port 9376 on any Pod with the `app.kubernetes.io/name: MyApp` label. + +Kubernetes assigns this Service an IP address (the _cluster IP_), +that is used by the virtual IP address mechanism. For more details on that mechanism, +read [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/). + +The controller for that Service continuously scans for Pods that +match its selector, and then makes any necessary updates to the set of +EndpointSlices for the Service. + +The name of a Service object must be a valid +[RFC 1035 label name](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names). + + +{{< note >}} +A Service can map _any_ incoming `port` to a `targetPort`. By default and +for convenience, the `targetPort` is set to the same value as the `port` +field. +{{< /note >}} + +### Port definitions {#field-spec-ports} + +Port definitions in Pods have names, and you can reference these names in the +`targetPort` attribute of a Service. For example, we can bind the `targetPort` +of the Service to the Pod port in the following way: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + app.kubernetes.io/name: proxy +spec: + containers: + - name: nginx + image: nginx:stable + ports: + - containerPort: 80 + name: http-web-svc + +--- +apiVersion: v1 +kind: Service +metadata: + name: nginx-service +spec: + selector: + app.kubernetes.io/name: proxy + ports: + - name: name-of-service-port + protocol: TCP + port: 80 + targetPort: http-web-svc +``` + +This works even if there is a mixture of Pods in the Service using a single +configured name, with the same network protocol available via different +port numbers. This offers a lot of flexibility for deploying and evolving +your Services. For example, you can change the port numbers that Pods expose +in the next version of your backend software, without breaking clients. + +The default protocol for Services is +[TCP](/docs/reference/networking/service-protocols/#protocol-tcp); you can also +use any other [supported protocol](/docs/reference/networking/service-protocols/). + +Because many Services need to expose more than one port, Kubernetes supports +[multiple port definitions](#multi-port-services) for a single Service. +Each port definition can have the same `protocol`, or a different one. + +### Services without selectors + +Services most commonly abstract access to Kubernetes Pods thanks to the selector, +but when used with a corresponding set of +{{}} +objects and without a selector, the Service can abstract other kinds of backends, +including ones that run outside the cluster. + +For example: + +* You want to have an external database cluster in production, but in your + test environment you use your own databases. +* You want to point your Service to a Service in a different + {{< glossary_tooltip term_id="namespace" >}} or on another cluster. +* You are migrating a workload to Kubernetes. While evaluating the approach, + you run only a portion of your backends in Kubernetes. + +In any of these scenarios you can define a Service _without_ specifying a +selector to match Pods. For example: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9376 +``` + +Because this Service has no selector, the corresponding EndpointSlice (and +legacy Endpoints) objects are not created automatically. You can map the Service +to the network address and port where it's running, by adding an EndpointSlice +object manually. For example: + +```yaml +apiVersion: discovery.k8s.io/v1 +kind: EndpointSlice +metadata: + name: my-service-1 # by convention, use the name of the Service + # as a prefix for the name of the EndpointSlice + labels: + # You should set the "kubernetes.io/service-name" label. + # Set its value to match the name of the Service + kubernetes.io/service-name: my-service +addressType: IPv4 +ports: + - name: '' # empty because port 9376 is not assigned as a well-known + # port (by IANA) + appProtocol: http + protocol: TCP + port: 9376 +endpoints: + - addresses: + - "10.4.5.6" + - addresses: + - "10.1.2.3" +``` + +#### Custom EndpointSlices + +When you create an [EndpointSlice](#endpointslices) object for a Service, you can +use any name for the EndpointSlice. Each EndpointSlice in a namespace must have a +unique name. You link an EndpointSlice to a Service by setting the +`kubernetes.io/service-name` {{< glossary_tooltip text="label" term_id="label" >}} +on that EndpointSlice. + +{{< note >}} +The endpoint IPs _must not_ be: loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), or +link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6). + +The endpoint IP addresses cannot be the cluster IPs of other Kubernetes Services, +because {{< glossary_tooltip term_id="kube-proxy" >}} doesn't support virtual IPs +as a destination. +{{< /note >}} + +For an EndpointSlice that you create yourself, or in your own code, +you should also pick a value to use for the label +[`endpointslice.kubernetes.io/managed-by`](/docs/reference/labels-annotations-taints/#endpointslicekubernetesiomanaged-by). +If you create your own controller code to manage EndpointSlices, consider using a +value similar to `"my-domain.example/name-of-controller"`. If you are using a third +party tool, use the name of the tool in all-lowercase and change spaces and other +punctuation to dashes (`-`). +If people are directly using a tool such as `kubectl` to manage EndpointSlices, +use a name that describes this manual management, such as `"staff"` or +`"cluster-admins"`. You should +avoid using the reserved value `"controller"`, which identifies EndpointSlices +managed by Kubernetes' own control plane. + +#### Accessing a Service without a selector {#service-no-selector-access} + +Accessing a Service without a selector works the same as if it had a selector. +In the [example](#services-without-selectors) for a Service without a selector, +traffic is routed to one of the two endpoints defined in +the EndpointSlice manifest: a TCP connection to 10.1.2.3 or 10.4.5.6, on port 9376. + +{{< note >}} +The Kubernetes API server does not allow proxying to endpoints that are not mapped to +pods. Actions such as `kubectl proxy ` where the service has no +selector will fail due to this constraint. This prevents the Kubernetes API server +from being used as a proxy to endpoints the caller may not be authorized to access. +{{< /note >}} + +An `ExternalName` Service is a special case of Service that does not have +selectors and uses DNS names instead. For more information, see the +[ExternalName](#externalname) section. + +### EndpointSlices + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + +[EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) are objects that +represent a subset (a _slice_) of the backing network endpoints for a Service. + +Your Kubernetes cluster tracks how many endpoints each EndpointSlice represents. +If there are so many endpoints for a Service that a threshold is reached, then +Kubernetes adds another empty EndpointSlice and stores new endpoint information +there. +By default, Kubernetes makes a new EndpointSlice once the existing EndpointSlices +all contain at least 100 endpoints. Kubernetes does not make the new EndpointSlice +until an extra endpoint needs to be added. + +See [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) for more +information about this API. + +### Endpoints + +In the Kubernetes API, an +[Endpoints](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) +(the resource kind is plural) defines a list of network endpoints, typically +referenced by a Service to define which Pods the traffic can be sent to. + +The EndpointSlice API is the recommended replacement for Endpoints. + +#### Over-capacity endpoints + +Kubernetes limits the number of endpoints that can fit in a single Endpoints +object. When there are over 1000 backing endpoints for a Service, Kubernetes +truncates the data in the Endpoints object. Because a Service can be linked +with more than one EndpointSlice, the 1000 backing endpoint limit only +affects the legacy Endpoints API. + +In that case, Kubernetes selects at most 1000 possible backend endpoints to store +into the Endpoints object, and sets an +{{< glossary_tooltip text="annotation" term_id="annotation" >}} on the Endpoints: +[`endpoints.kubernetes.io/over-capacity: truncated`](/docs/reference/labels-annotations-taints/#endpoints-kubernetes-io-over-capacity). +The control plane also removes that annotation if the number of backend Pods drops below 1000. + +Traffic is still sent to backends, but any load balancing mechanism that relies on the +legacy Endpoints API only sends traffic to at most 1000 of the available backing endpoints. + +The same API limit means that you cannot manually update an Endpoints to have more than 1000 endpoints. + +### Application protocol + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +The `appProtocol` field provides a way to specify an application protocol for +each Service port. This is used as a hint for implementations to offer +richer behavior for protocols that they understand. +The value of this field is mirrored by the corresponding +Endpoints and EndpointSlice objects. + +This field follows standard Kubernetes label syntax. Valid values are one of: + +* [IANA standard service names](https://www.iana.org/assignments/service-names). + +* Implementation-defined prefixed names such as `mycompany.com/my-custom-protocol`. + +* Kubernetes-defined prefixed names: + +| Protocol | Description | +|----------|-------------| +| `kubernetes.io/h2c` | HTTP/2 over cleartext as described in [RFC 7540](https://www.rfc-editor.org/rfc/rfc7540) | + +### Multi-port Services + +For some Services, you need to expose more than one port. +Kubernetes lets you configure multiple port definitions on a Service object. +When using multiple ports for a Service, you must give all of your ports names +so that these are unambiguous. +For example: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp + ports: + - name: http + protocol: TCP + port: 80 + targetPort: 9376 + - name: https + protocol: TCP + port: 443 + targetPort: 9377 +``` + +{{< note >}} +As with Kubernetes {{< glossary_tooltip term_id="name" text="names">}} in general, names for ports +must only contain lowercase alphanumeric characters and `-`. Port names must +also start and end with an alphanumeric character. + +For example, the names `123-abc` and `web` are valid, but `123_abc` and `-web` are not. +{{< /note >}} + +## Service type {#publishing-services-service-types} + +For some parts of your application (for example, frontends) you may want to expose a +Service onto an external IP address, one that's accessible from outside of your +cluster. + +Kubernetes Service types allow you to specify what kind of Service you want. + +The available `type` values and their behaviors are: + +[`ClusterIP`](#type-clusterip) +: Exposes the Service on a cluster-internal IP. Choosing this value + makes the Service only reachable from within the cluster. This is the + default that is used if you don't explicitly specify a `type` for a Service. + You can expose the Service to the public internet using an + [Ingress](/docs/concepts/services-networking/ingress/) or a + [Gateway](https://gateway-api.sigs.k8s.io/). + +[`NodePort`](#type-nodeport) +: Exposes the Service on each Node's IP at a static port (the `NodePort`). + To make the node port available, Kubernetes sets up a cluster IP address, + the same as if you had requested a Service of `type: ClusterIP`. + +[`LoadBalancer`](#loadbalancer) +: Exposes the Service externally using an external load balancer. Kubernetes + does not directly offer a load balancing component; you must provide one, or + you can integrate your Kubernetes cluster with a cloud provider. + +[`ExternalName`](#externalname) +: Maps the Service to the contents of the `externalName` field (for example, + to the hostname `api.foo.bar.example`). The mapping configures your cluster's + DNS server to return a `CNAME` record with that external hostname value. + No proxying of any kind is set up. + +The `type` field in the Service API is designed as nested functionality - each level +adds to the previous. However there is an exception to this nested design. You can +define a `LoadBalancer` Service by +[disabling the load balancer `NodePort` allocation](/docs/concepts/services-networking/service/#load-balancer-nodeport-allocation). + +### `type: ClusterIP` {#type-clusterip} + +This default Service type assigns an IP address from a pool of IP addresses that +your cluster has reserved for that purpose. + +Several of the other types for Service build on the `ClusterIP` type as a +foundation. + +If you define a Service that has the `.spec.clusterIP` set to `"None"` then +Kubernetes does not assign an IP address. See [headless Services](#headless-services) +for more information. + +#### Choosing your own IP address + +You can specify your own cluster IP address as part of a `Service` creation +request. To do this, set the `.spec.clusterIP` field. For example, if you +already have an existing DNS entry that you wish to reuse, or legacy systems +that are configured for a specific IP address and difficult to re-configure. + +The IP address that you choose must be a valid IPv4 or IPv6 address from within the +`service-cluster-ip-range` CIDR range that is configured for the API server. +If you try to create a Service with an invalid `clusterIP` address value, the API +server will return a 422 HTTP status code to indicate that there's a problem. + +Read [avoiding collisions](/docs/reference/networking/virtual-ips/#avoiding-collisions) +to learn how Kubernetes helps reduce the risk and impact of two different Services +both trying to use the same IP address. + +### `type: NodePort` {#type-nodeport} + +If you set the `type` field to `NodePort`, the Kubernetes control plane +allocates a port from a range specified by `--service-node-port-range` flag (default: 30000-32767). +Each node proxies that port (the same port number on every Node) into your Service. +Your Service reports the allocated port in its `.spec.ports[*].nodePort` field. + +Using a NodePort gives you the freedom to set up your own load balancing solution, +to configure environments that are not fully supported by Kubernetes, or even +to expose one or more nodes' IP addresses directly. + +For a node port Service, Kubernetes additionally allocates a port (TCP, UDP or +SCTP to match the protocol of the Service). Every node in the cluster configures +itself to listen on that assigned port and to forward traffic to one of the ready +endpoints associated with that Service. You'll be able to contact the `type: NodePort` +Service, from outside the cluster, by connecting to any node using the appropriate +protocol (for example: TCP), and the appropriate port (as assigned to that Service). + +#### Choosing your own port {#nodeport-custom-port} + +If you want a specific port number, you can specify a value in the `nodePort` +field. The control plane will either allocate you that port or report that +the API transaction failed. +This means that you need to take care of possible port collisions yourself. +You also have to use a valid port number, one that's inside the range configured +for NodePort use. + +Here is an example manifest for a Service of `type: NodePort` that specifies +a NodePort value (30007, in this example): + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + type: NodePort + selector: + app.kubernetes.io/name: MyApp + ports: + - port: 80 + # By default and for convenience, the `targetPort` is set to + # the same value as the `port` field. + targetPort: 80 + # Optional field + # By default and for convenience, the Kubernetes control plane + # will allocate a port from a range (default: 30000-32767) + nodePort: 30007 +``` + +#### Reserve Nodeport ranges to avoid collisions {#avoid-nodeport-collisions} + +{{< feature-state for_k8s_version="v1.29" state="stable" >}} + +The policy for assigning ports to NodePort services applies to both the auto-assignment and +the manual assignment scenarios. When a user wants to create a NodePort service that +uses a specific port, the target port may conflict with another port that has already been assigned. + +To avoid this problem, the port range for NodePort services is divided into two bands. +Dynamic port assignment uses the upper band by default, and it may use the lower band once the +upper band has been exhausted. Users can then allocate from the lower band with a lower risk of port collision. + +#### Custom IP address configuration for `type: NodePort` Services {#service-nodeport-custom-listen-address} + +You can set up nodes in your cluster to use a particular IP address for serving node port +services. You might want to do this if each node is connected to multiple networks (for example: +one network for application traffic, and another network for traffic between nodes and the +control plane). + +If you want to specify particular IP address(es) to proxy the port, you can set the +`--nodeport-addresses` flag for kube-proxy or the equivalent `nodePortAddresses` +field of the [kube-proxy configuration file](/docs/reference/config-api/kube-proxy-config.v1alpha1/) +to particular IP block(s). + +This flag takes a comma-delimited list of IP blocks (e.g. `10.0.0.0/8`, `192.0.2.0/25`) +to specify IP address ranges that kube-proxy should consider as local to this node. + +For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8` flag, +kube-proxy only selects the loopback interface for NodePort Services. +The default for `--nodeport-addresses` is an empty list. +This means that kube-proxy should consider all available network interfaces for NodePort. +(That's also compatible with earlier Kubernetes releases.) +{{< note >}} +This Service is visible as `:spec.ports[*].nodePort` and `.spec.clusterIP:spec.ports[*].port`. +If the `--nodeport-addresses` flag for kube-proxy or the equivalent field +in the kube-proxy configuration file is set, `` would be a filtered +node IP address (or possibly IP addresses). +{{< /note >}} + +### `type: LoadBalancer` {#loadbalancer} + +On cloud providers which support external load balancers, setting the `type` +field to `LoadBalancer` provisions a load balancer for your Service. +The actual creation of the load balancer happens asynchronously, and +information about the provisioned balancer is published in the Service's +`.status.loadBalancer` field. +For example: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + clusterIP: 10.0.171.239 + type: LoadBalancer +status: + loadBalancer: + ingress: + - ip: 192.0.2.127 +``` + +Traffic from the external load balancer is directed at the backend Pods. The cloud +provider decides how it is load balanced. + +To implement a Service of `type: LoadBalancer`, Kubernetes typically starts off +by making the changes that are equivalent to you requesting a Service of +`type: NodePort`. The cloud-controller-manager component then configures the external +load balancer to forward traffic to that assigned node port. + +You can configure a load balanced Service to +[omit](#load-balancer-nodeport-allocation) assigning a node port, provided that the +cloud provider implementation supports this. + +Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer is created +with the user-specified `loadBalancerIP`. If the `loadBalancerIP` field is not specified, +the load balancer is set up with an ephemeral IP address. If you specify a `loadBalancerIP` +but your cloud provider does not support the feature, the `loadbalancerIP` field that you +set is ignored. + + +{{< note >}} +The`.spec.loadBalancerIP` field for a Service was deprecated in Kubernetes v1.24. + +This field was under-specified and its meaning varies across implementations. +It also cannot support dual-stack networking. This field may be removed in a future API version. + +If you're integrating with a provider that supports specifying the load balancer IP address(es) +for a Service via a (provider specific) annotation, you should switch to doing that. + +If you are writing code for a load balancer integration with Kubernetes, avoid using this field. +You can integrate with [Gateway](https://gateway-api.sigs.k8s.io/) rather than Service, or you +can define your own (provider specific) annotations on the Service that specify the equivalent detail. +{{< /note >}} + +#### Load balancers with mixed protocol types + +{{< feature-state for_k8s_version="v1.26" state="stable" >}} + +By default, for LoadBalancer type of Services, when there is more than one port defined, all +ports must have the same protocol, and the protocol must be one which is supported +by the cloud provider. + +The feature gate `MixedProtocolLBService` (enabled by default for the kube-apiserver as of v1.24) allows the use of +different protocols for LoadBalancer type of Services, when there is more than one port defined. + +{{< note >}} +The set of protocols that can be used for load balanced Services is defined by your +cloud provider; they may impose restrictions beyond what the Kubernetes API enforces. +{{< /note >}} + +#### Disabling load balancer NodePort allocation {#load-balancer-nodeport-allocation} + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +You can optionally disable node port allocation for a Service of `type: LoadBalancer`, by setting +the field `spec.allocateLoadBalancerNodePorts` to `false`. This should only be used for load balancer implementations +that route traffic directly to pods as opposed to using node ports. By default, `spec.allocateLoadBalancerNodePorts` +is `true` and type LoadBalancer Services will continue to allocate node ports. If `spec.allocateLoadBalancerNodePorts` +is set to `false` on an existing Service with allocated node ports, those node ports will **not** be de-allocated automatically. +You must explicitly remove the `nodePorts` entry in every Service port to de-allocate those node ports. + +#### Specifying class of load balancer implementation {#load-balancer-class} + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +For a Service with `type` set to `LoadBalancer`, the `.spec.loadBalancerClass` field +enables you to use a load balancer implementation other than the cloud provider default. + +By default, `.spec.loadBalancerClass` is not set and a `LoadBalancer` +type of Service uses the cloud provider's default load balancer implementation if the +cluster is configured with a cloud provider using the `--cloud-provider` component +flag. + +If you specify `.spec.loadBalancerClass`, it is assumed that a load balancer +implementation that matches the specified class is watching for Services. +Any default load balancer implementation (for example, the one provided by +the cloud provider) will ignore Services that have this field set. +`spec.loadBalancerClass` can be set on a Service of type `LoadBalancer` only. +Once set, it cannot be changed. +The value of `spec.loadBalancerClass` must be a label-style identifier, +with an optional prefix such as "`internal-vip`" or "`example.com/internal-vip`". +Unprefixed names are reserved for end-users. + +#### Specifying IPMode of load balancer status {#load-balancer-ip-mode} + +{{< feature-state for_k8s_version="v1.29" state="alpha" >}} + +Starting as Alpha in Kubernetes 1.29, +a [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +named `LoadBalancerIPMode` allows you to set the `.status.loadBalancer.ingress.ipMode` +for a Service with `type` set to `LoadBalancer`. +The `.status.loadBalancer.ingress.ipMode` specifies how the load-balancer IP behaves. +It may be specified only when the `.status.loadBalancer.ingress.ip` field is also specified. + +There are two possible values for `.status.loadBalancer.ingress.ipMode`: "VIP" and "Proxy". +The default value is "VIP" meaning that traffic is delivered to the node +with the destination set to the load-balancer's IP and port. +There are two cases when setting this to "Proxy", depending on how the load-balancer +from the cloud provider delivers the traffics: + +- If the traffic is delivered to the node then DNATed to the pod, the destination would be set to the node's IP and node port; +- If the traffic is delivered directly to the pod, the destination would be set to the pod's IP and port. + +Service implementations may use this information to adjust traffic routing. + +#### Internal load balancer + +In a mixed environment it is sometimes necessary to route traffic from Services inside the same +(virtual) network address block. + +In a split-horizon DNS environment you would need two Services to be able to route both external +and internal traffic to your endpoints. + +To set an internal load balancer, add one of the following annotations to your Service +depending on the cloud service provider you're using: + +{{< tabs name="service_tabs" >}} +{{% tab name="Default" %}} +Select one of the tabs. +{{% /tab %}} + +{{% tab name="GCP" %}} + +```yaml +metadata: + name: my-service + annotations: + networking.gke.io/load-balancer-type: "Internal" +``` +{{% /tab %}} +{{% tab name="AWS" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/aws-load-balancer-internal: "true" +``` + +{{% /tab %}} +{{% tab name="Azure" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/azure-load-balancer-internal: "true" +``` + +{{% /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 +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/openstack-internal-load-balancer: "true" +``` + +{{% /tab %}} +{{% tab name="Baidu Cloud" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true" +``` + +{{% /tab %}} +{{% tab name="Tencent Cloud" %}} + +```yaml +metadata: + annotations: + service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx +``` + +{{% /tab %}} +{{% tab name="Alibaba Cloud" %}} + +```yaml +metadata: + annotations: + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" +``` + +{{% /tab %}} +{{% tab name="OCI" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/oci-load-balancer-internal: true +``` +{{% /tab %}} +{{< /tabs >}} + +### `type: ExternalName` {#externalname} + +Services of type ExternalName map a Service to a DNS name, not to a typical selector such as +`my-service` or `cassandra`. You specify these Services with the `spec.externalName` parameter. + +This Service definition, for example, maps +the `my-service` Service in the `prod` namespace to `my.database.example.com`: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service + namespace: prod +spec: + type: ExternalName + externalName: my.database.example.com +``` + +{{< note >}} +A Service of `type: ExternalName` accepts an IPv4 address string, +but treats that string as a DNS name comprised of digits, +not as an IP address (the internet does not however allow such names in DNS). +Services with external names that resemble IPv4 +addresses are not resolved by DNS servers. + +If you want to map a Service directly to a specific IP address, consider using +[headless Services](#headless-services). +{{< /note >}} + +When looking up the host `my-service.prod.svc.cluster.local`, the cluster DNS Service +returns a `CNAME` record with the value `my.database.example.com`. Accessing +`my-service` works in the same way as other Services but with the crucial +difference that redirection happens at the DNS level rather than via proxying or +forwarding. Should you later decide to move your database into your cluster, you +can start its Pods, add appropriate selectors or endpoints, and change the +Service's `type`. + +{{< caution >}} +You may have trouble using ExternalName for some common protocols, including HTTP and HTTPS. +If you use ExternalName then the hostname used by clients inside your cluster is different from +the name that the ExternalName references. + +For protocols that use hostnames this difference may lead to errors or unexpected responses. +HTTP requests will have a `Host:` header that the origin server does not recognize; +TLS servers will not be able to provide a certificate matching the hostname that the client connected to. +{{< /caution >}} + +## Headless Services + +Sometimes you don't need load-balancing and a single Service IP. In +this case, you can create what are termed _headless Services_, by explicitly +specifying `"None"` for the cluster IP address (`.spec.clusterIP`). + +You can use a headless Service to interface with other service discovery mechanisms, +without being tied to Kubernetes' implementation. + +For headless Services, a cluster IP is not allocated, kube-proxy does not handle +these Services, and there is no load balancing or proxying done by the platform +for them. How DNS is automatically configured depends on whether the Service has +selectors defined: + +### With selectors + +For headless Services that define selectors, the endpoints controller creates +EndpointSlices in the Kubernetes API, and modifies the DNS configuration to return +A or AAAA records (IPv4 or IPv6 addresses) that point directly to the Pods backing the Service. + +### Without selectors + +For headless Services that do not define selectors, the control plane does +not create EndpointSlice objects. However, the DNS system looks for and configures +either: + +* DNS CNAME records for [`type: ExternalName`](#externalname) Services. +* DNS A / AAAA records for all IP addresses of the Service's ready endpoints, + for all Service types other than `ExternalName`. + * For IPv4 endpoints, the DNS system creates A records. + * For IPv6 endpoints, the DNS system creates AAAA records. + +When you define a headless Service without a selector, the `port` must +match the `targetPort`. + +## Discovering services + +For clients running inside your cluster, Kubernetes supports two primary modes of +finding a Service: environment variables and DNS. + +### Environment variables + +When a Pod is run on a Node, the kubelet adds a set of environment variables +for each active Service. It adds `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, +where the Service name is upper-cased and dashes are converted to underscores. + + +For example, the Service `redis-primary` which exposes TCP port 6379 and has been +allocated cluster IP address 10.0.0.11, produces the following environment +variables: + +```shell +REDIS_PRIMARY_SERVICE_HOST=10.0.0.11 +REDIS_PRIMARY_SERVICE_PORT=6379 +REDIS_PRIMARY_PORT=tcp://10.0.0.11:6379 +REDIS_PRIMARY_PORT_6379_TCP=tcp://10.0.0.11:6379 +REDIS_PRIMARY_PORT_6379_TCP_PROTO=tcp +REDIS_PRIMARY_PORT_6379_TCP_PORT=6379 +REDIS_PRIMARY_PORT_6379_TCP_ADDR=10.0.0.11 +``` + +{{< note >}} +When you have a Pod that needs to access a Service, and you are using +the environment variable method to publish the port and cluster IP to the client +Pods, you must create the Service *before* the client Pods come into existence. +Otherwise, those client Pods won't have their environment variables populated. + +If you only use DNS to discover the cluster IP for a Service, you don't need to +worry about this ordering issue. +{{< /note >}} + +Kubernetes also supports and provides variables that are compatible with Docker +Engine's "_[legacy container links](https://docs.docker.com/network/links/)_" feature. +You can read [`makeLinkVariables`](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) +to see how this is implemented in Kubernetes. + +### DNS + +You can (and almost always should) set up a DNS service for your Kubernetes +cluster using an [add-on](/docs/concepts/cluster-administration/addons/). + +A cluster-aware DNS server, such as CoreDNS, watches the Kubernetes API for new +Services and creates a set of DNS records for each one. If DNS has been enabled +throughout your cluster then all Pods should automatically be able to resolve +Services by their DNS name. + +For example, if you have a Service called `my-service` in a Kubernetes +namespace `my-ns`, the control plane and the DNS Service acting together +create a DNS record for `my-service.my-ns`. Pods in the `my-ns` namespace +should be able to find the service by doing a name lookup for `my-service` +(`my-service.my-ns` would also work). + +Pods in other namespaces must qualify the name as `my-service.my-ns`. These names +will resolve to the cluster IP assigned for the Service. + +Kubernetes also supports DNS SRV (Service) records for named ports. If the +`my-service.my-ns` Service has a port named `http` with the protocol set to +`TCP`, you can do a DNS SRV query for `_http._tcp.my-service.my-ns` to discover +the port number for `http`, as well as the IP address. + +The Kubernetes DNS server is the only way to access `ExternalName` Services. +You can find more information about `ExternalName` resolution in +[DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/). + + + + + + + + + + +## Virtual IP addressing mechanism + +Read [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/) explains the +mechanism Kubernetes provides to expose a Service with a virtual IP address. + +### Traffic policies + +You can set the `.spec.internalTrafficPolicy` and `.spec.externalTrafficPolicy` fields +to control how Kubernetes routes traffic to healthy (“ready”) backends. + +See [Traffic Policies](/docs/reference/networking/virtual-ips/#traffic-policies) for more details. + +### Session stickiness + +If you want to make sure that connections from a particular client are passed to +the same Pod each time, you can configure session affinity based on the client's +IP address. Read [session affinity](/docs/reference/networking/virtual-ips/#session-affinity) +to learn more. + +## External IPs + +If there are external IPs that route to one or more cluster nodes, Kubernetes Services +can be exposed on those `externalIPs`. When network traffic arrives into the cluster, with +the external IP (as destination IP) and the port matching that Service, rules and routes +that Kubernetes has configured ensure that the traffic is routed to one of the endpoints +for that Service. + +When you define a Service, you can specify `externalIPs` for any +[service type](#publishing-services-service-types). +In the example below, the Service named `"my-service"` can be accessed by clients using TCP, +on `"198.51.100.32:80"` (calculated from `.spec.externalIPs[]` and `.spec.ports[].port`). + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp + ports: + - name: http + protocol: TCP + port: 80 + targetPort: 49152 + externalIPs: + - 198.51.100.32 +``` + +{{< note >}} +Kubernetes does not manage allocation of `externalIPs`; these are the responsibility +of the cluster administrator. +{{< /note >}} + +## API Object + +Service is a top-level resource in the Kubernetes REST API. You can find more details +about the [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core). + +## {{% heading "whatsnext" %}} + +Learn more about Services and how they fit into Kubernetes: + +* Follow the [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) + tutorial. +* Read about [Ingress](/docs/concepts/services-networking/ingress/), which + exposes HTTP and HTTPS routes from outside the cluster to Services within + your cluster. +* Read about [Gateway](/docs/concepts/services-networking/gateway/), an extension to + Kubernetes that provides more flexibility than Ingress. + +For more context, read the following: + +* [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/) +* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) +* [Service API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) +* [EndpointSlice API reference](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) +* [Endpoint API reference (legacy)](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) diff --git a/content/uk/docs/concepts/storage/_index.md b/content/uk/docs/concepts/storage/_index.md index 23108a421cb1a..7106dfc283494 100644 --- a/content/uk/docs/concepts/storage/_index.md +++ b/content/uk/docs/concepts/storage/_index.md @@ -1,4 +1,6 @@ --- -title: "Сховища інформації" +title: "Зберігання" weight: 70 +description: > + Способи надання як довгострокового, так і тимчасового зберігання даних для `Pod`ів у вашому кластері. --- diff --git a/content/uk/docs/concepts/storage/persistent-volumes.md b/content/uk/docs/concepts/storage/persistent-volumes.md new file mode 100644 index 0000000000000..d317bb7a8cb79 --- /dev/null +++ b/content/uk/docs/concepts/storage/persistent-volumes.md @@ -0,0 +1,1289 @@ +--- +reviewers: +- jsafrane +- saad-ali +- thockin +- msau42 +- xing-yang +title: Постійні томи +feature: + title: Оркестрація зберігання + description: > + Автоматичне монтування системи зберігання за вашим вибором, будь то локальне зберігання, публічний постачальник хмарних послуг або мережева система зберігання, така як iSCSI або NFS. +content_type: concept +weight: 20 +--- + + + +This document describes _persistent volumes_ in Kubernetes. Familiarity with +[volumes](/docs/concepts/storage/volumes/), [StorageClasses](/docs/concepts/storage/storage-classes/) +and [VolumeAttributesClasses](/docs/concepts/storage/volume-attributes-classes/) is suggested. + + + +## Introduction + +Managing storage is a distinct problem from managing compute instances. +The PersistentVolume subsystem provides an API for users and administrators +that abstracts details of how storage is provided from how it is consumed. +To do this, we introduce two new API resources: PersistentVolume and PersistentVolumeClaim. + +A _PersistentVolume_ (PV) is a piece of storage in the cluster that has been +provisioned by an administrator or dynamically provisioned using +[Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in +the cluster just like a node is a cluster resource. PVs are volume plugins like +Volumes, but have a lifecycle independent of any individual Pod that uses the PV. +This API object captures the details of the implementation of the storage, be that +NFS, iSCSI, or a cloud-provider-specific storage system. + +A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar +to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can +request specific levels of resources (CPU and Memory). Claims can request specific +size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany, +ReadWriteMany, or ReadWriteOncePod, see [AccessModes](#access-modes)). + +While PersistentVolumeClaims allow a user to consume abstract storage resources, +it is common that users need PersistentVolumes with varying properties, such as +performance, for different problems. Cluster administrators need to be able to +offer a variety of PersistentVolumes that differ in more ways than size and access +modes, without exposing users to the details of how those volumes are implemented. +For these needs, there is the _StorageClass_ resource. + +See the [detailed walkthrough with working examples](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). + +## Lifecycle of a volume and claim + +PVs are resources in the cluster. PVCs are requests for those resources and also act +as claim checks to the resource. The interaction between PVs and PVCs follows this lifecycle: + +### Provisioning + +There are two ways PVs may be provisioned: statically or dynamically. + +#### Static + +A cluster administrator creates a number of PVs. They carry the details of the +real storage, which is available for use by cluster users. They exist in the +Kubernetes API and are available for consumption. + +#### Dynamic + +When none of the static PVs the administrator created match a user's PersistentVolumeClaim, +the cluster may try to dynamically provision a volume specially for the PVC. +This provisioning is based on StorageClasses: the PVC must request a +[storage class](/docs/concepts/storage/storage-classes/) and +the administrator must have created and configured that class for dynamic +provisioning to occur. Claims that request the class `""` effectively disable +dynamic provisioning for themselves. + +To enable dynamic storage provisioning based on storage class, the cluster administrator +needs to enable the `DefaultStorageClass` +[admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) +on the API server. This can be done, for example, by ensuring that `DefaultStorageClass` is +among the comma-delimited, ordered list of values for the `--enable-admission-plugins` flag of +the API server component. For more information on API server command-line flags, +check [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) documentation. + +### Binding + +A user creates, or in the case of dynamic provisioning, has already created, +a PersistentVolumeClaim with a specific amount of storage requested and with +certain access modes. A control loop in the control plane watches for new PVCs, finds +a matching PV (if possible), and binds them together. If a PV was dynamically +provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, +the user will always get at least what they asked for, but the volume may be in +excess of what was requested. Once bound, PersistentVolumeClaim binds are exclusive, +regardless of how they were bound. A PVC to PV binding is a one-to-one mapping, +using a ClaimRef which is a bi-directional binding between the PersistentVolume +and the PersistentVolumeClaim. + +Claims will remain unbound indefinitely if a matching volume does not exist. +Claims will be bound as matching volumes become available. For example, a +cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. +The PVC can be bound when a 100Gi PV is added to the cluster. + +### Using + +Pods use claims as volumes. The cluster inspects the claim to find the bound +volume and mounts that volume for a Pod. For volumes that support multiple +access modes, the user specifies which mode is desired when using their claim +as a volume in a Pod. + +Once a user has a claim and that claim is bound, the bound PV belongs to the +user for as long as they need it. Users schedule Pods and access their claimed +PVs by including a `persistentVolumeClaim` section in a Pod's `volumes` block. +See [Claims As Volumes](#claims-as-volumes) for more details on this. + +### Storage Object in Use Protection + +The purpose of the Storage Object in Use Protection feature is to ensure that +PersistentVolumeClaims (PVCs) in active use by a Pod and PersistentVolume (PVs) +that are bound to PVCs are not removed from the system, as this may result in data loss. + +{{< note >}} +PVC is in active use by a Pod when a Pod object exists that is using the PVC. +{{< /note >}} + +If a user deletes a PVC in active use by a Pod, the PVC is not removed immediately. +PVC removal is postponed until the PVC is no longer actively used by any Pods. Also, +if an admin deletes a PV that is bound to a PVC, the PV is not removed immediately. +PV removal is postponed until the PV is no longer bound to a PVC. + +You can see that a PVC is protected when the PVC's status is `Terminating` and the +`Finalizers` list includes `kubernetes.io/pvc-protection`: + +```shell +kubectl describe pvc hostpath +Name: hostpath +Namespace: default +StorageClass: example-hostpath +Status: Terminating +Volume: +Labels: +Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath + volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath +Finalizers: [kubernetes.io/pvc-protection] +... +``` + +You can see that a PV is protected when the PV's status is `Terminating` and +the `Finalizers` list includes `kubernetes.io/pv-protection` too: + +```shell +kubectl describe pv task-pv-volume +Name: task-pv-volume +Labels: type=local +Annotations: +Finalizers: [kubernetes.io/pv-protection] +StorageClass: standard +Status: Terminating +Claim: +Reclaim Policy: Delete +Access Modes: RWO +Capacity: 1Gi +Message: +Source: + Type: HostPath (bare host directory volume) + Path: /tmp/data + HostPathType: +Events: +``` + +### Reclaiming + +When a user is done with their volume, they can delete the PVC objects from the +API that allows reclamation of the resource. The reclaim policy for a PersistentVolume +tells the cluster what to do with the volume after it has been released of its claim. +Currently, volumes can either be Retained, Recycled, or Deleted. + +#### Retain + +The `Retain` reclaim policy allows for manual reclamation of the resource. +When the PersistentVolumeClaim is deleted, the PersistentVolume still exists +and the volume is considered "released". But it is not yet available for +another claim because the previous claimant's data remains on the volume. +An administrator can manually reclaim the volume with the following steps. + +1. Delete the PersistentVolume. The associated storage asset in external infrastructure + still exists after the PV is deleted. +1. Manually clean up the data on the associated storage asset accordingly. +1. Manually delete the associated storage asset. + +If you want to reuse the same storage asset, create a new PersistentVolume with +the same storage asset definition. + +#### Delete + +For volume plugins that support the `Delete` reclaim policy, deletion removes +both the PersistentVolume object from Kubernetes, as well as the associated +storage asset in the external infrastructure. Volumes that were dynamically provisioned +inherit the [reclaim policy of their StorageClass](#reclaim-policy), which +defaults to `Delete`. The administrator should configure the StorageClass +according to users' expectations; otherwise, the PV must be edited or +patched after it is created. See +[Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). + +#### Recycle + +{{< warning >}} +The `Recycle` reclaim policy is deprecated. Instead, the recommended approach +is to use dynamic provisioning. +{{< /warning >}} + +If supported by the underlying volume plugin, the `Recycle` reclaim policy performs +a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim. + +However, an administrator can configure a custom recycler Pod template using +the Kubernetes controller manager command line arguments as described in the +[reference](/docs/reference/command-line-tools-reference/kube-controller-manager/). +The custom recycler Pod template must contain a `volumes` specification, as +shown in the example below: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pv-recycler + namespace: default +spec: + restartPolicy: Never + volumes: + - name: vol + hostPath: + path: /any/path/it/will/be/replaced + containers: + - name: pv-recycler + image: "registry.k8s.io/busybox" + command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] + volumeMounts: + - name: vol + mountPath: /scrub +``` + +However, the particular path specified in the custom recycler Pod template in the +`volumes` part is replaced with the particular path of the volume that is being recycled. + +### PersistentVolume deletion protection finalizer +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +Finalizers can be added on a PersistentVolume to ensure that PersistentVolumes +having `Delete` reclaim policy are deleted only after the backing storage are deleted. + +The newly introduced finalizers `kubernetes.io/pv-controller` and +`external-provisioner.volume.kubernetes.io/finalizer` +are only added to dynamically provisioned volumes. + +The finalizer `kubernetes.io/pv-controller` is added to in-tree plugin volumes. +The following is an example + +```shell +kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 +Name: pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 +Labels: +Annotations: kubernetes.io/createdby: vsphere-volume-dynamic-provisioner + pv.kubernetes.io/bound-by-controller: yes + pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume +Finalizers: [kubernetes.io/pv-protection kubernetes.io/pv-controller] +StorageClass: vcp-sc +Status: Bound +Claim: default/vcp-pvc-1 +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 1Gi +Node Affinity: +Message: +Source: + Type: vSphereVolume (a Persistent Disk resource in vSphere) + VolumePath: [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk + FSType: ext4 + StoragePolicyName: vSAN Default Storage Policy +Events: +``` + +The finalizer `external-provisioner.volume.kubernetes.io/finalizer` is added for CSI volumes. +The following is an example: + +```shell +Name: pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d +Labels: +Annotations: pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com +Finalizers: [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer] +StorageClass: fast +Status: Bound +Claim: demo-app/nginx-logs +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 200Mi +Node Affinity: +Message: +Source: + Type: CSI (a Container Storage Interface (CSI) volume source) + Driver: csi.vsphere.vmware.com + FSType: ext4 + VolumeHandle: 44830fa8-79b4-406b-8b58-621ba25353fd + ReadOnly: false + VolumeAttributes: storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com + type=vSphere CNS Block Volume +Events: +``` + +When the `CSIMigration{provider}` feature flag is enabled for a specific in-tree volume plugin, +the `kubernetes.io/pv-controller` finalizer is replaced by the +`external-provisioner.volume.kubernetes.io/finalizer` finalizer. + +### Reserving a PersistentVolume + +The control plane can [bind PersistentVolumeClaims to matching PersistentVolumes](#binding) +in the cluster. However, if you want a PVC to bind to a specific PV, you need to pre-bind them. + +By specifying a PersistentVolume in a PersistentVolumeClaim, you declare a binding +between that specific PV and PVC. If the PersistentVolume exists and has not reserved +PersistentVolumeClaims through its `claimRef` field, then the PersistentVolume and +PersistentVolumeClaim will be bound. + +The binding happens regardless of some volume matching criteria, including node affinity. +The control plane still checks that [storage class](/docs/concepts/storage/storage-classes/), +access modes, and requested storage size are valid. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: foo-pvc + namespace: foo +spec: + storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will be set + volumeName: foo-pv + ... +``` + +This method does not guarantee any binding privileges to the PersistentVolume. +If other PersistentVolumeClaims could use the PV that you specify, you first +need to reserve that storage volume. Specify the relevant PersistentVolumeClaim +in the `claimRef` field of the PV so that other PVCs can not bind to it. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: foo-pv +spec: + storageClassName: "" + claimRef: + name: foo-pvc + namespace: foo + ... +``` + +This is useful if you want to consume PersistentVolumes that have their `persistentVolumeReclaimPolicy` set +to `Retain`, including cases where you are reusing an existing PV. + +### Expanding Persistent Volumes Claims + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Support for expanding PersistentVolumeClaims (PVCs) is enabled by default. You can expand +the following types of volumes: + +* azureFile (deprecated) +* {{< glossary_tooltip text="csi" term_id="csi" >}} +* flexVolume (deprecated) +* rbd (deprecated) +* portworxVolume (deprecated) + +You can only expand a PVC if its storage class's `allowVolumeExpansion` field is set to true. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: example-vol-default +provisioner: vendor-name.example/magicstorage +parameters: + resturl: "http://192.168.10.100:8080" + restuser: "" + secretNamespace: "" + secretName: "" +allowVolumeExpansion: true +``` + +To request a larger volume for a PVC, edit the PVC object and specify a larger +size. This triggers expansion of the volume that backs the underlying PersistentVolume. A +new PersistentVolume is never created to satisfy the claim. Instead, an existing volume is resized. + +{{< warning >}} +Directly editing the size of a PersistentVolume can prevent an automatic resize of that volume. +If you edit the capacity of a PersistentVolume, and then edit the `.spec` of a matching +PersistentVolumeClaim to make the size of the PersistentVolumeClaim match the PersistentVolume, +then no storage resize happens. +The Kubernetes control plane will see that the desired state of both resources matches, +conclude that the backing volume size has been manually +increased and that no resize is necessary. +{{< /warning >}} + +#### CSI Volume expansion + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Support for expanding CSI volumes is enabled by default but it also requires a +specific CSI driver to support volume expansion. Refer to documentation of the +specific CSI driver for more information. + +#### Resizing a volume containing a file system + +You can only resize volumes containing a file system if the file system is XFS, Ext3, or Ext4. + +When a volume contains a file system, the file system is only resized when a new Pod is using +the PersistentVolumeClaim in `ReadWrite` mode. File system expansion is either done when a Pod is starting up +or when a Pod is running and the underlying file system supports online expansion. + +FlexVolumes (deprecated since Kubernetes v1.23) allow resize if the driver is configured with the +`RequiresFSResize` capability to `true`. The FlexVolume can be resized on Pod restart. + +#### Resizing an in-use PersistentVolumeClaim + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +In this case, you don't need to delete and recreate a Pod or deployment that is using an existing PVC. +Any in-use PVC automatically becomes available to its Pod as soon as its file system has been expanded. +This feature has no effect on PVCs that are not in use by a Pod or deployment. You must create a Pod that +uses the PVC before the expansion can complete. + +Similar to other volume types - FlexVolume volumes can also be expanded when in-use by a Pod. + +{{< note >}} +FlexVolume resize is possible only when the underlying driver supports resize. +{{< /note >}} + +#### Recovering from Failure when Expanding Volumes + +If a user specifies a new size that is too big to be satisfied by underlying +storage system, expansion of PVC will be continuously retried until user or +cluster administrator takes some action. This can be undesirable and hence +Kubernetes provides following methods of recovering from such failures. + +{{< tabs name="recovery_methods" >}} +{{% tab name="Manually with Cluster Administrator access" %}} + +If expanding underlying storage fails, the cluster administrator can manually +recover the Persistent Volume Claim (PVC) state and cancel the resize requests. +Otherwise, the resize requests are continuously retried by the controller without +administrator intervention. + +1. Mark the PersistentVolume(PV) that is bound to the PersistentVolumeClaim(PVC) + with `Retain` reclaim policy. +2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not lose any data + when we recreate the PVC. +3. Delete the `claimRef` entry from PV specs, so as new PVC can bind to it. + This should make the PV `Available`. +4. Re-create the PVC with smaller size than PV and set `volumeName` field of the + PVC to the name of the PV. This should bind new PVC to existing PV. +5. Don't forget to restore the reclaim policy of the PV. + +{{% /tab %}} +{{% tab name="By requesting expansion to smaller size" %}} +{{% feature-state for_k8s_version="v1.23" state="alpha" %}} + +{{< note >}} +Recovery from failing PVC expansion by users is available as an alpha feature +since Kubernetes 1.23. The `RecoverVolumeExpansionFailure` feature must be +enabled for this feature to work. Refer to the +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +documentation for more information. +{{< /note >}} + +If the feature gates `RecoverVolumeExpansionFailure` is +enabled in your cluster, and expansion has failed for a PVC, you can retry expansion with a +smaller size than the previously requested value. To request a new expansion attempt with a +smaller proposed size, edit `.spec.resources` for that PVC and choose a value that is less than the +value you previously tried. +This is useful if expansion to a higher value did not succeed because of capacity constraint. +If that has happened, or you suspect that it might have, you can retry expansion by specifying a +size that is within the capacity limits of underlying storage provider. You can monitor status of +resize operation by watching `.status.allocatedResourceStatuses` and events on the PVC. + +Note that, +although you can specify a lower amount of storage than what was requested previously, +the new value must still be higher than `.status.capacity`. +Kubernetes does not support shrinking a PVC to less than its current size. +{{% /tab %}} +{{% /tabs %}} + +## Types of Persistent Volumes + +PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins: + +* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI) +* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage +* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume + (for single node testing only; WILL NOT WORK in a multi-node cluster; + consider using `local` volume instead) +* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage +* [`local`](/docs/concepts/storage/volumes/#local) - local storage devices + mounted on nodes. +* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage + +The following types of PersistentVolume are deprecated. +This means that support is still available but will be removed in a future Kubernetes release. + +* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File + (**deprecated** in v1.21) +* [`flexVolume`](/docs/concepts/storage/volumes/#flexvolume) - FlexVolume + (**deprecated** in v1.23) +* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume + (**deprecated** in v1.25) +* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume + (**deprecated** in v1.19) +* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume + (**deprecated** in v1.28) +* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume + (**deprecated** in v1.28) + +Older versions of Kubernetes also supported the following in-tree PersistentVolume types: + +* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) + (**not available** in v1.27) +* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk + (**not available** in v1.27) +* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) + (**not available** in v1.26) +* `photonPersistentDisk` - Photon controller persistent disk. + (**not available** starting v1.15) +* `scaleIO` - ScaleIO volume. + (**not available** starting v1.21) +* `flocker` - Flocker storage. + (**not available** starting v1.25) +* `quobyte` - Quobyte volume. + (**not available** starting v1.25) +* `storageos` - StorageOS volume. + (**not available** starting v1.25) + +## Persistent Volumes + +Each PV contains a spec and status, which is the specification and status of the volume. +The name of a PersistentVolume object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: pv0003 +spec: + capacity: + storage: 5Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Recycle + storageClassName: slow + mountOptions: + - hard + - nfsvers=4.1 + nfs: + path: /tmp + server: 172.17.0.2 +``` + +{{< note >}} +Helper programs relating to the volume type may be required for consumption of +a PersistentVolume within a cluster. In this example, the PersistentVolume is +of type NFS and the helper program /sbin/mount.nfs is required to support the +mounting of NFS filesystems. +{{< /note >}} + +### Capacity + +Generally, a PV will have a specific storage capacity. This is set using the PV's +`capacity` attribute which is a {{< glossary_tooltip term_id="quantity" >}} value. + +Currently, storage size is the only resource that can be set or requested. +Future attributes may include IOPS, throughput, etc. + +### Volume Mode + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +Kubernetes supports two `volumeModes` of PersistentVolumes: `Filesystem` and `Block`. + +`volumeMode` is an optional API parameter. +`Filesystem` is the default mode used when `volumeMode` parameter is omitted. + +A volume with `volumeMode: Filesystem` is *mounted* into Pods into a directory. If the volume +is backed by a block device and the device is empty, Kubernetes creates a filesystem +on the device before mounting it for the first time. + +You can set the value of `volumeMode` to `Block` to use a volume as a raw block device. +Such volume is presented into a Pod as a block device, without any filesystem on it. +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](#raw-block-volume-support) +for an example on how to use a volume with `volumeMode: Block` in a Pod. + +### Access Modes + +A PersistentVolume can be mounted on a host in any way supported by the resource +provider. As shown in the table below, providers will have different capabilities +and each PV's access modes are set to the specific modes supported by that particular +volume. For example, NFS can support multiple read/write clients, but a specific +NFS PV might be exported on the server as read-only. Each PV gets its own set of +access modes describing that specific PV's capabilities. + +The access modes are: + +`ReadWriteOnce` +: the volume can be mounted as read-write by a single node. ReadWriteOnce access + mode still can allow multiple pods to access the volume when the pods are + running on the same node. For single pod access, please see ReadWriteOncePod. + +`ReadOnlyMany` +: the volume can be mounted as read-only by many nodes. + +`ReadWriteMany` +: the volume can be mounted as read-write by many nodes. + + `ReadWriteOncePod` +: {{< feature-state for_k8s_version="v1.29" state="stable" >}} + the volume can be mounted as read-write by a single Pod. Use ReadWriteOncePod + access mode if you want to ensure that only one pod across the whole cluster can + read that PVC or write to it. + +{{< note >}} +The `ReadWriteOncePod` access mode is only supported for +{{< glossary_tooltip text="CSI" term_id="csi" >}} volumes and Kubernetes version +1.22+. To use this feature you will need to update the following +[CSI sidecars](https://kubernetes-csi.github.io/docs/sidecar-containers.html) +to these versions or greater: + +* [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0) +* [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0) +* [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0) +{{< /note >}} + +In the CLI, the access modes are abbreviated to: + +* RWO - ReadWriteOnce +* ROX - ReadOnlyMany +* RWX - ReadWriteMany +* RWOP - ReadWriteOncePod + +{{< note >}} +Kubernetes uses volume access modes to match PersistentVolumeClaims and PersistentVolumes. +In some cases, the volume access modes also constrain where the PersistentVolume can be mounted. +Volume access modes do **not** enforce write protection once the storage has been mounted. +Even if the access modes are specified as ReadWriteOnce, ReadOnlyMany, or ReadWriteMany, +they don't set any constraints on the volume. For example, even if a PersistentVolume is +created as ReadOnlyMany, it is no guarantee that it will be read-only. If the access modes +are specified as ReadWriteOncePod, the volume is constrained and can be mounted on only a single Pod. +{{< /note >}} + +> __Important!__ A volume can only be mounted using one access mode at a time, +> even if it supports many. + +| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod | +| :--- | :---: | :---: | :---: | - | +| AzureFile | ✓ | ✓ | ✓ | - | +| CephFS | ✓ | ✓ | ✓ | - | +| CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver | +| FC | ✓ | ✓ | - | - | +| FlexVolume | ✓ | ✓ | depends on the driver | - | +| HostPath | ✓ | - | - | - | +| iSCSI | ✓ | ✓ | - | - | +| NFS | ✓ | ✓ | ✓ | - | +| RBD | ✓ | ✓ | - | - | +| VsphereVolume | ✓ | - | - (works when Pods are collocated) | - | +| PortworxVolume | ✓ | - | ✓ | - | - | + +### Class + +A PV can have a class, which is specified by setting the +`storageClassName` attribute to the name of a +[StorageClass](/docs/concepts/storage/storage-classes/). +A PV of a particular class can only be bound to PVCs requesting +that class. A PV with no `storageClassName` has no class and can only be bound +to PVCs that request no particular class. + +In the past, the annotation `volume.beta.kubernetes.io/storage-class` was used instead +of the `storageClassName` attribute. This annotation is still working; however, +it will become fully deprecated in a future Kubernetes release. + +### Reclaim Policy + +Current reclaim policies are: + +* Retain -- manual reclamation +* Recycle -- basic scrub (`rm -rf /thevolume/*`) +* Delete -- delete the volume + +For Kubernetes {{< skew currentVersion >}}, only `nfs` and `hostPath` volume types support recycling. + +### Mount Options + +A Kubernetes administrator can specify additional mount options for when a +Persistent Volume is mounted on a node. + +{{< note >}} +Not all Persistent Volume types support mount options. +{{< /note >}} + +The following volume types support mount options: + +* `azureFile` +* `cephfs` (**deprecated** in v1.28) +* `cinder` (**deprecated** in v1.18) +* `iscsi` +* `nfs` +* `rbd` (**deprecated** in v1.28) +* `vsphereVolume` + +Mount options are not validated. If a mount option is invalid, the mount fails. + +In the past, the annotation `volume.beta.kubernetes.io/mount-options` was used instead +of the `mountOptions` attribute. This annotation is still working; however, +it will become fully deprecated in a future Kubernetes release. + +### Node Affinity + +{{< note >}} +For most volume types, you do not need to set this field. +You need to explicitly set this for [local](/docs/concepts/storage/volumes/#local) volumes. +{{< /note >}} + +A PV can specify node affinity to define constraints that limit what nodes this +volume can be accessed from. Pods that use a PV will only be scheduled to nodes +that are selected by the node affinity. To specify node affinity, set +`nodeAffinity` in the `.spec` of a PV. The +[PersistentVolume](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) +API reference has more details on this field. + +### Phase + +A PersistentVolume will be in one of the following phases: + +`Available` +: a free resource that is not yet bound to a claim + +`Bound` +: the volume is bound to a claim + +`Released` +: the claim has been deleted, but the associated storage resource is not yet reclaimed by the cluster + +`Failed` +: the volume has failed its (automated) reclamation + +You can see the name of the PVC bound to the PV using `kubectl describe persistentvolume `. + +#### Phase transition timestamp + +{{< feature-state for_k8s_version="v1.29" state="beta" >}} + +The `.status` field for a PersistentVolume can include an alpha `lastPhaseTransitionTime` field. This field records +the timestamp of when the volume last transitioned its phase. For newly created +volumes the phase is set to `Pending` and `lastPhaseTransitionTime` is set to +the current time. + +{{< note >}} +You need to enable the `PersistentVolumeLastPhaseTransitionTime` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +to use or see the `lastPhaseTransitionTime` field. +{{< /note >}} + +## PersistentVolumeClaims + +Each PVC contains a spec and status, which is the specification and status of the claim. +The name of a PersistentVolumeClaim object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: myclaim +spec: + accessModes: + - ReadWriteOnce + volumeMode: Filesystem + resources: + requests: + storage: 8Gi + storageClassName: slow + selector: + matchLabels: + release: "stable" + matchExpressions: + - {key: environment, operator: In, values: [dev]} +``` + +### Access Modes + +Claims use [the same conventions as volumes](#access-modes) when requesting +storage with specific access modes. + +### Volume Modes + +Claims use [the same convention as volumes](#volume-mode) to indicate the +consumption of the volume as either a filesystem or block device. + +### Resources + +Claims, like Pods, can request specific quantities of a resource. In this case, +the request is for storage. The same +[resource model](https://git.k8s.io/design-proposals-archive/scheduling/resources.md) +applies to both volumes and claims. + +### Selector + +Claims can specify a +[label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors) +to further filter the set of volumes. Only the volumes whose labels match the selector +can be bound to the claim. The selector can consist of two fields: + +* `matchLabels` - the volume must have a label with this value +* `matchExpressions` - a list of requirements made by specifying key, list of values, + and operator that relates the key and values. Valid operators include In, NotIn, + Exists, and DoesNotExist. + +All of the requirements, from both `matchLabels` and `matchExpressions`, are +ANDed together – they must all be satisfied in order to match. + +### Class + +A claim can request a particular class by specifying the name of a +[StorageClass](/docs/concepts/storage/storage-classes/) +using the attribute `storageClassName`. +Only PVs of the requested class, ones with the same `storageClassName` as the PVC, can +be bound to the PVC. + +PVCs don't necessarily have to request a class. A PVC with its `storageClassName` set +equal to `""` is always interpreted to be requesting a PV with no class, so it +can only be bound to PVs with no class (no annotation or one set equal to +`""`). A PVC with no `storageClassName` is not quite the same and is treated differently +by the cluster, depending on whether the +[`DefaultStorageClass` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) +is turned on. + +* If the admission plugin is turned on, the administrator may specify a + default StorageClass. All PVCs that have no `storageClassName` can be bound only to + PVs of that default. Specifying a default StorageClass is done by setting the + annotation `storageclass.kubernetes.io/is-default-class` equal to `true` in + a StorageClass object. If the administrator does not specify a default, the + cluster responds to PVC creation as if the admission plugin were turned off. If more than one + default StorageClass is specified, the newest default is used when the + PVC is dynamically provisioned. +* If the admission plugin is turned off, there is no notion of a default + StorageClass. All PVCs that have `storageClassName` set to `""` can be + bound only to PVs that have `storageClassName` also set to `""`. + However, PVCs with missing `storageClassName` can be updated later once + default StorageClass becomes available. If the PVC gets updated it will no + longer bind to PVs that have `storageClassName` also set to `""`. + +See [retroactive default StorageClass assignment](#retroactive-default-storageclass-assignment) for more details. + +Depending on installation method, a default StorageClass may be deployed +to a Kubernetes cluster by addon manager during installation. + +When a PVC specifies a `selector` in addition to requesting a StorageClass, +the requirements are ANDed together: only a PV of the requested class and with +the requested labels may be bound to the PVC. + +{{< note >}} +Currently, a PVC with a non-empty `selector` can't have a PV dynamically provisioned for it. +{{< /note >}} + +In the past, the annotation `volume.beta.kubernetes.io/storage-class` was used instead +of `storageClassName` attribute. This annotation is still working; however, +it won't be supported in a future Kubernetes release. + +#### Retroactive default StorageClass assignment + +{{< feature-state for_k8s_version="v1.28" state="stable" >}} + +You can create a PersistentVolumeClaim without specifying a `storageClassName` +for the new PVC, and you can do so even when no default StorageClass exists +in your cluster. In this case, the new PVC creates as you defined it, and the +`storageClassName` of that PVC remains unset until default becomes available. + +When a default StorageClass becomes available, the control plane identifies any +existing PVCs without `storageClassName`. For the PVCs that either have an empty +value for `storageClassName` or do not have this key, the control plane then +updates those PVCs to set `storageClassName` to match the new default StorageClass. +If you have an existing PVC where the `storageClassName` is `""`, and you configure +a default StorageClass, then this PVC will not get updated. + +In order to keep binding to PVs with `storageClassName` set to `""` +(while a default StorageClass is present), you need to set the `storageClassName` +of the associated PVC to `""`. + +This behavior helps administrators change default StorageClass by removing the +old one first and then creating or setting another one. This brief window while +there is no default causes PVCs without `storageClassName` created at that time +to not have any default, but due to the retroactive default StorageClass +assignment this way of changing defaults is safe. + +## Claims As Volumes + +Pods access storage by using the claim as a volume. Claims must exist in the +same namespace as the Pod using the claim. The cluster finds the claim in the +Pod's namespace and uses it to get the PersistentVolume backing the claim. +The volume is then mounted to the host and into the Pod. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: myfrontend + image: nginx + volumeMounts: + - mountPath: "/var/www/html" + name: mypd + volumes: + - name: mypd + persistentVolumeClaim: + claimName: myclaim +``` + +### A Note on Namespaces + +PersistentVolumes binds are exclusive, and since PersistentVolumeClaims are +namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only +possible within one namespace. + +### PersistentVolumes typed `hostPath` + +A `hostPath` PersistentVolume uses a file or directory on the Node to emulate +network-attached storage. See +[an example of `hostPath` typed volume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). + +## Raw Block Volume Support + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +The following volume plugins support raw block volumes, including dynamic provisioning where +applicable: + +* CSI +* FC (Fibre Channel) +* iSCSI +* Local volume +* OpenStack Cinder +* RBD (deprecated) +* RBD (Ceph Block Device; deprecated) +* VsphereVolume + +### PersistentVolume using a Raw Block Volume {#persistent-volume-using-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: block-pv +spec: + capacity: + storage: 10Gi + accessModes: + - ReadWriteOnce + volumeMode: Block + persistentVolumeReclaimPolicy: Retain + fc: + targetWWNs: ["50060e801049cfd1"] + lun: 0 + readOnly: false +``` + +### PersistentVolumeClaim requesting a Raw Block Volume {#persistent-volume-claim-requesting-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: block-pvc +spec: + accessModes: + - ReadWriteOnce + volumeMode: Block + resources: + requests: + storage: 10Gi +``` + +### Pod specification adding Raw Block Device path in container + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-with-block-volume +spec: + containers: + - name: fc-container + image: fedora:26 + command: ["/bin/sh", "-c"] + args: [ "tail -f /dev/null" ] + volumeDevices: + - name: data + devicePath: /dev/xvda + volumes: + - name: data + persistentVolumeClaim: + claimName: block-pvc +``` + +{{< note >}} +When adding a raw block device for a Pod, you specify the device path in the +container instead of a mount path. +{{< /note >}} + +### Binding Block Volumes + +If a user requests a raw block volume by indicating this using the `volumeMode` +field in the PersistentVolumeClaim spec, the binding rules differ slightly from +previous releases that didn't consider this mode as part of the spec. +Listed is a table of possible combinations the user and admin might specify for +requesting a raw block device. The table indicates if the volume will be bound or +not given the combinations: Volume binding matrix for statically provisioned volumes: + +| PV volumeMode | PVC volumeMode | Result | +| --------------|:---------------:| ----------------:| +| unspecified | unspecified | BIND | +| unspecified | Block | NO BIND | +| unspecified | Filesystem | BIND | +| Block | unspecified | NO BIND | +| Block | Block | BIND | +| Block | Filesystem | NO BIND | +| Filesystem | Filesystem | BIND | +| Filesystem | Block | NO BIND | +| Filesystem | unspecified | BIND | + +{{< note >}} +Only statically provisioned volumes are supported for alpha release. Administrators +should take care to consider these values when working with raw block devices. +{{< /note >}} + +## Volume Snapshot and Restore Volume from Snapshot Support + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +Volume snapshots only support the out-of-tree CSI volume plugins. +For details, see [Volume Snapshots](/docs/concepts/storage/volume-snapshots/). +In-tree volume plugins are deprecated. You can read about the deprecated volume +plugins in the +[Volume Plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). + +### Create a PersistentVolumeClaim from a Volume Snapshot {#create-persistent-volume-claim-from-volume-snapshot} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: restore-pvc +spec: + storageClassName: csi-hostpath-sc + dataSource: + name: new-snapshot-test + kind: VolumeSnapshot + apiGroup: snapshot.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Volume Cloning + +[Volume Cloning](/docs/concepts/storage/volume-pvc-datasource/) +only available for CSI volume plugins. + +### Create PersistentVolumeClaim from an existing PVC {#create-persistent-volume-claim-from-an-existing-pvc} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: cloned-pvc +spec: + storageClassName: my-csi-plugin + dataSource: + name: existing-src-pvc-name + kind: PersistentVolumeClaim + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Volume populators and data sources + +{{< feature-state for_k8s_version="v1.24" state="beta" >}} + +Kubernetes supports custom volume populators. +To use custom volume populators, you must enable the `AnyVolumeDataSource` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for +the kube-apiserver and kube-controller-manager. + +Volume populators take advantage of a PVC spec field called `dataSourceRef`. Unlike the +`dataSource` field, which can only contain either a reference to another PersistentVolumeClaim +or to a VolumeSnapshot, the `dataSourceRef` field can contain a reference to any object in the +same namespace, except for core objects other than PVCs. For clusters that have the feature +gate enabled, use of the `dataSourceRef` is preferred over `dataSource`. + +## Cross namespace data sources + +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +Kubernetes supports cross namespace volume data sources. +To use cross namespace volume data sources, you must enable the `AnyVolumeDataSource` +and `CrossNamespaceVolumeDataSource` +[feature gates](/docs/reference/command-line-tools-reference/feature-gates/) for +the kube-apiserver and kube-controller-manager. +Also, you must enable the `CrossNamespaceVolumeDataSource` feature gate for the csi-provisioner. + +Enabling the `CrossNamespaceVolumeDataSource` feature gate allows you to specify +a namespace in the dataSourceRef field. + +{{< note >}} +When you specify a namespace for a volume data source, Kubernetes checks for a +ReferenceGrant in the other namespace before accepting the reference. +ReferenceGrant is part of the `gateway.networking.k8s.io` extension APIs. +See [ReferenceGrant](https://gateway-api.sigs.k8s.io/api-types/referencegrant/) +in the Gateway API documentation for details. +This means that you must extend your Kubernetes cluster with at least ReferenceGrant from the +Gateway API before you can use this mechanism. +{{< /note >}} + +## Data source references + +The `dataSourceRef` field behaves almost the same as the `dataSource` field. If one is +specified while the other is not, the API server will give both fields the same value. Neither +field can be changed after creation, and attempting to specify different values for the two +fields will result in a validation error. Therefore the two fields will always have the same +contents. + +There are two differences between the `dataSourceRef` field and the `dataSource` field that +users should be aware of: + +* The `dataSource` field ignores invalid values (as if the field was blank) while the + `dataSourceRef` field never ignores values and will cause an error if an invalid value is + used. Invalid values are any core object (objects with no apiGroup) except for PVCs. +* The `dataSourceRef` field may contain different types of objects, while the `dataSource` field + only allows PVCs and VolumeSnapshots. + +When the `CrossNamespaceVolumeDataSource` feature is enabled, there are additional differences: + +* The `dataSource` field only allows local objects, while the `dataSourceRef` field allows + objects in any namespaces. +* When namespace is specified, `dataSource` and `dataSourceRef` are not synced. + +Users should always use `dataSourceRef` on clusters that have the feature gate enabled, and +fall back to `dataSource` on clusters that do not. It is not necessary to look at both fields +under any circumstance. The duplicated values with slightly different semantics exist only for +backwards compatibility. In particular, a mixture of older and newer controllers are able to +interoperate because the fields are the same. + +### Using volume populators + +Volume populators are {{< glossary_tooltip text="controllers" term_id="controller" >}} that can +create non-empty volumes, where the contents of the volume are determined by a Custom Resource. +Users create a populated volume by referring to a Custom Resource using the `dataSourceRef` field: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: populated-pvc +spec: + dataSourceRef: + name: example-name + kind: ExampleDataSource + apiGroup: example.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +Because volume populators are external components, attempts to create a PVC that uses one +can fail if not all the correct components are installed. External controllers should generate +events on the PVC to provide feedback on the status of the creation, including warnings if +the PVC cannot be created due to some missing component. + +You can install the alpha [volume data source validator](https://github.com/kubernetes-csi/volume-data-source-validator) +controller into your cluster. That controller generates warning Events on a PVC in the case that no populator +is registered to handle that kind of data source. When a suitable populator is installed for a PVC, it's the +responsibility of that populator controller to report Events that relate to volume creation and issues during +the process. + +### Using a cross-namespace volume data source + +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +Create a ReferenceGrant to allow the namespace owner to accept the reference. +You define a populated volume by specifying a cross namespace volume data source +using the `dataSourceRef` field. You must already have a valid ReferenceGrant +in the source namespace: + + ```yaml + apiVersion: gateway.networking.k8s.io/v1beta1 + kind: ReferenceGrant + metadata: + name: allow-ns1-pvc + namespace: default + spec: + from: + - group: "" + kind: PersistentVolumeClaim + namespace: ns1 + to: + - group: snapshot.storage.k8s.io + kind: VolumeSnapshot + name: new-snapshot-demo + ``` + + ```yaml + apiVersion: v1 + kind: PersistentVolumeClaim + metadata: + name: foo-pvc + namespace: ns1 + spec: + storageClassName: example + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + dataSourceRef: + apiGroup: snapshot.storage.k8s.io + kind: VolumeSnapshot + name: new-snapshot-demo + namespace: default + volumeMode: Filesystem + ``` + +## Writing Portable Configuration + +If you're writing configuration templates or examples that run on a wide range of clusters +and need persistent storage, it is recommended that you use the following pattern: + +- Include PersistentVolumeClaim objects in your bundle of config (alongside + Deployments, ConfigMaps, etc). +- Do not include PersistentVolume objects in the config, since the user instantiating + the config may not have permission to create PersistentVolumes. +- Give the user the option of providing a storage class name when instantiating + the template. + - If the user provides a storage class name, put that value into the + `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 + 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 + and surface this to the user, as this may indicate that the cluster has no + dynamic storage support (in which case the user should create a matching PV) + or the cluster has no storage system (in which case the user cannot deploy + config requiring PVCs). + +## {{% heading "whatsnext" %}} + +* Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). +* Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). +* Read the [Persistent Storage design document](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md). + +### API references {#reference} + +Read about the APIs described in this page: + +* [`PersistentVolume`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/) +* [`PersistentVolumeClaim`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1/) diff --git a/content/uk/docs/concepts/windows/_index.md b/content/uk/docs/concepts/windows/_index.md new file mode 100644 index 0000000000000..188b801adccea --- /dev/null +++ b/content/uk/docs/concepts/windows/_index.md @@ -0,0 +1,29 @@ +--- +title: "Windows у Kubernetes" +simple_list: true +weight: 200 +description: >- + Kubernetes підтримує роботу вузлів на яких запущено Microsoft Windows. +--- + +Kubernetes підтримує робочі {{< glossary_tooltip text="вузли" term_id="node" >}} які запущених на Linux або Microsoft Windows. + +{{% thirdparty-content single="true" %}} + +CNCF та батьківська організація Linux Foundation використовують вендор-нейтральний підхід до сумісності. Це означає, що можна додати ваш [Windows сервер](https://www.microsoft.com/en-us/windows-server) як робочий вузол до кластера Kubernetes. + +Ви можете [встановити та налаштувати kubectl на Windows](/docs/tasks/tools/install-kubectl-windows/) незалежно від операційної системи, яку ви використовуєте в своєму кластері. + +Якщо ви використовуєте вузли Windows, ви можете прочитати: + +* [Мережа на Windows](/docs/concepts/services-networking/windows-networking/) +* [Зберігання на Windows в Kubernetes](/docs/concepts/storage/windows-storage/) +* [Керування ресурсами для вузлів Windows](/docs/concepts/configuration/windows-resource-management/) +* [Налаштування RunAsUserName для Pod та контейнерів Windows](/docs/tasks/configure-pod-container/configure-runasusername/) +* [Створення Pod Windows HostProcess](/docs/tasks/configure-pod-container/create-hostprocess-pod/) +* [Налаштування облікових записів служби з груповим керуванням для Pod та контейнерів Windows](/docs/tasks/configure-pod-container/configure-gmsa/) +* [Безпека для вузлів Windows](/docs/concepts/security/windows-security/) +* [Поради з налагодження Windows](/docs/tasks/debug/debug-cluster/windows/) +* [Посібник з планування контейнерів Windows в Kubernetes](/docs/concepts/windows/user-guide) + +або, для ознайомлення, подивіться: diff --git a/content/uk/docs/concepts/workloads/_index.md b/content/uk/docs/concepts/workloads/_index.md index c826cbbcbc587..bfb1ca07142e9 100644 --- a/content/uk/docs/concepts/workloads/_index.md +++ b/content/uk/docs/concepts/workloads/_index.md @@ -1,4 +1,44 @@ --- title: "Робочі навантаження" -weight: 50 +weight: 55 +description: > + Отримайте розуміння про Podʼи, найменші обʼєкти виконання в Kubernetes, та вищі рівні абстракції, які допомагають вам їх запускати. +no_list: true +card: + title: Робочі навантаження та Podʼи + name: concepts + weight: 60 --- + +{{< glossary_definition term_id="workload" length="short" >}} +Неважливо чи є ваше робоче навантаження одним компонентом, чи кількома, які працюють разом, в Kubernetes ви запускаєте його всередині набору [_Podʼів_](/docs/concepts/workloads/pods). В Kubernetes Pod представляє набір запущених {{< glossary_tooltip text="контейнерів" term_id="container" >}} у вашому кластері. + +Podʼи Kubernetes мають [кінцевий життєвий цикл](/docs/concepts/workloads/pods/pod-lifecycle/). Наприклад, як тільки Pod запущено у вашому кластері, будь-яка критична помилка на {{< glossary_tooltip text="вузлі" term_id="node" >}}, де запущено цей Pod, означає, що всі Podʼи на цьому вузлі зазнають збою. Kubernetes розглядає цей рівень збою як кінцевий: вам потрібно створити новий Pod, щоб відновити роботу, навіть якщо вузол пізніше відновить свою роботу. + +Однак, керувати кожним Pod окремо може бути складно. Замість цього, ви можете використовувати _ресурси робочого навантаження_, які керують набором Podʼів за вас. Ці ресурси налаштовують {{< glossary_tooltip term_id="controller" text="контролери" >}}, які переконуються, що правильна кількість Podʼів потрібного виду працює, щоб відповідати стану, який ви вказали. + +Kubernetes надає кілька вбудованих ресурсів робочого навантаження: + +* [Deployment](/docs/concepts/workloads/controllers/deployment/) та [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) (що є заміною застарілого типу ресурсу {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}). Deployment є хорошим вибором для керування робочим навантаженням, яке не зберігає стану, де будь-який Pod у Deployment може бути замінений, якщо це потрібно. +* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) дозволяє вам запускати один або кілька повʼязаних Podʼів, які відстежують стан певним чином. Наприклад, якщо ваше робоче навантаження постійно записує дані, ви можете запустити StatefulSet, який поєднує кожен Pod з [PersistentVolume](/docs/concepts/storage/persistent-volumes/). Ваш код, який працює в Pod для цього StatefulSet, може реплікувати дані на інші Podʼи в цьому StatefulSet, щоб покращити загальну надійність. +* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) визначає Podʼи які надають можливості, що локальними для вузлів. Кожного разу, коли ви додаєте вузол до свого кластера, який відповідає специфікації в DaemonSet, панель управління планує Pod для цього DaemonSet на новому вузлі. Кожен Pod в DaemonSet виконує роботу, схожу на роботу системного демона у класичному Unix/POSIX сервері. DaemonSet може бути фундаментальним для роботи вашого кластера, як, наприклад, втулок [мережі кластера](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model), він може допомогти вам керувати вузлом, або надати додаткову поведінку, яка розширює платформу контейнерів, яку ви використовуєте. +* [Job](/docs/concepts/workloads/controllers/job/) та [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) надають різні способи визначення завдань, які виконуються до завершення та зупиняються. Ви можете використовувати [Job](/docs/concepts/workloads/controllers/job/) для визначення завдання, яке виконується до завершення, тільки один раз. Ви можете використовувати [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) для запуску того ж Job кілька разів згідно з розкладом. + +В екосистемі Kubernetes ви можете знайти ресурси робочого навантаження від сторонніх розробників, які надають додаткові можливості. Використовуючи [визначення власних ресурсів](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), ви можете додати ресурс робочого навантаження від стороннього розробника, якщо ви хочете використовувати конкретну функцію, яка не є частиною основної функціональності Kubernetes. Наприклад, якщо ви хочете запустити групу Podʼів для вашого застосунку, але зупинити роботу незалежно від того, чи доступні _всі_ Podʼи (можливо, для якогось розподіленого завдання великого обсягу), ви можете реалізувати або встановити розширення, яке надає цю функцію. + +## {{% heading "whatsnext" %}} + + Так само як і дізнаючись про кожний різновид API для керування робочим навантаженням, ви можете дізнатись, як виконати конкретні завдання: + +* [Запуск застосунку stateless використовуючи Deployment](/docs/tasks/run-application/run-stateless-application-deployment/) +* Запуск застосунку stateful як [одиничного екземпляру](/docs/tasks/run-application/run-single-instance-stateful-application/) чи як [реплікованого набору](/docs/tasks/run-application/run-replicated-stateful-application/) +* [Викоання автоматизованих завдань з CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/) + +Щоб дізнатись про механізми Kubernetes для відокремлення коду від конфігурації, відвідайте сторінку [Конфігурація](/docs/concepts/configuration/). + +Існують два концепти, які надають фонову інформацію про те, як Kubernetes керує Podʼами для застосунків: + +* [Збір сміття](/docs/concepts/architecture/garbage-collection/) приводить до ладу обʼєкти у вашому кластері після того, як їх _власний ресурс_ був видалений. +* [Контролер _time-to-live after finished_](/docs/concepts/workloads/controllers/ttlafterfinished/) видаляє Jobʼи після того, як визначений час пройшов після їх завершення. + +Як тільки ваш застосунок працює, ви, можливо, захочете зробити його доступними в Інтернеті як [Service](/docs/concepts/services-networking/service/) або, для вебзастосунків, використовуючи [Ingress](/docs/concepts/services-networking/ingress/). diff --git a/content/uk/docs/concepts/workloads/autoscaling.md b/content/uk/docs/concepts/workloads/autoscaling.md new file mode 100644 index 0000000000000..8cc4266080d9c --- /dev/null +++ b/content/uk/docs/concepts/workloads/autoscaling.md @@ -0,0 +1,117 @@ +--- +title: Автомасштабування робочих навантажень +description: >- + З автомасштабуванням ви можете автоматично оновлювати ваші робочі навантаження різними способами. Це дозволяє вашому кластеру еластичніше та ефективніше реагувати на зміни витрат ресурсів. +content_type: concept +weight: 40 +--- + + + +У Kubernetes ви можете _масштабувати_ робоче навантаження залежно від поточного попиту на ресурси. Це дозволяє вашому кластеру більш еластично та ефективно реагувати на зміни витрат ресурсів. + +При масштабуванні робочого навантаження ви можете збільшувати або зменшувати кількість реплік, які керуються робочим навантаженням, або налаштовувати ресурси, доступні для реплік на місці. + +Перший підхід називається _горизонтальним масштабуванням_, тоді як другий — _вертикальним масштабуванням_. + +Є ручні та автоматичні способи масштабування робочих навантажень, залежно від вашого випадку використання. + + + +## Ручне масштабування робочих навантажень {#scaling-workloads-manually} + +Kubernetes підтримує _ручне масштабування_ робочих навантажень. Горизонтальне масштабування можна виконати за допомогою інтерфейсу командного рядка `kubectl`. Для вертикального масштабування вам потрібно _змінити_ визначення ресурсів вашого робочого навантаження. + +Дивіться нижче приклади обох стратегій. + +- **Горизонтальне масштабування**: [Запуск кількох екземплярів вашого застосунку](/docs/tutorials/kubernetes-basics/scale/scale-intro/) +- **Вертикальне масштабування**: [Зміна обсягів ресурсів CPU та памʼяті, призначених для контейнерів](/docs/tasks/configure-pod-container/resize-container-resources/) + +## Автоматичне масштабування робочих навантажень {#scaling-workloads-automatically} + +Kubernetes також підтримує _автоматичне масштабування_ робочих навантажень, що є основною темою цієї сторінки. + +Концепція _Автомасштабування_ в Kubernetes стосується можливості автоматичного оновлення обʼєкта, який керує набором Podʼів (наприклад, {{< glossary_tooltip text="Deployment" term_id="deployment" >}}). + +### Горизонтальне масштабування робочих навантажень {#scaling-workloads-horizontally} + +У Kubernetes ви можете автоматично масштабувати робоче навантаження горизонтально за допомогою _HorizontalPodAutoscaler_ (HPA). + +Він реалізований як ресурс Kubernetes API та {{< glossary_tooltip text="controller" term_id="controller" >}} і періодично налаштовує кількість {{< glossary_tooltip text="реплік" term_id="replica" >}} в робочому навантаженні, щоб відповідати спостереженню за використанням ресурсів, такими як використання CPU чи памʼяті. + +Є [посібник з інструкціями](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough) з налаштування HorizontalPodAutoscaler для Deployment. + +### Вертикальне масштабування робочих навантажень {#scaling-workloads-vertically} + +{{< feature-state for_k8s_version="v1.25" state="stable" >}} + +Ви можете автоматично масштабувати робоче навантаження вертикально за допомогою _VerticalPodAutoscaler_ (VPA). На відміну від HPA, VPA не поставляється стандартно в Kubernetes, але є окремим проєктом, який можна знайти [на GitHub](https://github.com/kubernetes/autoscaler/tree/9f87b78df0f1d6e142234bb32e8acbd71295585a/vertical-pod-autoscaler). + +Після встановлення він дозволяє створювати {{< glossary_tooltip text="CustomResourceDefinitions" term_id="customresourcedefinition" >}} (CRDs) для ваших робочих навантажень, які визначають _як_ і _коли_ масштабувати ресурси керованих реплік. + +{{< note >}} +Вам потрібно мати встановлений [Metrics Server](https://github.com/kubernetes-sigs/metrics-server) в вашому кластері для роботи HPA. +{{< /note >}} + +На цей час VPA може працювати в чотирьох різних режимах: + +{{< table caption="Різні режими VPA" >}} +Режим | Опис +:----|:----------- +`Auto` | Наразі `Recreate`, може змінитися на оновлення на місці у майбутньому +`Recreate` | VPA встановлює ресурсні запити при створенні підпорядкованих контейнерів і оновлює їх на наявних контейнерах, витісняючи їх, коли запитані ресурси відрізняються від нової рекомендації +`Initial` | VPA встановлює ресурсні запити лише при створенні підпорядкованих контейнерів і ніколи не змінює їх пізніше. +`Off` | VPA автоматично не змінює вимоги до ресурсів підпорядкованих контейнерів. Рекомендації обчислюються і можуть бути перевірені в обʼєкті VPA. +{{< /table >}} + +#### Вимоги для масштабування на місці + +{{< feature-state for_k8s_version="v1.27" state="alpha" >}} + +Масштабування робочого навантаження на місці **без** перезапуску {{< glossary_tooltip text="підпорядкованих контейнерів" term_id="pod" >}} чи їх {{< glossary_tooltip text="контейнерів" term_id="container" >}} вимагає версії Kubernetes 1.27 чи пізніше.
+Додатково потрібно ввімкнути властивість `InPlaceVerticalScaling`. + +{{< feature-gate-description name="InPlacePodVerticalScaling" >}} + +### Автомасштабування на основі розміру кластера {#autoscaling-based-on-cluster-size} + +Для робочих навантажень, які потрібно масштабувати залежно від розміру кластера (наприклад, `cluster-dns` чи інші системні компоненти), ви можете використовувати [_Cluster Proportional Autoscaler_](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler).
Так само як і VPA, він не є частиною основного функціонала Kubernetes, але розміщений як окремий проєкт на GitHub. + +Cluster Proportional Autoscaler відстежує кількість {{< glossary_tooltip text="вузлів" term_id="node" >}} які готові приймати Podʼи та ядра та масштабує кількість реплік цільового робочого навантаження відповідно. + +Якщо кількість реплік має залишитися незмінною, ви можете масштабувати свої робочі навантаження вертикально залежно від розміру кластера, використовуючи [_Cluster Proportional Vertical Autoscaler_](https://github.com/kubernetes-sigs/cluster-proportional-vertical-autoscaler). Проєкт знаходиться **наразі у бета-версії** та доступний на GitHub. + +В той час як Cluster Proportional Autoscaler масштабує кількість реплік робочого навантаження, Cluster Proportional Vertical Autoscaler налаштовує вимоги до ресурсів для робочого навантаження (наприклад, Deployment або DaemonSet) залежно від кількості вузлів та/або ядер у кластері. + +### Автомасштабування, на підставі подій {#event-driven-autoscaling} + +Також існує можливість масштабування робочих навантажень на основі подій, наприклад, використовуючи [_Kubernetes Event Driven Autoscaler_ (**KEDA**)](https://keda.sh/). + +KEDA є проєктом створеним під егідою CNCF, що дозволяє масштабувати ваші робочі навантаження залежно від кількості +подій для обробки, наприклад, кількість повідомлень в черзі. Існує широкий спектр адаптерів для різних джерел подій, які можна вибрати. + +### Автомасштабування на основі розкладу {#autoscaling-based-on-schedule} + +Ще одна стратегія для масштабування вашого робочого навантаження — це **запланувати** операції масштабування, наприклад, для зменшення використання ресурсів під час годин неактивності. + +Схоже на автомасштабування, спровоковане подіями, таку поведінку можна досягти за допомогою KEDA спільно з його [`Cron` scaler](https://keda.sh/docs/2.13/scalers/cron/). Scaler `Cron` дозволяє вам визначати розклади (і часові пояси) для масштабування ваших робочих навантажень вгору чи вниз. + +## Масштабування інфраструктури кластера {#scaling-cluster-infrastructure} + +Якщо масштабування робочих навантажень не вистачає для задоволення ваших потреб, ви також можете масштабувати інфраструктуру вашого кластера. + +Масштабування інфраструктури кластера, зазвичай, передбачає додавання або видалення {{< glossary_tooltip text="вузлів" term_id="node" >}}. Це можна зробити за допомогою одного з двох доступних автомасштабувальників: + +- [**Cluster Autoscaler**](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) +- [**Karpenter**](https://github.com/kubernetes-sigs/karpenter?tab=readme-ov-file) + +Обидва автомасштабувальники працюють, спостерігаючи за підписаними як _незаплановані для розміщення_ або _недостатньо використаними_ вузлами та, відповідно, додають або +видаляють вузли за необхідності. + +## {{% heading "whatsnext" %}} + +- Дізнайтеся більше про горизонтальне масштабування + - [Масштабування StatefulSet](/docs/tasks/run-application/scale-stateful-set/) + - [Посібник по HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) +- [Зміна розміру ресурсів контейнера на місці](/docs/tasks/configure-pod-container/resize-container-resources/) +- [Автомасштабування служби DNS в кластері](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) diff --git a/content/uk/docs/concepts/workloads/controllers/_index.md b/content/uk/docs/concepts/workloads/controllers/_index.md index 3e5306f908cbc..48ee06f2f7095 100644 --- a/content/uk/docs/concepts/workloads/controllers/_index.md +++ b/content/uk/docs/concepts/workloads/controllers/_index.md @@ -1,4 +1,25 @@ --- -title: "Контролери" +title: "Керування навантаженням" weight: 20 +simple_list: true --- + +Kubernetes надає кілька вбудованих API для декларативного керування вашими {{< glossary_tooltip text="робочими навантаженнями" term_id="workload" >}} та їх компонентами. + +У кінцевому підсумку ваші застосунки працюють як контейнери всередині {{< glossary_tooltip term_id="Pod" text="Podʼів" >}}; однак керувати окремими Podʼами вимагало б багато зусиль. Наприклад, якщо Pod зазнає збою, ви, ймовірно, захочете запустити новий Pod для його заміни. Kubernetes може зробити це за вас. + +Ви використовуєте API Kubernetes для створення робочого {{< glossary_tooltip text="обʼєкта" term_id="object" >}}, який представляє вищий рівень абстракції, ніж Pod, а потім Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} автоматично керує обʼєктами Pod від вашого імені, відповідно до специфікації обʼєкта робочого навантаження, яку ви визначили. + +Вбудовані API для керування робочими навантаженнями: + +[Deployment](/docs/concepts/workloads/controllers/deployment/) (і, опосередковано, [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)), найпоширеніший спосіб запуску застосунку у вашому кластері. Deployment є хорошим вибором для керування робочим навантаженням, яке не зберігає стану, де будь-який Pod у Deployment може бути замінений, якщо це потрібно. (Deployments є заміною застарілого API {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}). + +[StatefulSet](/docs/concepts/workloads/controllers/statefulset/) дозволяє вам керувати одним або кількома Pod, які виконують один і той же код застосунку, де Pod мають унікальну ідентичність. Це відрізняється від Deployment, де очікується, що Pod будуть взаємозамінними. Найпоширеніше використання StatefulSet полягає в тому, щоб забезпечити звʼязок між Pod та їх постійним сховищем. Наприклад, ви можете запустити StatefulSet, який асоціює кожен Pod з [PersistentVolume](/docs/concepts/storage/persistent-volumes/). Якщо один з Pod у StatefulSet зазнає збою, Kubernetes створює новий Pod, який підключений до того ж PersistentVolume. + +[DemonSet](/docs/concepts/workloads/controllers/daemonset/) визначає Podʼи, які надають можливості, що є локальними для конкретного {{< glossary_tooltip text="вузла" term_id="node" >}}; наприклад, драйвер, який дозволяє контейнерам на цьому вузлі отримувати доступ до системи сховища. Ви використовуєте DemonSet, коли драйвер або інша служба рівня вузла має працювати на вузлі, де вона корисна. Кожен Pod в DemonSet виконує роль, схожу на системний демон на класичному сервері Unix/POSIX. DemonSet може бути фундаментальним для роботи вашого кластера, наприклад, як втулок [мережі кластера](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model), він може допомогти вам керувати вузлом, або надати додаткову поведінку, яка розширює платформу контейнерів, яку ви використовуєте. Ви можете запускати DemonSet (і їх Podʼи) на кожному вузлі вашого кластера, або лише на підмножині (наприклад, встановити драйвер прискорювача GPU лише на вузлах, де встановлено GPU). + +Ви можете використовувати [Job](/docs/concepts/workloads/controllers/job/) та / або [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) для визначення завдань, які виконуються до завершення та зупиняються. Job представляє одноразове завдання, тоді як кожен CronJob повторюється згідно з розкладом. + +Інші теми в цьому розділі: + + diff --git a/content/uk/docs/concepts/workloads/controllers/cron-jobs.md b/content/uk/docs/concepts/workloads/controllers/cron-jobs.md new file mode 100644 index 0000000000000..d55ebad1a508c --- /dev/null +++ b/content/uk/docs/concepts/workloads/controllers/cron-jobs.md @@ -0,0 +1,171 @@ +--- +reviewers: +- erictune +- soltysh +- janetkuo +title: CronJob +content_type: concept +description: >- + Обʼєкт CronJob запускає Job за повторюваним графіком. +weight: 80 +hide_summary: true # Listed separately in section index +--- + + + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + +_**CronJob**_ створює {{< glossary_tooltip term_id="job" text="Jobs" >}} за повторюваним графіком. + +CronJob призначений для виконання регулярних запланованих дій, таких як резервне копіювання, генерація звітів та інше. Один обʼєкт CronJob подібний до одного рядка файлу _crontab_ (таблиця cron) на системі Unix. Він запускає Job періодично за заданим графіком, записаним у форматі [Cron](https://en.wikipedia.org/wiki/Cron). + +У CronJob є обмеження та особливості. Наприклад, в певних обставинах один CronJob може створювати кілька одночасних Jobs. Див. [обмеження](#cron-job-limitations) нижче. + +Коли планувальник створює нові Jobs і (відповідно) Podʼи для CronJob, `.metadata.name` CronJob є частиною основи для імені цих Podʼів. Назва CronJob повинна бути дійсним значенням [DNS-піддомену](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names), але це може призводити до неочікуваних результатів для імен хостів Podʼів. Для найкращої сумісності назва повинна відповідати більш обмеженим правилам [DNS-мітки](/docs/concepts/overview/working-with-objects/names#dns-label-names). Навіть коли імʼя є DNS-піддоменом, імʼя не повинно бути довше 52 символів. Це тому, що контролер CronJob автоматично додає 11 символів до наданого вами імені, і існує обмеження на довжину імені Job, яке не повинно перевищувати 63 символи. + + + +## Приклад {#example} + +У цьому прикладі маніфест CronJob виводить поточний час та вітання кожну хвилину: + +{{% code_sample file="application/job/cronjob.yaml" %}} + +([Виконання автоматизованих завдань за допомогою CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/) докладніше описує цей приклад). + +## Написання специфікації CronJob {#writing-a-cronjob-spec} + +### Синтаксис розкладу {#schedule-syntax} + +Поле `.spec.schedule` є обовʼязковим. Значення цього поля відповідає синтаксису [Cron](https://en.wikipedia.org/wiki/Cron): + +```none +# ┌───────────── хвилина (0 - 59) +# │ ┌───────────── година (0 - 23) +# │ │ ┌───────────── день місяця (1 - 31) +# │ │ │ ┌───────────── місяць (1 - 12) +# │ │ │ │ ┌───────────── день тижня (0 - 6) (Неділя - Субота) +# │ │ │ │ │ АБО неділя, понеділок, вівторок, середа, четвер, п'ятниця, субота +# │ │ │ │ │ +# │ │ │ │ │ +# * * * * * +``` + +Наприклад, `0 0 13 * 5` вказує, що завдання повинно починатися кожної пʼятниці о півночі, а також 13-ого числа кожного місяця о півночі. + +Формат також включає розширені значення кроків "Vixie cron". Як пояснено в [документації FreeBSD](https://www.freebsd.org/cgi/man.cgi?crontab%285%29): + +> Значення кроків можна використовувати разом із діапазонами. Після діапазону з `/ ` вказує пропуски значення числа через діапазон. Наприклад, `0-23/2` можна використовувати в годинах для вказівки виконання команди кожну другу годину (альтернативою в стандарті V7 є `0,2,4,6,8,10,12,14,16,18,20,22`). Після зірочки також допускаються кроки, тому, якщо ви хочете сказати "кожні дві години", просто використовуйте `*/2`. + +{{< note >}} +Знак питання (`?`) у розкладі має той же зміст, що й зірочка `*`, тобто позначає будь-яке доступне значення для даного поля. +{{< /note >}} + +Окрім стандартного синтаксису, також можна використовувати деякі макроси, такі як `@monthly`: + +| Запис | Опис | Еквівалентно | +| ------------- | ------------- |------------- | +| @yearly (або @annually) | Виконувати один раз на рік о півночі 1 січня | 0 0 1 1 * | +| @monthly | Виконувати один раз на місяць о півночі першого дня місяця | 0 0 1 * * | +| @weekly | Виконувати один раз на тиждень о півночі в неділю | 0 0 * * 0 | +| @daily (або @midnight) | Виконувати один раз на день о півночі | 0 0 * * * | +| @hourly | Виконувати один раз на годину на початку години | 0 * * * * | + +Для генерації виразів розкладу CronJob можна також використовувати вебінструменти, наприклад [crontab.guru](https://crontab.guru/). + +### Шаблон завдання {#job-template} + +Поле `.spec.jobTemplate` визначає шаблон для завдань, які створює CronJob, і воно обовʼязкове. Воно має точно таку ж схему, як [Job](/docs/concepts/workloads/controllers/job/), за винятком того, що воно вкладене і не має `apiVersion` або `kind`. Ви можете вказати загальні метадані для завдань, створених за шаблоном, такі як {{< glossary_tooltip text="labels" term_id="label" >}} або {{< glossary_tooltip text="annotations" term_id="annotation" >}}. Щодо інформації щодо написання `.spec` завдання, дивіться [Написання специфікації завдання](/docs/concepts/workloads/controllers/job/#writing-a-job-spec). + +### Термін відстрочення для відкладеного запуску завдання {#starting-deadline} + +Поле `.spec.startingDeadlineSeconds` є необовʼязковим. Це поле визначає термін (в повних секундах) для запуску завдання, якщо це завдання пропускає свій запланований час з будь-якої причини. + +Після пропуску терміну CronJob пропускає цей екземпляр завдання (майбутні випадки все ще заплановані). Наприклад, якщо у вас є завдання резервного копіювання, яке запускається двічі на день, ви можете дозволити йому запускатися з запізненням до 8 годин, але не пізніше, оскільки резервна копія, виконана пізніше, буде неактуальною: ви замість цього віддавали б перевагу чекати на наступний запланований запуск. + +Для завдань, які пропускають свій термін, налаштований час відстрочення, Kubernetes вважає їх завданнями, що не вдалися. Якщо ви не вказали `startingDeadlineSeconds` для CronJob, екземпляри завдань не мають терміну. + +Якщо поле `.spec.startingDeadlineSeconds` встановлено (не є нульовим), контролер CronJob вимірює час між тим, коли очікується створення завдання, і зараз. Якщо різниця вище за цей ліміт, він пропускає це виконання. + +Наприклад, якщо воно встановлене на `200`, це дозволяє створити завдання протягом 200 секунд після фактичного часу. + +### Політика паралелізму {#concurrency-policy} + +Також необовʼязкове поле `.spec.concurrencyPolicy`. Воно визначає, як обробляти паралельні виконання завдання, яке створюється цим CronJob. Специфікація може вказувати лише одну з наступних політик паралельності: + +* `Allow` (станадартно): CronJob дозволяє паралельні запуски завдань +* `Forbid`: CronJob не дозволяє паралельні запуски; якщо настав час для нового запуску завдання і попередній запуск завдання ще не завершився, CronJob пропускає новий запуск завдання. Також слід зауважити, що коли попередній запуск завдання завершиться, враховується `.spec.startingDeadlineSeconds` і може призвести до нового запуску завдання. +* `Replace`: Якщо час для нового запуску завдання і попередній запуск завдання ще не завершився, CronJob замінює поточний запуск завдання новим запуском завдання. + +Зверніть увагу, що політика паралелізму застосовується лише до завдань, створених цим самим CronJob. Якщо є кілька CronJob, їхні відповідні завдання завжди можуть виконуватися паралельно. + +### Призупинення розкладу {#schedule-suspension} + +Ви можете призупинити виконання завдань для CronJob, встановивши необовʼязкове поле `.spec.suspend` в значення true. Стандартно поле має значення false. + +Це налаштування _не_ впливає на завдання, які CronJob вже розпочав. + +Якщо ви встановите це поле в значення true, всі наступні виконання будуть призупинені (вони залишаються запланованими, але контролер CronJob не запускає завдання для виконання завдань), поки ви не призупините CronJob. + +{{< caution >}} +Виконання, які призупинені під час запланованого часу, вважаються пропущеними завданнями. Коли `.spec.suspend` змінюється з `true` на `false` для наявного CronJob без [строку початку](#starting-deadline), пропущені завдання заплановані негайно. +{{< /caution >}} + +### Обмеження історії завдань {#job-history-limit} + +Поля `.spec.successfulJobsHistoryLimit` та `.spec.failedJobsHistoryLimit` є необовʼязковими. Ці поля вказують, скільки завершених і невдало виконаних завдань слід зберігати. Типово вони встановлені на 3 та 1 відповідно. Встановлення обмеження `0` відповідає тому, що не слід зберігати жодного відповідного типу завдань після їх завершення. + +Для іншого способу автоматичного прибирання завдань дивіться [Автоматичне прибирання завершених завдань](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically). + +### Часові пояси {#time-zones} + +{{< feature-state for_k8s_version="v1.27" state="stable" >}} + +Для CronJob без вказаного часового поясу {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} інтерпретує розклад відносно свого локального часового поясу. + +Ви можете вказати часовий пояс для CronJob, встановивши `.spec.timeZone` на назву дійсного [часового поясу](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). Наприклад, встановлення `.spec.timeZone: "Etc/UTC"` вказує Kubernetes інтерпретувати графік відносно Координованого універсального часу. + +В базових бінарниках включена база даних часових поясів зі стандартної бібліотеки Go і використовується як запасний варіант у разі, якщо зовнішня база даних недоступна на системі. + +### Обмеження CronJob {#cron-job-limitations} + +### Непідтримувані специфікації часових поясів {#unsupported-time-zone-specification} + +Зазначення часового поясу за допомогою змінних `CRON_TZ` або `TZ` всередині `.spec.schedule` **офіційно не підтримується** (і ніколи не підтримувалася). + +Починаючи з Kubernetes 1.29, якщо ви намагаєтеся встановити розклад, який включає вказівку часового поясу `TZ` або `CRON_TZ`, Kubernetes не зможе створити ресурс і сповістить про помилку. Оновлення CronJobs, які вже використовують `TZ` або `CRON_TZ`, продовжать повідомляти клієнта про [попередження](/blog/2020/09/03/warnings/). + +### Зміна параметрів CronJob {#modifying-a-cronjob} + +За концепцією, у CronJob є шаблоном для _нових_ Jobs. Якщо ви модифікуєте наявний CronJob, зміни застосовуватимуться до нових Job, які почнуть виконуватися після завершення вашої модифікації. Job (і їх Podʼи), які вже почали виконуватися, продовжують працювати без змін. Іншими словами, CronJob не оновлює поточні Job, навіть якщо вони ще продовжують виконуватися. + +### Створення Job {#job-creation} + +CronJob створює обʼєкт Job приблизно один раз за час виконання свого розкладу. Запуск є приблизним через те, що є обставини, коли може бути створено два Job або жоденого. Kubernetes намагається уникати таких ситуацій, але не повністю запобігає їм. Таким чином, Job, які ви визначаєте, повинні бути _ідемпотентними_. + +{{< caution >}} +Якщо `startingDeadlineSeconds` встановлено на велике значення або залишено не встановленим (типово), і якщо `concurrencyPolicy` встановлено на `Allow`, Jobs завжди будуть запускатися принаймні один раз. +{{< /caution >}} + +Для кожного CronJob контролер CronJob {{< glossary_tooltip term_id="controller" >}} перевіряє, скільки розкладів він пропустив протягом часу від його останнього запланованого часу до теперішнього часу. Якщо пропущено понад 100 розкладів, то Job не запускається, і виводиться помилка в лог. + +```none +Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. +``` + +Важливо відзначити, що якщо поле `startingDeadlineSeconds` встановлено (не є `nil`), контролер враховує, скільки пропущених Job сталося від значення `startingDeadlineSeconds` до теперішнього часу, а не від останнього запланованого часу до теперішнього часу. Наприклад, якщо `startingDeadlineSeconds` дорівнює `200`, контролер враховує, скільки Job було пропущено за останні 200 секунд. + +CronJob вважається пропущеним, якщо не вдалося створити Job в запланований час. Наприклад, якщо `concurrencyPolicy` встановлено на `Forbid` і CronJob було спробовано запланувати, коли попередній Job все ще працював, то це буде враховуватися як пропущено. + +Наприклад, припустимо, що CronJob встановлено для запуску нового Job кожну хвилину, починаючи з `08:30:00`, і його поле `startingDeadlineSeconds` не встановлено. Якщо контролер CronJob випадково був вимкнений з `08:29:00` по `10:21:00`, Job не буде запущено, оскільки кількість пропущених Jobs, які пропустили свій розклад, понад 100. + +Для того, щоб краще проілюструвати цей концепт, припустимо, що CronJob встановлено для запуску нового Job кожну хвилину, починаючи з `08:30:00`, і його поле `startingDeadlineSeconds` встановлено на 200 секунд. Якщо контролер CronJob випадково був вимкнений протягом того ж періоду, що й у попередньому прикладі (`08:29:00` до `10:21:00`) Job все одно запуститься о 10:22:00. Це трапляється тому, що тепер контролер перевіряє, скільки пропущених розкладів сталося за останні 200 секунд (тобто 3 пропущені розклади), а не від останнього запланованого часу до теперішнього часу. + +CronJob відповідає лише за створення Job, які відповідають його розкладу, а Job, зs свого боку, відповідає за управління Podʼами, які він представляє. + +## {{% heading "whatsnext" %}} + +* Дізнайтесь про [Podʼи](/docs/concepts/workloads/pods/) та [Job](/docs/concepts/workloads/controllers/job/), два поняття, які використовуються в CronJobs. +* Дізнайтеся більше про [формат](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format) поля `.spec.schedule` в CronJob. +* Щодо інструкцій зі створення та роботи з CronJobs, а також для прикладу маніфесту CronJob, дивіться [Виконання автоматизованих завдань за допомогою CronJobs](/docs/tasks/job/automated-tasks-with-cron-jobs/). +* `CronJob` є частиною Kubernetes REST API. Читайте {{< api-reference page="workload-resources/cron-job-v1" >}} API посилання для отримання докладних деталей. diff --git a/content/uk/docs/concepts/workloads/controllers/daemonset.md b/content/uk/docs/concepts/workloads/controllers/daemonset.md new file mode 100644 index 0000000000000..4f5e5adfbdf42 --- /dev/null +++ b/content/uk/docs/concepts/workloads/controllers/daemonset.md @@ -0,0 +1,186 @@ +--- +reviewers: +- enisoc +- erictune +- foxish +- janetkuo +- kow3ns +title: DaemonSet +description: >- + DaemonSet визначає Podʼи, які забезпечують засоби локального вузла. Це може бути фундаментально важливим для роботи вашого кластера, таким як інструмент-помічник мережі, або бути частиною застосунку. +content_type: concept +weight: 40 +hide_summary: true # Listed separately in section index +--- + + + +_**DaemonSet**_ переконується, що всі (або деякі) вузли запускають копію Podʼа. При додаванні вузлів до кластера, на них додаються Podʼи. При видаленні вузлів з кластера ці Podʼи видаляються. Видалення DaemonSet призведе до очищення створених ним Podʼів. + +Деякі типові використання DaemonSet включають: + +- запуск демона кластерного сховища на кожному вузлі +- запуск демона збору логів на кожному вузлі +- запуск демона моніторингу вузла на кожному вузлі + +У простому випадку один DaemonSet, який охоплює всі вузли, може використовуватися для кожного типу демона. Складніше налаштування може використовувати кілька DaemonSet для одного типу демона, але з різними прапорами, або різними запитами памʼяті та CPU для різних типів обладнання. + + + +## Створення специфікації DaemonSet {#writing-a-daemonset-spec} + +### Створення DaemonSet {#creating-a-daemonset} + +Ви можете описати DaemonSet у файлі YAML. Наприклад, файл `daemonset.yaml` нижче описує DaemonSet, який запускає Docker-образ fluentd-elasticsearch: + +{{% code_sample file="controllers/daemonset.yaml" %}} + +Створіть DaemonSet на основі файлу YAML: + +```bash +kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml +``` + +### Обовʼязкові поля {#required-fields} + +Як і з будь-якою іншою конфігурацією Kubernetes, DaemonSet потребує полів `apiVersion`, `kind` та `metadata`. Для загальної інформації щодо роботи з файлами конфігурації, див. [запуск stateless застосунків](/docs/tasks/run-application/run-stateless-application-deployment/) та [управління обʼєктами за допомогою kubectl](/docs/concepts/overview/working-with-objects/object-management/). + +Назва обʼєкта DaemonSet повинна бути дійсним [імʼям DNS-піддомену](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +DaemonSet також потребує [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) розділу. + +### Шаблон Podʼа {#pod-template} + +`.spec.template` — одне з обовʼязкових полів в `.spec`. + +`.spec.template` — це [шаблон Podʼа](/docs/concepts/workloads/pods/#pod-templates). Він має ту саму схему, що і {{< glossary_tooltip text="Pod" term_id="pod" >}}, за винятком того, що він вкладений і не має `apiVersion` або `kind`. + +Окрім обовʼязкових полів для Podʼа, шаблон Podʼа в DaemonSet повинен вказати відповідні мітки (див. [вибір Podʼа](#вибір-Podʼа)). + +Шаблон Pod в DaemonSet повинен мати [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) рівну `Always` або бути не вказаною, що типово рівнозначно `Always`. + +### Селектор Podʼа {#pod-selector} + +`.spec.selector` — обовʼязкове поле в `.spec`. + +Поле `.spec.selector` — це селектор Podʼа. Воно працює так само як і `.spec.selector` в [Job](/docs/concepts/workloads/controllers/job/). + +Ви повинні вказати селектор Podʼа, який відповідає міткам `.spec.template`. Крім того, після створення DaemonSet, його `.spec.selector` не може бути змінено. Зміна вибору Podʼа може призвести до навмисного залишення Podʼів сиротами, і це буде плутати користувачів. + +`.spec.selector` — це обʼєкт, що складається з двох полів: + +- `matchLabels` - працює так само як і `.spec.selector` у [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/). +- `matchExpressions` - дозволяє будувати складніші селектори, вказуючи ключ, список значень та оператор, який повʼязує ключ і значення. + +Коли вказані обидва, результат є має мати збіг з обома. + +`.spec.selector` повинен відповідати `.spec.template.metadata.labels`. Конфігурація з цими двома несумісними буде відхилена API. + +### Запуск Podʼів на вибраних вузлах {#running-pods-on-selected-nodes} + +Якщо ви вказуєте `.spec.template.spec.nodeSelector`, тоді контролер DaemonSet буде +створювати Podʼи на вузлах, які відповідають [селектору вузла](/docs/concepts/scheduling-eviction/assign-pod-node/). Так само, якщо ви вказуєте `.spec.template.spec.affinity`, тоді контролер DaemonSet буде створювати Podʼи на вузлах, які відповідають цій [спорідненості вузла](/docs/concepts/scheduling-eviction/assign-pod-node/). Якщо ви не вказали жодного з них, контролер DaemonSet буде створювати Podʼи на всіх вузлах. + +## Як заплановані Daemon Podʼи {#how-daemon-pods-are-scheduled} + +DaemonSet може бути використаний для того, щоб забезпечити, щоб всі придатні вузли запускали копію Podʼа. Контролер DaemonSet створює Pod для кожного придатного вузла та додає поле `spec.affinity.nodeAffinity` Podʼа для відповідності цільовому хосту. Після створення Podʼа, зазвичай вступає в дію типовий планувальник і привʼязує Pod до цільового хосту, встановлюючи поле `.spec.nodeName`. Якщо новий Pod не може поміститися на вузлі, типовий планувальник може здійснити перерозподіл (витіснення) деяких наявних Podʼів на основі [пріоритету](/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) нового Podʼа. + +{{< note >}} +Якщо важливо, щоб Pod DaemonSet запускався на кожному вузлі, часто бажано встановити `.spec.template.spec.priorityClassName` DaemonSet на [PriorityClass](/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass) з вищим пріоритетом, щоб забезпечити витіснення. +{{< /note >}} + +Користувач може вказати інший планувальник для Podʼів DaemonSet, встановивши поле `.spec.template.spec.schedulerName` DaemonSet. + +Оригінальний афінітет вузла, вказаний в полі `.spec.template.spec.affinity.nodeAffinity` (якщо вказано), береться до уваги контролером DaemonSet при оцінці придатних вузлів, але замінюється на афінітет вузла, який відповідає імені +придатного вузла, на створеному Podʼі. + +```yaml +nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchFields: + - key: metadata.name + operator: In + values: + - target-host-name +``` + +### Taint та toleration {#taints-and-tolerations} + +Контролер DaemonSet автоматично додає набір {{< glossary_tooltip text="toleration" term_id="toleration" >}} до Podʼів DaemonSet: + +{{< table caption="Toleration для Podʼів DaemonSet" >}} + +| Ключ толерантності | Ефект | Деталі | +| --------------------------------------------------------------------------------------------------------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | +| [`node.kubernetes.io/not-ready`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-not-ready) | `NoExecute` | Podʼи DaemonSet можуть бути заплановані на вузли, які не є справними або готовими приймати Podʼи. Будь-які Podʼи DaemonSet, які працюють на таких вузлах, не будуть витіснені. | +| [`node.kubernetes.io/unreachable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-unreachable) | `NoExecute` | Podʼи DaemonSet можуть бути заплановані на вузли, які недоступні з контролера вузла. Будь-які Podʼи DaemonSet, які працюють на таких вузлах, не будуть витіснені. | +| [`node.kubernetes.io/disk-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-disk-pressure) | `NoSchedule` | Podʼи DaemonSet можуть бути заплановані на вузли із проблемами дискового тиску. | +| [`node.kubernetes.io/memory-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-memory-pressure) | `NoSchedule` | Podʼи DaemonSet можуть бути заплановані на вузли із проблемами памʼяті. | +| [`node.kubernetes.io/pid-pressure`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-pid-pressure) | `NoSchedule` | Podʼи DaemonSet можуть бути заплановані на вузли з проблемами процесів. | +| [`node.kubernetes.io/unschedulable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-unschedulable) | `NoSchedule` | Podʼи DaemonSet можуть бути заплановані на вузли, які не можна планувати. | +| [`node.kubernetes.io/network-unavailable`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-network-unavailable) | `NoSchedule` | **Додається лише для Podʼів DaemonSet, які запитують мережу вузла**, тобто Podʼи з `spec.hostNetwork: true`. Такі Podʼи DaemonSet можуть бути заплановані на вузли із недоступною мережею.| + +{{< /table >}} + +Ви можете додавати свої толерантності до Podʼів DaemonSet, визначивши їх в шаблоні Podʼа DaemonSet. + +Оскільки контролер DaemonSet автоматично встановлює толерантність `node.kubernetes.io/unschedulable:NoSchedule`, Kubernetes може запускати Podʼи DaemonSet на вузлах, які відзначені як _unschedulable_. + +Якщо ви використовуєте DaemonSet для надання важливої функції на рівні вузла, такої як [мережа кластера](/docs/concepts/cluster-administration/networking/), то корисно, що Kubernetes розміщує Podʼи DaemonSet на вузлах до того, як вони будуть готові. Наприклад, без цієї спеціальної толерантності ви можете опинитися в тупиковій ситуації, коли вузол не позначений як готовий, тому що мережевий втулок не працює там, і в той самий час мережевий втулок не працює на цьому вузлі, оскільки вузол ще не готовий. + +## Взаємодія з Daemon Podʼами {#communicating-with-daemon-pods} + +Деякі можливі шаблони для взаємодії з Podʼами у DaemonSet: + +- **Push**: Podʼи в DaemonSet налаштовані надсилати оновлення до іншого сервісу, такого як база статистики. У них немає клієнтів. +- **NodeIP та відомий порт**: Podʼи в DaemonSet можуть використовувати `hostPort`, щоб їх можна було знайти за IP-адресою вузла. Клієнти певним чином знають стандартний список IP-адрес вузлів і порти. +- **DNS**: Створіть [headless сервіс](/docs/concepts/services-networking/service/#headless-services) за таким же вибором Podʼа, а потім виявіть DaemonSet, використовуючи ресурс `endpoints` або отримайте кілька записів A з DNS. +- **Сервіс**: Створіть сервіс із тим самим вибором Podʼа та використовуйте сервіс для зʼєднання з демоном на випадковому вузлі. (Немає способу зʼєднатися напряму з конкретним Podʼом.) + +## Оновлення DaemonSet {#updating-a-daemonset} + +Якщо мітки вузлів змінюються, DaemonSet негайно додає Podʼи на нові відповідні вузли та видаляє Podʼи на нових не відповідних вузлах. + +Ви можете змінювати Podʼи, які створює DaemonSet. Проте Podʼи не дозволяють оновлювати всі поля. Крім того, контролер DaemonSet буде використовувати початковий шаблон при наступному створенні вузла (навіть з тим самим імʼям). + +Ви можете видалити DaemonSet. Якщо ви вказали `--cascade=orphan` з `kubectl`, тоді Podʼи залишаться на вузлах. Якщо ви потім створите новий DaemonSet з тим самим селектором, новий DaemonSet прийме наявні Podʼи. Якщо потрібно замінити які-небудь Podʼи, DaemonSet їх замінює згідно з його `updateStrategy`. + +Ви можете [виконати поетапне оновлення](/docs/tasks/manage-daemon/update-daemon-set/) DaemonSet. + +## Альтернативи DaemonSet {#alternatives-to-daemonset} + +### Скрипти ініціалізації {#init-scripts} + +Звичайно, можливо запускати процеси демонів, безпосередньо стартуючи їх на вузлі (наприклад, за допомогою `init`, `upstartd` або `systemd`). Це абсолютно прийнятно. Однак існують кілька переваг запуску таких процесів через DaemonSet: + +- Можливість моніторингу та управління логами для демонів так само як і для застосунків. +- Однакова мова конфігурації та інструменти (наприклад, шаблони Podʼа, `kubectl`) для демонів та застосунків. +- Запуск демонів у контейнерах з обмеженням ресурсів підвищує ізоляцію між демонами та контейнерами застосунків. Однак це також можна досягти, запускаючи демонів у контейнері, але не в Podʼі. + +### Тільки Podʼи {#bare-pods} + +Можливо створити Podʼи безпосередньо, вказуючи певний вузол для запуску. Проте DaemonSet замінює Podʼи, які видаляються або завершуються з будь-якої причини, такої як збій вузла або руйнівне обслуговування вузла, наприклад, оновлення ядра. З цієї причини слід використовувати DaemonSet замість створення тільки Podʼів. + +### Статичні Podʼи {#static-pods} + +Можливо створити Podʼи, записавши файл у певну теку, що спостерігається Kubelet. Їх називають [статичними Podʼами](/docs/tasks/configure-pod-container/static-pod/). На відміну від DaemonSet, статичними Podʼами не можна управляти за допомогою `kubectl` або інших клієнтів API Kubernetes. Статичні Podʼи не залежать від apiserver, що робить їх корисними в разі початкового налаштування кластера. Однак, статичні Podʼи можуть бути застарілими у майбутньому. + +### Deployments + +DaemonSet схожий на [Розгортання (Deployments)](/docs/concepts/workloads/controllers/deployment/) тим, що обидва створюють Podʼи, і ці Podʼи мають процеси, які не очікується, що завершаться (наприклад, вебсервери, сервери сховищ). + +Використовуйте Розгортання для stateless служб, таких як фронтенди, де важливо збільшувати та зменшувати кількість реплік та розгортати оновлення. Використовуйте DaemonSet, коли важливо, щоб копія Podʼа завжди працювала на всіх або певних вузлах, якщо DaemonSet надає функціональність рівня вузла, яка дозволяє іншим Podʼам правильно працювати на цьому конкретному вузлі. + +Наприклад, [мережеві втулки](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) часто включають компонент, який працює як DaemonSet. Цей компонент DaemonSet переконується, що вузол, де він працює, має справну кластерну мережу. + +## {{% heading "whatsnext" %}} + +- Дізнайтеся більше про [Podʼи](/docs/concepts/workloads/pods). + - Дізнайтеся про [статичні Podʼи](#static-pods), які корисні для запуску компонентів {{< glossary_tooltip text="панелі управління" term_id="control-plane" >}} Kubernetes. +- Дізнайтеся, як використовувати DaemonSets + - [Виконати поетапне оновлення DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/) + - [Виконати відкат DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/) (наприклад, якщо розгортання не працює так, як ви очікували). +- Дізнайтесь [як Kubernetes призначає Podʼи вузлам](/docs/concepts/scheduling-eviction/assign-pod-node/). +- Дізнайтеся про [втулки пристроїв](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) та [надбудови](/docs/concepts/cluster-administration/addons/), які часто працюють як DaemonSets. +- `DaemonSet` — це ресурс верхнього рівня у Kubernetes REST API. Ознайомтесь з визначенням обʼєкта {{< api-reference page="workload-resources/daemon-set-v1" >}}, щоб зрозуміти API для DaemonSet. diff --git a/content/uk/docs/concepts/workloads/controllers/deployment.md b/content/uk/docs/concepts/workloads/controllers/deployment.md new file mode 100644 index 0000000000000..4e27dae253884 --- /dev/null +++ b/content/uk/docs/concepts/workloads/controllers/deployment.md @@ -0,0 +1,1269 @@ +--- +reviewers: +- janetkuo +title: Deployment +feature: + title: Автоматизоване розгортання та згортання + description: > + Kubernetes поступово впроваджує зміни до вашого застосунку або його конфігурації, одночасно відстежуючи його стан, щоб переконатися, що він не припиняє роботу всіх робочів екземплярів застосунку одночасно. Якщо щось піде не так, Kubernetes відкотить зміни за вас. Скористайтесь перевагами зростаючої екосистеми рішень для розгортання. +description: >- + Deployment керує набором екземплярів Podʼів та їх робочими навантаженнями, як правило, тими, що не зберігають стан. +content_type: concept +weight: 10 +hide_summary: true # Listed separately in section index +--- + + + +_Розгортання (Deployment)_ забезпечує декларативні оновлення для {{< glossary_tooltip text="Podʼів" term_id="pod" >}} та {{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}. + +Ви описуєте _бажаний стан_ у Deployment, і {{< glossary_tooltip term_id="controller" >}} Deployment змінює фактичний стан на бажаний стан з контрольованою швидкістю. Ви можете визначити Deployment для створення нових ReplicaSets або видалення існуючих Deployment та прийняття всіх їхніх ресурсів новими Deployment. + +{{< note >}} +Не керуйте ReplicaSets, що належать Deployment. Розгляньте можливість створення тікета в основному репозиторії Kubernetes, якщо ваш випадок використання не врахований нижче. +{{< /note >}} + + + +## Сценарії використання {#use-cases} + +Наступні сценарії є типовими для Deployment: + +* [Створення Deployment для розгортання набору ReplicaSet](#creating-a-deployment). ReplicaSet створює Podʼи у фоновому режимі. Перевірте стан розгортання, щоб переконатися, чи воно успішне чи ні. +* [Оголошення нового стану Podʼів](#updating-a-deployment) шляхом оновлення PodTemplateSpec в Deployment. Створюється новий ReplicaSet, і Deployment відповідає за переміщення Podʼів зі старого ReplicaSet на новий з контрольованою швидкістю. Кожен новий ReplicaSet оновлює ревізію Deployment. +* [Відкат до попередньої ревізії Deployment](#rolling-back-a-deployment), якщо поточний стан Deployment нестабільний. Кожен відкат оновлює ревізію Deployment. +* [Масштабування Deployment для обробки більшого навантаження](#scaling-a-deployment). +* [Призупинення Deployment](#pausing-and-resuming-a-deployment), щоб застосувати кілька виправлень до його PodTemplateSpec, а потім відновити його для початку нового розгортання. +* [Використання стану Deployment](#deployment-status) як індикатора того, що розгортання зупинилося. +* [Очищення старих ReplicaSets](#clean-up-policy), які вам більше не потрібні. + +## Створення Deployment {#creating-a-deployment} + +Розглянемо приклад Deployment. Він створює ReplicaSet для запуску трьох Podʼів `nginx`: + +{{% code_sample file="controllers/nginx-deployment.yaml" %}} + +В цьому прикладі: + +* Створюється Deployment з назвою`nginx-deployment`, назва вказується в полі `.metadata.name`. Ця назва буде основою для ReplicaSets та Podʼів які буде створено потім. Дивіться [Написання Deployment Spec](#writing-a-deployment-spec) для отримання додаткових відомостей. +* Deployment створює ReplicaSet, який створює три реплікованих Podʼи, кількість зазначено у полі `.spec.replicas`. +* Поле `.spec.selector` визначає як створений ReplicaSet відшукує Podʼи для керування. В цьому випадку вибирається мітка, яка визначена в шаблоні Pod, `app: nginx`. Однак можливі складніші правила вибору, якщо шаблон Pod задовольняє це правило. + + {{< note >}} + Поле `.spec.selector.matchLabels` є масивом пар {key,value}. Одна пара {key,value} у `matchLabels` еквівалентна елементу `matchExpressions`, де поле `key` — "key", `operator` — "In", а масив `values` містить лише "value". Всі умови, як від `matchLabels`, так і від `matchExpressions`, повинні бути виконані для отримання збігу. + {{< /note >}} + +* Поле `template` має наступні вкладені поля: + * Podʼи позначаються міткою `app: nginx` з поля `.metadata.labels`. + * Шаблон специфікації Podʼа, поле `.template.spec`, вказує на те, що Podʼи використовують один контейнер, `nginx`, який використовує образ `nginx` з [Docker Hub](https://hub.docker.com/) версія якого – 1.14.2. + * Створюється один контейнер, який отримує назву `nginx`, яка вказана в полі `.spec.template.spec.containers[0].name`. + +Перед тим, як почати, переконайтеся, що ваш кластер Kubernetes працює. Дотримуйтесь наведених нижче кроків для створення Deployment: + +1. Створіть Deployment скориставшись командою: + + ```shell + kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml + ``` + +2. Виконайте `kubectl get deployments` для перевірки створення Deployment. + + Якщо Deployment все ще створюється, ви побачите вивід подібний цьому: + + ```none + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 0/3 0 0 1s + ``` + + Коли ви досліджуєте Deploymentʼи у вашому кластері, показуються наступні поля: + * `NAME` — містить назву Deploymentʼів у просторі імен. + * `READY` — показує скільки реплік застосунку доступно користувачам. Значення відповідає шаблону наявно/бажано. + * `UP-TO-DATE` — показує кількість реплік, які були оновлені для досягнення бажаного стану. + * `AVAILABLE` — показує скільки реплік доступно користувачам. + * `AGE` — показує час впродовж якого застосунок працює. + + Notice how the number of desired replicas is 3 according to `.spec.replicas` field. + +3. Для перевірки стану розгортання Deployment, виконайте `kubectl rollout status deployment/nginx-deployment`. + + Має бути подібний вивід: + + ```none + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + deployment "nginx-deployment" successfully rolled out + ``` + +4. Запустіть `kubectl get deployments` знов через кілька секунд. Має бути подібний вивід: + + ```none + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 18s + ``` + + Бачите, що Deployment створив три репліки, і всі репліки актуальні (вони містять останній шаблон Pod) та доступні. + +5. Для перевірки ReplicaSet (`rs`), створених Deployment, виконайте `kubectl get rs`. Має бути подібний вивід: + + ```none + NAME DESIRED CURRENT READY AGE + nginx-deployment-75675f5897 3 3 3 18s + ``` + + Вивід ReplicaSet має наступні поля: + + * `NAME` — перелік назв ReplicaSets в просторі імен. + * `DESIRED` — показує бажану кількість _реплік_ застосунку, яку ви вказали при створенні Deployment. Це — _бажаний стан_. + * `CURRENT` — показує поточну кількість реплік, що працюють на поточний момент. + * `READY` — показує скільки реплік застосунку доступно користувачам. + * `AGE` — показує час впродовж якого застосунок працює. + + Зверніть увагу, що назва ReplicaSet завжди складається як `[DEPLOYMENT-NAME]-[HASH]`. Ця назва буде основою для назв Podʼів, які буде створено потім. + + Рядок `HASH` є відповідником мітки `pod-template-hash` в ReplicaSet. + +6. Для ознайомлення з мітками, які було створено для кожного Pod, виконайте `kubectl get pods --show-labels`. + Вивід буде схожим на це: + + ```none + NAME READY STATUS RESTARTS AGE LABELS + nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897 + nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897 + nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897 + ``` + + Створений ReplicaSet таким чином переконується, що в наявності є три Podʼи `nginx`. + +{{< note >}} +Ви маєте зазначити відповідний селектор та мітки шаблону Pod в Deployment (тут, `app: nginx`). + +Не використовуйте однакові мітки або селектори з іншими контролерами (включаючи інші Deployments та StatefulSets). Kubernetes не завадить вам це зробити, і якщо кілька контролерів мають селектори, що збігаються, ці контролери можуть конфліктувати та поводитись непередбачувано. +{{< /note >}} + +### Мітка pod-template-hash {#pod-template-hash-label} + +{{< caution >}} +Не змінюйте цю мітку. +{{< /caution >}} + +Мітка `pod-template-hash` додається контролером Deployment до кожного ReplicaSet, який створює або бере під нагляд Deployment. + +Ця мітка забезпечує унікальність дочірніх ReplicaSets Deploymentʼа. Вона генерується шляхом хешування `PodTemplate` ReplicaSet, і отриманий хеш використовується як значення мітки, яке додається до селектора ReplicaSet, міток шаблону Podʼа, а також до всіх наявних Podʼів, які можуть бути у ReplicaSet. + +## Оновлення Deployment {#updating-a-deployment} + +{{< note >}} +Оновлення Deployment викликається тільки в тому випадку, якщо шаблон Deployment Podʼу (тобто `.spec.template`) змінився, наприклад, якщо оновлено мітки чи образ контейнера шаблону. Інші оновлення, такі як масштабування Deployment, не викликають розгортання. +{{< /note >}} + +Дотримуйтеся поданих нижче кроків для оновлення вашого Deployment: + +1. Оновіть Podʼи nginx, щоб використовувати образ `nginx:1.16.1` замість `nginx:1.14.2`. + + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 + ``` + + або використовуйте наступну команду: + + ```shell + kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + ``` + + де `deployment/nginx-deployment` вказує на Deployment, `nginx` — на контейнер, який буде оновлено, і `nginx:1.16.1` — на новий образ та його теґ. + + Вивід буде схожий на: + + ```none + deployment.apps/nginx-deployment image updated + ``` + + Альтернативно, ви можете відредагувати розгортання і змінити `.spec.template.spec.containers[0].image` з `nginx:1.14.2` на `nginx:1.16.1`: + + ```shell + kubectl edit deployment/nginx-deployment + ``` + + Вивід буде схожий на: + + ```none + deployment.apps/nginx-deployment edited + ``` + +2. Щоб перевірити статус розгортання, виконайте: + + ```shell + kubectl rollout status deployment/nginx-deployment + ``` + + Вивід буде схожий на це: + + ```none + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + ``` + + або + + ```none + deployment "nginx-deployment" successfully rolled out + ``` + +Отримайте більше деталей про ваш оновлений Deployment: + +* Після успішного розгортання можна переглянути Deployment за допомогою `kubectl get deployments`. Вивід буде схожий на це: + + ```ini + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 36s + ``` + +* Виконайте `kubectl get rs`, щоб перевірити, що Deployment оновив Podʼи, створивши новий ReplicaSet та масштабував його до 3 реплік, а також зменшивши розмір старого ReplicaSet до 0 реплік. + + ```shell + kubectl get rs + ``` + + Вивід схожий на це: + + ```none + NAME DESIRED CURRENT READY AGE + nginx-deployment-1564180365 3 3 3 6s + nginx-deployment-2035384211 0 0 0 36s + ``` + +* Виклик `get pods` повинен тепер показати лише нові Podʼи: + + ```shell + kubectl get pods + ``` + + Вивід буде схожий на це: + + ```none + NAME READY STATUS RESTARTS AGE + nginx-deployment-1564180365-khku8 1/1 Running 0 14s + nginx-deployment-1564180365-nacti 1/1 Running 0 14s + nginx-deployment-1564180365-z9gth 1/1 Running 0 14s + ``` + + Наступного разу, коли вам потрібно буде оновити ці Podʼи, вам достатньо буде знову оновити шаблон Podʼу в Deployment. + + Deployment забезпечує, що тільки певна кількість Podʼів буде відключена під час оновлення. Типово це забезпечує, що принаймні 75% відомої кількості Podʼів будуть активними (максимум недоступних 25%). + + Deployment також забезпечує, що тільки певна кількість Podʼів буде створена поверх відомої кількості Podʼів. Типово це забезпечує, що як максимум буде активно 125% відомої кількості Podʼів (25% максимального збільшення). + + Наприклад, якщо ви ретельно досліджуєте Deployment вище, ви побачите, що спочатку було створено новий Pod, потім видалено старий Pod і створено ще один новий. Старі Podʼи не прибираються допоки не зʼявиться достатня кількість нових, і не створюються нові Podʼи допоки не буде прибрано достатню кількість старих. Deployment переконується, що принаймні 3 Podʼи доступні, і що вони не перевищують 4 Podʼа. У випадку розгортання з 4 репліками кількість Podʼів буде між 3 і 5. + +* Отримайте деталі вашого розгортання: + + ```shell + kubectl describe deployments + ``` + + Вивід буде схожий на це: + + ```none + Name: nginx-deployment + Namespace: default + CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=2 + Selector: app=nginx + Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.16.1 + Port: 80/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created) + Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3 + Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1 + Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2 + Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2 + Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1 + Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 + Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 + ``` + + Тут ви бачите, що при створенні Deployment спочатку було створено ReplicaSet (nginx-deployment-2035384211) та масштабовано його до 3 реплік безпосередньо. Коли ви оновили Deployment, було створено новий ReplicaSet (nginx-deployment-1564180365) та масштабовано його до 1, потім Deployment дочекався, коли він запуститься. Потім було зменшено розмір старого ReplicaSet + до 2 і масштабовано новий ReplicaSet до 2, таким чином, щоб принаймні 3 Podʼа були доступні, і не більше 4 Podʼів в будь-який момент. Потім було продовжено масштабування нового та старого ReplicaSet, з однаковою стратегією поетапного оновлення. У кінці вас буде 3 доступні репліки в новому ReplicaSet, і старий ReplicaSet зменшений до 0. + +{{< note >}} +Kubernetes не враховує Podʼи, які завершують роботу, коли розраховує кількість `availableReplicas`, яка повинна бути між `replicas - maxUnavailable` та `replicas + maxSurge`. Внаслідок цього ви можете помітити, що під час розгортання є більше Podʼів, ніж очікувалося, і що загальні ресурси, які використовує Deployment, перевищують `replicas + maxSurge` до того моменту, поки не мине `terminationGracePeriodSeconds` для Podʼів, що завершують роботу. +{{< /note >}} + +### Rollover (або кілька одночасних оновлень) {#rollover-and-multiple-updates-in-flight} + +Кожного разу, коли новий Deployment спостерігається контролером Deployment, ReplicaSet створюється для запуску необхідних Podʼів. Якщо Deployment оновлюється, поточний ReplicaSet, Podʼи якого збігаються з міткам з `.spec.selector`, але не збігаються з `.spec.template`, зменшується. Зрештою, новий ReplicaSet масштабується до `.spec.replicas`, і всі старі ReplicaSets масштабуються в 0. + +Якщо ви оновите Deployment під час вже поточного процесу розгортання, Deployment створить новий ReplicaSet відповідно до оновлення і почне масштабувати його, і розвертати ReplicaSet, який він раніше масштабував — він додасть його до списку старих ReplicaSets та почне зменшувати його. + +Наприклад, припустимо, ви створюєте Deployment для створення 5 реплік `nginx:1.14.2`, але потім оновлюєте Deployment для створення 5 реплік `nginx:1.16.1`, коли вже створено тільки 3 репліки `nginx:1.14.2`. У цьому випадку Deployment негайно починає +знищувати 3 Podʼи `nginx:1.14.2`, які вже створено, і починає створювати +Podʼи `nginx:1.16.1`. Deployment не чекає, доки буде створено 5 реплік `nginx:1.14.2`, перш ніж змінити напрямок. + +### Оновлення селектора міток {#label-selector-updates} + +Зазвичай не рекомендується вносити оновлення до селектора міток, і рекомендується планувати ваші селектори наперед. У будь-якому випадку, якщо вам потрібно виконати оновлення селектора міток, дійте з великою обережністю і переконайтеся, що ви розумієте всі його наслідки. + +{{< note >}} +В API-версії `apps/v1` селектор міток Deployment є незмінним після створення. +{{< /note >}} + +* Додавання селектора вимагає оновлення міток шаблону Podʼа в специфікації Deployment новою міткою, інакше буде повернуто помилку перевірки. Ця зміна не є такою, що перетинається з наявними мітками, що означає, що новий селектор не вибирає ReplicaSets та Podʼи, створені за допомогою старого селектора, що призводить до залишення всіх старих ReplicaSets та створення нового ReplicaSet. +* Оновлення селектора змінює поточне значення ключа селектора — призводить до такого ж результату, як і додавання. +* Вилучення селектора вилучає наявний ключ з селектора Deployment — не вимагає будь-яких змін у мітках шаблону Podʼа. Наявні ReplicaSets не залишаються сиротами, і новий ReplicaSet не створюється, але слід зауважити, що вилучена мітка все ще існує в будь-яких наявних Podʼах і ReplicaSets. + +## Відкат Deployment {#rolling-back-a-deployment} + +Іноді вам може знадобитися відкотити Deployment, наприклад, коли Deployment нестабільний, наприклад цикл постійних помилок. Типово, вся історія Deployment зберігається в системі, щоб ви могли відкотити його в будь-який час (ви можете змінити це, змінивши обмеження історії ревізій). + +{{< note >}} +Ревізія Deployment створюється, коли спрацьовує Deployment. Це означає, що нова ревізія створюється тільки тоді, коли змінюється шаблон Podʼа Deployment (`.spec.template`), наприклад, якщо ви оновлюєте мітки або образи контейнера в шаблоні. Інші оновлення, такі як масштабування Deployment, не створюють ревізію Deployment, щоб ви могли одночасно використовувати ручне або автоматичне масштабування. Це означає, що при відкаті до попередньої ревізії повертається лише частина шаблону Podʼа Deployment. +{{< /note >}} + +* Припустимо, ви припустилися помилки при оновленні Deployment, вказавши назву образу як `nginx:1.161` замість `nginx:1.16.1`: + + ```shell + kubectl set image deployment/nginx-deployment nginx=nginx:1.161 + ``` + + Вивід буде подібний до цього: + + ```none + deployment.apps/nginx-deployment image updated + ``` + +* Розгортання застрягає. Ви можете перевірити це, перевіривши стан розгортання: + + ```shell + kubectl rollout status deployment/nginx-deployment + ``` + + Вивід буде подібний до цього: + + ```none + Waiting for rollout to finish: 1 out of 3 new replicas have been updated... + ``` + +* Натисніть Ctrl-C, щоб зупинити спостереження за станом розгортання. Щодо деталей розгортання, що застрягло, [читайте тут](#deployment-status). + +* Ви бачите, що кількість старих реплік (додаючи кількість реплік від `nginx-deployment-1564180365` та `nginx-deployment-2035384211`) — 3, а кількість нових реплік (від `nginx-deployment-3066724191`) — 1. + + ```shell + kubectl get rs + ``` + + Вивід буде подібний до цього: + + ```none + NAME DESIRED CURRENT READY AGE + nginx-deployment-1564180365 3 3 3 25s + nginx-deployment-2035384211 0 0 0 36s + nginx-deployment-3066724191 1 1 0 6s + ``` + +* При перегляді створених Podʼів ви бачите, що 1 Pod, створений новим ReplicaSet, застряг у циклі завантаження образу. + + ```shell + kubectl get pods + ``` + + Вивід буде подібний до цього: + + ```none + NAME READY STATUS RESTARTS AGE + nginx-deployment-1564180365-70iae 1/1 Running 0 25s + nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s + nginx-deployment-1564180365-hysrc 1/1 Running 0 25s + nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s + ``` + + {{< note >}} + Контролер Deployment автоматично зупиняє невдале розгортання та припиняє масштабування нового ReplicaSet. Це залежить від параметрів rollingUpdate (`maxUnavailable`), які ви вказали. Стандартно Kubernetes встановлює значення 25%. + {{< /note >}} + +* Отримання опису розгортання: + + ```shell + kubectl describe deployment + ``` + + Вивід буде подібний до цього: + + ```none + Name: nginx-deployment + Namespace: default + CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 + Labels: app=nginx + Selector: app=nginx + Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.161 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created) + NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created) + Events: + FirstSeen LastSeen Count From SubObjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1 + ``` + + Для виправлення цього вам потрібно відкотитиcm до попередньої ревізії Deployment, яка є стабільною. + +### Перевірка історії розгортання Deployment {#checking-rollout-history-of-a-deployment} + +Виконайте наведені нижче кроки, щоб перевірити історію розгортань: + +1. По-перше, перевірте ревізії цього Deployment: + + ```shell + kubectl rollout history deployment/nginx-deployment + ``` + + Вивід буде подібний до цього: + + ```none + deployments "nginx-deployment" + REVISION CHANGE-CAUSE + 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml + 2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + 3 kubectl set image deployment/nginx-deployment nginx=nginx:1.161 + ``` + + `CHANGE-CAUSE` копіюється з анотації Deployment `kubernetes.io/change-cause` до його ревізій при створенні. Ви можете вказати повідомлення `CHANGE-CAUSE`: + + * Анотуючи Deployment командою `kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` + * Ручним редагуванням маніфесту ресурсу. + +2. Щоб переглянути деталі кожної ревізії, виконайте: + + ```shell + kubectl rollout history deployment/nginx-deployment --revision=2 + ``` + + Вивід буде подібний до цього: + + ```none + deployments "nginx-deployment" revision 2 + Labels: app=nginx + pod-template-hash=1159050644 + Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + Containers: + nginx: + Image: nginx:1.16.1 + Port: 80/TCP + QoS Tier: + cpu: BestEffort + memory: BestEffort + Environment Variables: + No volumes. + ``` + +### Відкат до попередньої ревізії {#rolling-back-to-a-previous-revision} + +Виконайте наведені нижче кроки, щоб відкотити Deployment з поточної версії на попередню версію, яка є версією 2. + +1. Тепер ви вирішили скасувати поточне розгортання та повернутися до попередньої ревізії: + + ```shell + kubectl rollout undo deployment/nginx-deployment + ``` + + Вивід буде подібний до цього: + + ``` + deployment.apps/nginx-deployment rolled back + ``` + + Замість цього ви можете виконати відкат до певної ревізії, вказавши її параметром `--to-revision`: + + ```shell + kubectl rollout undo deployment/nginx-deployment --to-revision=2 + ``` + + Вивід буде подібний до цього: + + ``` + deployment.apps/nginx-deployment rolled back + ``` + + Для отримання додаткових відомостей про команди, повʼязані з розгортаннями, читайте [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout). + + Deployment тепер повернуто до попередньої стабільної ревізії. Як ви можете бачити, контролер розгортань генерує подію `DeploymentRollback` щодо відкату до ревізії 2. + +2. Перевірте, чи відкат був успішним і Deployment працює як очікується, виконавши: + + ```shell + kubectl get deployment nginx-deployment + ``` + + Вивід буде подібний до цього: + + ```none + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 30m + ``` + +3. Отримайте опис розгортання: + + ```shell + kubectl describe deployment nginx-deployment + ``` + + Вивід подібний до цього: + + ```none + Name: nginx-deployment + Namespace: default + CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=4 + kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + Selector: app=nginx + Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.16.1 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created) + Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1 + Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2 + Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0 + ``` + +### Масштабування Deployment {#scaling-a-deployment} + +Ви можете масштабувати Deployment за допомогою наступної команди: + +```shell +kubectl scale deployment/nginx-deployment --replicas=10 +``` + +Вивід буде подібний до цього: + +```none +deployment.apps/nginx-deployment scaled +``` + +Припускаючи, що [горизонтальне автомасштабування Pod](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) увімкнено у вашому кластері, ви можете налаштувати автомасштабування для вашого Deployment і вибрати мінімальну та максимальну кількість Podʼів, які ви хочете запустити на основі використання ЦП вашими поточними Podʼами. + +```shell +kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80 +``` + +Вивід буде подібний до цього: + +``` +deployment.apps/nginx-deployment scaled +``` + +### Пропорційне масштабування {#proportional-scaling} + +Deployment RollingUpdate підтримує виконання кількох версій застосунку одночасно. Коли ви або автомасштабування масштабуєте Deployment RollingUpdate, яке знаходиться в процесі розгортання (будь-то в процесі або призупинено), контролер Deployment балансує додаткові репліки в наявних активних ReplicaSets (ReplicaSets з Podʼами), щоб помʼякшити ризик. Це називається _пропорційним масштабуванням_. + +Наприклад, ви використовуєте Deployment з 10 репліками, [maxSurge](#max-surge)=3 та [maxUnavailable](#max-unavailable)=2. + +* Переконайтеся, що в вашому Deployment працює 10 реплік. + + ```shell + kubectl get deploy + ``` + + Вивід буде подібний до цього: + + ```none + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 10 10 10 10 50s + ``` + +* Ви оновлюєте образ, який, як виявляється, неможливо знайти в межах кластера. + + ```shell + kubectl set image deployment/nginx-deployment nginx=nginx:sometag + ``` + + Вивід подібний до цього: + + ```none + deployment.apps/nginx-deployment image updated + ``` + +* Оновлення образу розпочинає новий rollout з ReplicaSet nginx-deployment-1989198191, але воно блокується через вимогу `maxUnavailable`, яку ви вказали вище. Перевірте стан rollout: + + ```shell + kubectl get rs + ``` + + Вивід буде подібний до цього: + + ```none + NAME DESIRED CURRENT READY AGE + nginx-deployment-1989198191 5 5 0 9s + nginx-deployment-618515232 8 8 8 1m + ``` + +* Потім надходить новий запит на масштабування для Deployment. Автомасштабування збільшує репліки Deployment до 15. Контролер Deployment повинен вирішити, куди додати цих нових 5 реплік. Якби ви не використовували пропорційне масштабування, всі 5 реплік були б додані в новий ReplicaSet. З пропорційним масштабуванням ви розподіляєте додаткові репліки між всіма ReplicaSets. Більші частки йдуть в ReplicaSets з найбільшою кількістю реплік, а менші частки йдуть в ReplicaSets з меншою кількістю реплік. Залишки додаються до ReplicaSet з найбільшою кількістю реплік. ReplicaSets з нульовою кількістю реплік не масштабуються. + +У нашому прикладі вище 3 репліки додаються до старого ReplicaSet, а 2 репліки — до нових ReplicaSet. Процес розгортання повинен остаточно перемістити всі репліки в новий ReplicaSet, за умови, що нові репліки стають справними. Для підтвердження цього виконайте: + +```shell +kubectl get deploy +``` + +Вивід буде подібний до цього: + +```none +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 15 18 7 8 7m +``` + +Статус rollout підтверджує, як репліки були додані до кожного ReplicaSet. + +```shell +kubectl get rs +``` + +Вивід буде подібний до цього: + +```none +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 7 7 0 7m +nginx-deployment-618515232 11 11 11 7m +``` + +### Призупинення та відновлення розгортання Deployment {#pausing-and-resuming-a-deployment} + +При оновленні Deployment або плануванні оновлення ви можете призупинити розгортання для цього Deployment перед тим, як запустити одне чи кілька оновлень. Коли ви готові застосувати зміни, ви відновлюєте розгортання для Deployment. Цей підхід дозволяє вам застосовувати кілька виправлень між призупиненням та відновленням без зайвих розгортань. + +* Наприклад, з Deployment, яке було створено: + + Отримайте деталі Deployment: + + ```shell + kubectl get deploy + ``` + + Вивід буде подібний до цього: + + ```none + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx 3 3 3 3 1m + ``` + + Отримайте стан розгортання: + + ```shell + kubectl get rs + ``` + + Вивід буде подібний до цього: + + ```none + NAME DESIRED CURRENT READY AGE + nginx-2142116321 3 3 3 1m + ``` + +* Зробіть паузу за допомогою наступної команди: + + ```shell + kubectl rollout pause deployment/nginx-deployment + ``` + + Вивід буде подібний до цього: + + ```none + deployment.apps/nginx-deployment paused + ``` + +* Потім оновіть образ в Deployment: + + ```shell + kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + ``` + + Вивід буде подібний до цього: + + ```none + deployment.apps/nginx-deployment image updated + ``` + +* Зверніть увагу, що новий rollout не розпочався: + + ```shell + kubectl rollout history deployment/nginx-deployment + ``` + + Вивід буде подібний до цього: + + ```none + deployments "nginx" + REVISION CHANGE-CAUSE + 1 + ``` + +* Отримайте стан розгортання, щоб перевірити, що існуючий ReplicaSet не змінився: + + ```shell + kubectl get rs + ``` + + Вивід буде подібний до цього: + + ```none + NAME DESIRED CURRENT READY AGE + nginx-2142116321 3 3 3 2m + ``` + +* Ви можете робити стільки оновлень, скільки вам потрібно, наприклад, оновіть ресурси, які будуть використовуватися: + + ```shell + kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi + ``` + + Вивід буде подібний до цього: + + ```none + deployment.apps/nginx-deployment resource requirements updated + ``` + + Початковий стан Deployment перед призупиненням його rollout продовжить свою роботу, але нові оновлення до Deployment не матимуть жодного впливу, поки розгортання Deployment призупинено. + +* У кінці відновіть розгортання Deployment і спостерігайте, як новий ReplicaSet зʼявляється з усіма новими оновленнями: + + ```shell + kubectl rollout resume deployment/nginx-deployment + ``` + + Вивід буде подібний до цього: + + ```none + deployment.apps/nginx-deployment resumed + ``` + +* Спостерігайте за статусом розгортання, доки воно не завершиться. + + ```shell + kubectl get rs -w + ``` + + Вивід буде подібний до цього: + + ```none + NAME DESIRED CURRENT READY AGE + nginx-2142116321 2 2 2 2m + nginx-3926361531 2 2 0 6s + nginx-3926361531 2 2 1 18s + nginx-2142116321 1 2 2 2m + nginx-2142116321 1 2 2 2m + nginx-3926361531 3 2 1 18s + nginx-3926361531 3 2 1 18s + nginx-2142116321 1 1 1 2m + nginx-3926361531 3 3 1 18s + nginx-3926361531 3 3 2 19s + nginx-2142116321 0 1 1 2m + nginx-2142116321 0 1 1 2m + nginx-2142116321 0 0 0 2m + nginx-3926361531 3 3 3 20s + ``` + +* Отримайте статус останнього розгортання: + + ```shell + kubectl get rs + ``` + + Вивід буде подібний до цього: + + ```none + NAME DESIRED CURRENT READY AGE + nginx-2142116321 0 0 0 2m + nginx-3926361531 3 3 3 28s + ``` + +{{< note >}} +Ви не можете відкотити призупинене розгортання Deployment, доки ви його не відновите. +{{< /note >}} + +### Статус Deployment {#deployment-status} + +Deployment переходить через різні стани протягом свого життєвого циклу. Він може бути [d процесі](#progressing-deployment), коли виконується розгортання нового ReplicaSet, може бути [завершеним](#complete-deployment) або [невдалим](#failed-deployment). + +### Deployment в процесі {#progressing-deployment} + +Kubernetes позначає Deployment як _в процесі_ (progressing), коли виконується одне з наступних завдань: + +* Deployment створює новий ReplicaSet. +* Deployment масштабує вгору свій новий ReplicaSet. +* Deployment масштабує вниз свої старі ReplicaSet(s). +* Нові Podʼи стають готовими або доступними (готові принаймні [MinReadySeconds](#min-ready-seconds)). + +Коли розгортання стає "в процесі" (progressing), контролер Deployment додає умову із наступними атрибутами до `.status.conditions` Deployment: + +* `type: Progressing` +* `status: "True"` +* `reason: NewReplicaSetCreated` | `reason: FoundNewReplicaSet` | `reason: ReplicaSetUpdated` + +Ви можете відстежувати хід розгортання за допомогою `kubectl rollout status`. + +### Завершений Deployment {#complete-deployment} + +Kubernetes позначає Deployment як _завершений_ (complete), коли він має наступні характеристики: + +* Всі репліки, повʼязані з Deployment, були оновлені до останньої версії, яку ви вказали. Це означає, що всі запитані вами оновлення були завершені. +* Всі репліки, повʼязані з Deployment, доступні. +* Не працюють жодні старі репліки для Deployment. + +Коли розгортання стає "завершеним" (complete), контролер Deployment встановлює умову із наступними атрибутами до `.status.conditions` Deployment: + +* `type: Progressing` +* `status: "True"` +* `reason: NewReplicaSetAvailable` + +Ця умова `Progressing` буде зберігати значення статусу `"True"` до тих пір, поки не буде запущено нове розгортання. Умова залишається незмінною навіть тоді, коли змінюється доступність реплік (це не впливає на умову `Available`). + +Ви можете перевірити, чи завершено Deployment, використовуючи `kubectl rollout status`. Якщо Deployment завершився успішно, `kubectl rollout status` повертає код виходу нуль (успіх). + +```shell +kubectl rollout status deployment/nginx-deployment +``` + +Вивід буде схожий на наступний: + +```none +Waiting for rollout to finish: 2 of 3 updated replicas are available... +deployment "nginx-deployment" successfully rolled out +``` + +і код виходу з `kubectl rollout` дорівнює 0 (успіх): + +```shell +echo $? +``` + +```none +0 +``` + +### Невдалий Deployment {#failed-deployment} + +Ваш Deployment може застрягти під час намагання розгорнути свій новий ReplicaSet і ніколи не завершитися. Це може статися через наступне: + +* Недостатні квоти +* Збій проб readiness +* Помилки підтягування образів +* Недостатні дозволи +* Обмеження лімітів +* Неправильна конфігурація середовища виконання застосунку + +Один із способів виявлення цього стану — це вказати параметр граничного терміну в специфікації вашого розгортання: ([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `.spec.progressDeadlineSeconds` вказує кількість секунд, протягом яких контролер Deployment чекатиме, перш ніж вказати (в статусі Deployment), що прогрес розгортання зупинився. + +Наступна команда `kubectl` встановлює специфікацію з `progressDeadlineSeconds`, щоб змусити контролер повідомляти про відсутність прогресу розгортання для Deployment після 10 хвилин: + +```shell +kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' +``` + +Вивід буде схожий на наступний: + +```none +deployment.apps/nginx-deployment patched +``` + +Після того як граничний термін закінчився, контролер Deployment додає DeploymentCondition з наступними атрибутами до `.status.conditions` Deployment: + +* `type: Progressing` +* `status: "False"` +* `reason: ProgressDeadlineExceeded` + +Ця умова також може зазнати невдачі на ранніх етапах, і тоді вона встановлюється в значення статусу `"False"` з причинами, такими як `ReplicaSetCreateError`. Крім того, термін не враховується більше після завершення розгортання. + +Дивіться [Домовленості API Kubernetes](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) для отримання додаткової інформації щодо умов статусу. + +{{< note >}} +Kubernetes не вживає ніяких заходів стосовно до зупиненого Deployment, крім як звітувати про умову статусу з `reason: ProgressDeadlineExceeded`. Оркестратори вищого рівня можуть використовувати це і відповідним чином діяти, наприклад, відкотити Deployment до його попередньої версії. +{{< /note >}} + +{{< note >}} +Якщо ви призупините розгортання Deployment, Kubernetes не перевірятиме прогрес відносно вашого вказаного терміну. Ви можете безпечно призупинити розгортання Deployment в середині процесу розгортання та відновити його, не викликаючи +умову виходу за граничним терміном. +{{< /note >}} + +Ви можете зіткнутися з тимчасовими помилками у Deployment, або через низький таймаут, який ви встановили, або через будь-який інший вид помилок, який можна розглядати як тимчасовий. Наприклад, допустімо, що у вас недостатні квоти. Якщо ви +опишете Deployment, ви помітите наступний розділ: + +```shell +kubectl describe deployment nginx-deployment +``` + +Вивід буде схожий на наступний: + +```none +<...> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + ReplicaFailure True FailedCreate +<...> +``` + +Якщо ви виконаєте `kubectl get deployment nginx-deployment -o yaml`, статус Deployment схожий на це: + +```none +status: + availableReplicas: 2 + conditions: + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: Replica set "nginx-deployment-4262182780" is progressing. + reason: ReplicaSetUpdated + status: "True" + type: Progressing + - lastTransitionTime: 2016-10-04T12:25:42Z + lastUpdateTime: 2016-10-04T12:25:42Z + message: Deployment has minimum availability. + reason: MinimumReplicasAvailable + status: "True" + type: Available + - lastTransitionTime: 2016-10-04T12:25:39Z + last + +UpdateTime: 2016-10-04T12:25:39Z + message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota: + object-counts, requested: pods=1, used: pods=3, limited: pods=2' + reason: FailedCreate + status: "True" + type: ReplicaFailure + observedGeneration: 3 + replicas: 2 + unavailableReplicas: 2 +``` + +В решті решт, коли граничний термін прогресу Deployment буде перевищений, Kubernetes оновить статус і причину умови Progressing: + +```none +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing False ProgressDeadlineExceeded + ReplicaFailure True FailedCreate +``` + +Ви можете вирішити проблему недостатньої квоти, зменшивши масштаб вашого Deployment, зменшивши масштаб інших контролерів, які ви можете виконувати, або збільшивши квоту у вашому просторі імен. Якщо ви задовольните умови квоти +і контролер Deployment завершить розгортання, ви побачите, що статус Deployment оновлюється успішною умовою (`status: "True"` та `reason: NewReplicaSetAvailable`). + +```none +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +``` + +`type: Available` з `status: "True"` означає, що у вас є мінімальна доступність Deployment. Мінімальна доступність визначається параметрами, вказаними в стратегії розгортання. `type: Progressing` з `status: "True"` означає, що ваш Deployment або знаходиться в середині розгортання і прогресує, або він успішно завершив свій прогрес, і доступна мінімально необхідна нова кількість реплік (див. причину умови для конкретики — у нашому випадку `reason: NewReplicaSetAvailable` означає, що Deployment завершено). + +Ви можете перевірити, чи Deployment не вдався за допомогою `kubectl rollout status`. `kubectl rollout status` повертає код виходу, відмінний від нуля, якщо Deployment перевищив граничний термін виконання. + +```shell +kubectl rollout status deployment/nginx-deployment +``` + +Вивід буде схожий на наступний: + +```none +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +error: deployment "nginx" exceeded its progress deadline +``` + +і код виходу з `kubectl rollout` дорівнює 1 (позначає помилку): + +```shell +echo $? +``` + +```none +1 +``` + +### Операції з невдалим Deployment {#operations-on-a-failed-deployment} + +Всі дії, які застосовуються до завершеного Deployment, також застосовуються до невдалого Deployment. Ви можете масштабувати його вгору/вниз, відкотити на попередню ревізію або навіть призупинити, якщо вам потрібно застосувати кілька корекцій у шаблоні Pod Deployment. + +### Політика очищення {#clean-up-policy} + +Ви можете встановити поле `.spec.revisionHistoryLimit` у Deployment, щоб вказати, скільки старих ReplicaSets для цього Deployment ви хочете зберегти. Решта буде видалена як сміття в фоновому режимі. Типове значення становить 10. + +{{< note >}} +Якщо явно встановити це поле на 0, буде виконано очищення всієї історії вашого Deployment, і цей Deployment не зможе виконати відкат. +{{< /note >}} + +## Canary Deployment + +Якщо ви хочете впроваджувати релізи для підмножини користувачів чи серверів, використовуючи Deployment, ви можете створити кілька Deployment, один для кожного релізу, слідуючи шаблону Canary, описаному в [управлінні ресурсами](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments). + +## Написання специфікації Deployment {#writing-a-deployment-spec} + +Як і з усіма іншими конфігураціями Kubernetes, у Deployment потрібні поля `.apiVersion`, `.kind` і `.metadata`. Для загальної інформації щодо роботи з файлами конфігурацій дивіться документи [розгортання застосунків](/docs/tasks/run-application/run-stateless-application-deployment/), [налаштування контейнерів](/docs/tasks/run-application/configure-pod-container/) та [використання kubectl для управління ресурсами](/docs/concepts/overview/working-with-objects/object-management/). + +Коли панель управління створює нові Podʼи для Deployment, `.metadata.name` Deployment є частиною основи для найменування цих Podʼів. Назва Deployment повинна бути дійсним значенням [DNS-піддомену](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names), але це може призводити до неочікуваних результатів для імен хостів Podʼів. Для найкращої сумісності ім'я повинно відповідати більш обмеженим правилам [DNS-мітки](/docs/concepts/overview/working-with-objects/names#dns-label-names). + +Deployment також потребує розділу [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Шаблон Pod {#pod-template} + +`.spec.template` та `.spec.selector` — єдині обовʼязкові поля `.spec`. + +`.spec.template` — це [шаблон Pod](/docs/concepts/workloads/pods/#pod-templates). Він має точно таку ж схему, як і {{< glossary_tooltip text="Pod" term_id="pod" >}}, за винятком того, що він вкладений і не має `apiVersion` або `kind`. + +Крім обовʼязкових полів для Pod, шаблон Pod в Deployment повинен вказати відповідні мітки та відповідну політику перезапуску. Щодо міток, переконайтеся, що вони не перекриваються з іншими контролерами. Дивіться [селектор](#selector). + +Дозволяється лише [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy), рівне `Always`, що є стандартним значенням, якщо не вказано інше. + +### Репліки {#replicas} + +`.spec.replicas` — це необовʼязкове поле, яке вказує кількість бажаних Podʼів. Стандартно встановлено значення 1. + +Якщо ви вручну масштабуєте Deployment, наприклад, через `kubectl scale deployment deployment --replicas=X`, а потім ви оновлюєте цей Deployment на основі маніфесту (наприклад: виконуючи `kubectl apply -f deployment.yaml`), то застосування цього маніфесту перезаписує ручне масштабування, яке ви раніше вказали. + +Якщо [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (або будь-який аналогічний API для горизонтального масштабування) відповідає за масштабування Deployment, не встановлюйте значення в `.spec.replicas`. + +Замість цього дозвольте панелі управління Kubernetes автоматично керувати полем `.spec.replicas`. + +### Селектор {#selector} + +`.spec.selector` — обовʼязкове поле, яке вказує [селектор міток](/docs/concepts/overview/working-with-objects/labels/) для Podʼів, які створює цей Deployment. + +`.spec.selector` повинно відповідати `.spec.template.metadata.labels`, або воно буде відхилено API. + +В API-версії `apps/v1` `.spec.selector` та `.metadata.labels` не встановлюють стандартні значення на основі `.spec.template.metadata.labels`, якщо вони не встановлені. Таким чином, їх слід встановлювати явно. Також слід зазначити, що `.spec.selector` неможливо змінити після створення Deployment в `apps/v1`. + +Deployment може примусово завершити Podʼи, мітки яких відповідають селектору, якщо їх шаблон відмінний від `.spec.template` або якщо загальна кількість таких Podʼів перевищує `.spec.replicas`. Запускає нові Podʼи з `.spec.template`, якщо кількість Podʼів менше, ніж бажана кількість. + +{{< note >}} +Вам не слід створювати інші Podʼи, мітки яких відповідають цьому селектору, або безпосередньо, створюючи інший Deployment, або створюючи інший контролер, такий як ReplicaSet або ReplicationController. Якщо ви це зробите, перший Deployment вважатиме, що він створив ці інші Podʼи. Kubernetes не забороняє вам робити це. +{{< /note >}} + +Якщо у вас є кілька контролерів із подібними селекторами, контролери будуть конфліктувати між собою і не будуть вести себе коректно. + +### Стратегія {#strategy} + +`.spec.strategy` визначає стратегію, якою замінюються старі Podʼи новими. `.spec.strategy.type` може бути "Recreate" або "RollingUpdate". Типовим значенням є "RollingUpdate". + +#### Перестворення Deployment {#recreate-deployment} + +Всі поточні Podʼи примусово зупиняються та вилучаються, перш ніж створюються нові, коли `.spec.strategy.type==Recreate`. + +{{< note >}} +Це гарантує тільки завершення роботи Podʼи до створення для оновлення. Якщо ви оновлюєте Deployment, всі Podʼи старої ревізії будуть негайно завершені. Успішне видалення очікується перед створенням будь-якого Podʼи нової ревізії. Якщо ви вручну видаляєте Pod, життєвий цикл керується ReplicaSet, і заміщення буде створено негайно (навіть якщо старий Pod все ще перебуває в стані Terminating). Якщо вам потрібна гарантія "at most" для ваших Podʼів, вам слід розглянути використання [StatefulSet](/docs/concepts/workloads/controllers/statefulset/). +{{< /note >}} + +#### Оновлення Deployment {#rolling-update-deployment} + +Deployment оновлює Podʼи в режимі поетапного оновлення, коли `.spec.strategy.type==RollingUpdate`. Ви можете вказати `maxUnavailable` та `maxSurge`, щоб контролювати процес поетапного оновлення. + +##### Максимально недоступний {#max-unavailable} + +`.spec.strategy.rollingUpdate.maxUnavailable` — це необовʼязкове поле, яке вказує максимальну кількість Podʼів, які можуть бути недоступні під час процесу оновлення. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаної кількості Podʼів (наприклад, 10%). Абсолютне число обчислюється з відсотком, округленим вниз. Значення не може бути 0, якщо `MaxSurge` дорівнює 0. Станадартне значення — 25%. + +Наприклад, якщо це значення встановлено на 30%, старий ReplicaSet може бути масштабований до 70% від бажаної кількості Podʼів негайно, коли починається поетапне оновлення. Як тільки нові Podʼи готові, старий ReplicaSet може бути ще більше масштабований вниз, а після цього може бути збільшено масштаб нового ReplicaSet, забезпечуючи, що загальна кількість Podʼів, доступних у будь-який час під час оновлення, становить принаймні 70% від бажаної кількості Podʼів. + +##### Максимальний наплив {#max-surge} + +`.spec.strategy.rollingUpdate.maxSurge` — це необовʼязкове поле, яке вказує максимальну кількість Podʼів, які можуть бути створені понад бажану кількість Podʼів. Значення може бути абсолютним числом (наприклад, 5) або відсотком від бажаної кількості Podʼів (наприклад, 10%). Абсолютне число обчислюється з відсотком, округленим вгору. Значення не може бути 0, якщо `MaxUnavailable` дорівнює 0. Станадартне значення - 25%. + +Наприклад, якщо це значення встановлено на 30%, новий ReplicaSet може бути масштабований негайно, коли починається поетапне оновлення, таким чином, щоб загальна кількість старих і нових Podʼів не перевищувала 130% від бажаної кількості Podʼів. Як тільки старі Podʼи буде вилучено, новий ReplicaSet може бути масштабований ще більше, забезпечуючи, що загальна кількість Podʼів, які працюють в будь-який час під час оновлення, становить найбільше 130% від бажаної кількості Podʼів. + +Ось кілька прикладів оновлення Deployment за допомогою `maxUnavailable` та `maxSurge`: + +{{< tabs name="tab_with_md" >}} +{{% tab name="Max Unavailable" %}} + + ```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 + strategy: + type: RollingUpdate + rollingUpdate: + maxUnavailable: 1 + ``` + +{{% /tab %}} +{{% tab name="Max Surge" %}} + + ```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 + strategy: + type: RollingUpdate + rollingUpdate: + maxSurge: 1 + ``` + +{{% /tab %}} +{{% tab name="Гібрид" %}} + + ```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 + strategy: + type: RollingUpdate + rollingUpdate: + maxSurge: 1 + maxUnavailable: 1 + ``` + +{{% /tab %}} +{{< /tabs >}} + +### Час Progress Deadline {#progress-deadline-seconds} + +`.spec.progressDeadlineSeconds` — це необовʼязкове поле, яке вказує кількість секунд, протягом яких ви хочете чекати, поки ваш Deployment продовжиться, перш ніж система повідомить, що Deployment має [помилку](#failed-deployment) — відображається як умова з `type: Progressing`, `status: "False"` та `reason: ProgressDeadlineExceeded` в статусі ресурсу. Контролер Deployment буде продовжувати +повторювати спроби Deployment. Станадартно це значення становить 600. У майбутньому, коли буде реалізовано автоматичний відкат, контролер Deployment відкотить Deployment, як тільки він виявить таку умову. + +Якщо вказано це поле, воно повинно бути більше, ніж значення `.spec.minReadySeconds`. + +### Час Min Ready {#min-ready-seconds} + +`.spec.minReadySeconds` — це необовʼязкове поле, яке вказує мінімальну кількість секунд, протягом яких новий створений Pod повинен бути готовим, і жоден з його контейнерів не повинен виходити з ладу, щоб його вважалим доступним. Стандартно це значення становить 0 (Pod буде вважатися доступним, як тільки він буде готовий). Щоб дізнатися більше про те, коли Pod вважається готовим, див. [Проби контейнерів](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). + +### Ліміт історії ревізій {#revision-history-limit} + +Історія ревізій Deployment зберігається в ReplicaSets, якими він керує. + +`.spec.revisionHistoryLimit` — це необовʼязкове поле, яке вказує кількість старих ReplicaSets, які слід зберігати для можливості відкату. Ці старі ReplicaSets витрачають ресурси в `etcd` та заважають виводу `kubectl get rs`. Конфігурація кожного ревізії Deployment зберігається в його ReplicaSets; отже, після видалення старого ReplicaSet ви втрачаєте можливість відкотитися до цієї ревізії Deployment. Стандартно буде збережено 10 старих ReplicaSets, але ідеальне значення залежить від частоти та стабільності нових Deployment. + +Зокрема, встановлення цього поля рівним нулю означає, що всі старі ReplicaSets з 0 реплік буде очищено. У цьому випадку нове розгортання Deployment не може бути скасовано, оскільки його історія ревізій очищена. + +### Пауза {#paused} + +`.spec.paused` — це необовʼязкове булеве поле для призупинення та відновлення Deployment. Єдиний відмінок між призупиненим Deployment і тим, який не призупинений, полягає в тому, що будь-які зміни в PodTemplateSpec призупиненого Deployment не викличуть нових розгортань, поки він призупинений. Deployment типово не призупинений при створенні. + +## {{% heading "whatsnext" %}} + +* Дізнайтеся більше про [Podʼи](/docs/concepts/workloads/pods). +* [Запустіть stateless застосунок за допомогою Deployment](/docs/tasks/run-application/run-stateless-application-deployment/). +* Прочитайте {{< api-reference page="workload-resources/deployment-v1" >}}, щоб зрозуміти API Deployment. +* Прочитайте про [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) та як ви можете використовувати його для управління доступністю застосунку під час розладу. +* Використовуйте kubectl для [створення Deployment](/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/). diff --git a/content/uk/docs/concepts/workloads/controllers/job.md b/content/uk/docs/concepts/workloads/controllers/job.md new file mode 100644 index 0000000000000..39bc5509b5a37 --- /dev/null +++ b/content/uk/docs/concepts/workloads/controllers/job.md @@ -0,0 +1,752 @@ +--- +reviewers: +- alculquicondor +- erictune +- soltysh +title: Jobs +content_type: concept +description: >- + Job – є одноразовим завданням, що виконується до моменту його завершення. +feature: + title: Пакетне виконання + description: > + На додачу до сервісів, Kubernetes може керувати пакетними та CI завданнями, замінюючи, якщо треба, контейнери, які зазнали збоїв. +weight: 50 +hide_summary: true # Listed separately in section index +--- + + + +Завдання (Job) створює один або кілька Podʼів і буде продовжувати повторювати виконання Podʼів, доки не буде досягнуто вказану кількість успішних завершень. При успішному завершенні Podʼів завдання відстежує ці успішні завершення. Коли досягнута вказана кількість успішних завершень, завдання (тобто Job) завершується. Видалення завдання буде видаляти Podʼи, які воно створило. При призупиненні завдання буде видаляти активні Podʼи, доки завдання знову не буде відновлене. + +У простому випадку можна створити один обʼєкт Job для надійного запуску одного Podʼа до завершення. Обʼєкт Job буде запускати новий Pod, якщо перший Pod зазнає невдачі або видаляється (наприклад, через відмову апаратного забезпечення вузла або перезавантаження вузла). + +Також можна використовувати Job для запуску кількох Podʼів паралельно. + +Якщо ви хочете запустити завдання (або одне завдання, або декілька паралельно) за розкладом, див. [CronJob](/docs/concepts/workloads/controllers/cron-jobs/). + + + +## Запуск прикладу Job {#running-an-example-job} + +Ось конфігурація прикладу Job. Тут обчислюється число π з точністю до 2000 знаків і виконується його вивід. Виконання зазвичай займає близько 10 секунд. + +{{% code_sample file="controllers/job.yaml" %}} + +Ви можете запустити цей приклад за допомогою наступної команди: + +```shell +kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml +``` + +Вивід буде схожим на це: + +``` +job.batch/pi created +``` + +Перевірте статус Job за допомогою `kubectl`: + +{{< tabs name="Check status of Job" >}} +{{< tab name="kubectl describe job pi" codelang="bash" >}} +Name: pi +Namespace: default +Selector: batch.kubernetes.io/controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c +Labels: batch.kubernetes.io/controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + batch.kubernetes.io/job-name=pi + ... +Annotations: batch.kubernetes.io/job-tracking: "" +Parallelism: 1 +Completions: 1 +Start Time: Mon, 02 Dec 2019 15:20:11 +0200 +Completed At: Mon, 02 Dec 2019 15:21:16 +0200 +Duration: 65s +Pods Statuses: 0 Running / 1 Succeeded / 0 Failed +Pod Template: + Labels: batch.kubernetes.io/controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + batch.kubernetes.io/job-name=pi + Containers: + pi: + Image: perl:5.34.0 + Port: + Host Port: + Command: + perl + -Mbignum=bpi + -wle + print bpi(2000) + Environment: + Mounts: + Volumes: +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 21s job-controller Created pod: pi-xf9p4 + Normal Completed 18s job-controller Job completed +{{< /tab >}} +{{< tab name="kubectl get job pi -o yaml" codelang="bash" >}} +apiVersion: batch/v1 +kind: Job +metadata: + annotations: batch.kubernetes.io/job-tracking: "" + ... + creationTimestamp: "2022-11-10T17:53:53Z" + generation: 1 + labels: + batch.kubernetes.io/controller-uid: 863452e6-270d-420e-9b94-53a54146c223 + batch.kubernetes.io/job-name: pi + name: pi + namespace: default + resourceVersion: "4751" + uid: 204fb678-040b-497f-9266-35ffa8716d14 +spec: + backoffLimit: 4 + completionMode: NonIndexed + completions: 1 + parallelism: 1 + selector: + matchLabels: + batch.kubernetes.io/controller-uid: 863452e6-270d-420e-9b94-53a54146c223 + suspend: false + template: + metadata: + creationTimestamp: null + labels: + batch.kubernetes.io/controller-uid: 863452e6-270d-420e-9b94-53a54146c223 + batch.kubernetes.io/job-name: pi + spec: + containers: + - command: + - perl + - -Mbignum=bpi + - -wle + - print bpi(2000) + image: perl:5.34.0 + imagePullPolicy: IfNotPresent + name: pi + resources: {} + terminationMessagePath: /dev/termination-log + terminationMessagePolicy: File + dnsPolicy: ClusterFirst + restartPolicy: Never + schedulerName: default-scheduler + securityContext: {} + terminationGracePeriodSeconds: 30 +status: + active: 1 + ready: 0 + startTime: "2022-11-10T17:53:57Z" + uncountedTerminatedPods: {} +{{< /tab >}} +{{< /tabs >}} + +Щоб переглянути завершені Podʼи Job, використовуйте `kubectl get pods`. + +Щоб вивести всі Podʼи, які належать Job у машинночитаній формі, ви можете використовувати таку команду: + +```shell +pods=$(kubectl get pods --selector=batch.kubernetes.io/job-name=pi --output=jsonpath='{.items[*].metadata.name}') +echo $pods +``` + +Вивід буде схожим на це: + +```none +pi-5rwd7 +``` + +Тут, селектор збігається з селектором, який використовується в Job. Параметр `--output=jsonpath` зазначає вираз з назвою з кожного Pod зі списку. + +```shell +kubectl logs $pods +``` + +Іншим варіантом є використання `kubectl logs` для виводу логів з кожного Pod. + +```shell +kubectl logs job/pi +``` + +Вивід буде схожим на це: + +```none +3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 +``` + +### Створення опису Job {#writing-a-job-spec} + +Як і з будь-якою іншою конфігурацією Kubernetes, у Job мають бути вказані поля `apiVersion`, `kind` та `metadata`. + +При створенні панеллю управління нових Podʼів для Job, поле `.metadata.name` Job є частиною основи для надання імен цим Podʼам. Імʼя Job повинно бути дійсним значенням [DNS-піддомену](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names), але це може призводити до неочікуваних результатів для імен хостів Podʼів. Для найкращої сумісності імʼя повинно відповідати більш обмеженим правилам для [DNS-мітки](/docs/concepts/overview/working-with-objects/names#dns-label-names). Навіть якщо імʼя є DNS-піддоменом, імʼя повинно бути не довше 63 символів. + +Також у Job повинен бути розділ [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Мітки для Job {#job-labels} + +Мітки Job повинні мати префікс `batch.kubernetes.io/` для `job-name` та `controller-uid`. + +### Шаблон Podʼа {#pod-template} + +`.spec.template` — єдине обовʼязкове поле `.spec`. + +`.spec.template` — це [шаблон Podʼа](/docs/concepts/workloads/pods/#pod-templates). Він має точно таку ж схему, як {{< glossary_tooltip text="Pod" term_id="pod" >}}, окрім того, що він вкладений і не має `apiVersion` чи `kind`. + +Окрім обовʼязкових полів для Podʼа , шаблон Podʼа в Job повинен вказати відповідні мітки (див. [вибір Podʼа](#pod-selector)) та відповідну політику перезапуску. + +Дозволяється лише [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy), рівний `Never` або `OnFailure`. + +### Селектор Podʼа {#pod-selector} + +Поле `.spec.selector` є необовʼязковим. У майже всіх випадках ви не повинні його вказувати. Дивіться розділ [вказування вашого власного селектора Podʼа](#specifying-your-own-pod-selector). + +### Паралельне виконання для Jobs {#parallel-jobs} + +Існують три основних типи завдань, які підходять для виконання в якості Job: + +1. Непаралельні Jobs + - зазвичай запускається лише один Pod, якщо Pod не вдається. + - Job завершується, як тільки його Pod завершується успішно. + +1. Паралельні Jobs із *фіксованою кількістю завершень* + - вкажіть ненульове позитивне значення для `.spec.completions`. + - Job являє собою загальне завдання і завершується, коли є `.spec.completions` успішних Podʼів. + - при використанні `.spec.completionMode="Indexed"`, кожен Pod отримує різний індекс у діапазоні від 0 до `.spec.completions-1`. + +1. Паралельні Jobs із *чергою завдань* + - не вказуйте `.spec.completions`, типово встановлюється `.spec.parallelism`. + - Podʼи повинні координувати серед себе або зовнішній сервіс для визначення над чим кожен з них має працювати. Наприклад, Pod може отримати набір з N елементів з черги завдань. + - кожен Pod може незалежно визначити, чи завершилися всі його партнери, і, таким чином, що весь Job завершений. + - коли *будь-який* Pod з Job завершується успішно, нові Podʼи не створюються. + - як тільки хоча б один Pod завершився успішно і всі Podʼи завершені, тоді Job завершується успішно. + - як тільки будь-який Pod завершився успішно, жоден інший Pod не повинен виконувати роботу для цього завдання чи записувати будь-який вивід. Вони всі мають бути в процесі завершення. + +Для *непаралельного* Job ви можете залишити як `.spec.completions`, так і `.spec.parallelism` не встановленими. Коли обидва не встановлені, обидва типово встановлюються на 1. + +Для *Job із фіксованою кількістю завершень* вам слід встановити `.spec.completions` на кількість необхідних завершень. Ви можете встановити `.spec.parallelism` чи залишити його не встановленим, і він буде встановлено типово на 1. + +Для *Job із чергою завдань* ви повинні залишити `.spec.completions` не встановленим і встановити `.spec.parallelism` на не відʼємне ціле число. + +За докладною інформацією про використання різних типів Job, див. розділ [шаблони Job](#job-templates). + +#### Контроль паралелізму {#controlling-parallelism} + +Запитаний паралелізм (`.spec.parallelism`) може бути встановлений на будь-яке не відʼємне значення. Якщо значення не вказано, стандартно воно дорівнює 1. Якщо вказано як 0, то Job ефективно призупинено до тих пір, поки воно не буде збільшене. + +Фактична паралельність (кількість Podʼів, які працюють в будь-який момент) може бути більше чи менше, ніж запитаний паралелізм, з різних причин: + +- Для *Job із фіксованою кількістю завершень*, фактична кількість Podʼів, які працюють паралельно, не буде перевищувати кількість залишених завершень. Значення `.spec.parallelism` більше чи менше ігнорується. +- Для *Job із чергою завдань*, жоден новий Pod не запускається після успішного завершення будь-якого Podʼа — залишені Podʼи мають право завершити роботу. +- Якщо у {{< glossary_tooltip term_id="controller" text="контролера" >}} Job не було часу відреагувати. +- Якщо контролер Job не зміг створити Podʼи з будь-якої причини (нестача `ResourceQuota`, відсутність дозволу і т.д.), тоді може бути менше Podʼів, ніж запитано. +- Контролер Job може обмежувати створення нових Podʼів через ексцесивні попередні відмови Podʼів у цьому ж Job. +- Коли Pod завершується відповідним чином, на його зупинку потрібен час. + +### Режим завершення {#completion-mode} + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Для завдань з *фіксованою кількістю завершень* — тобто завдань, які мають не нульове `.spec.completions` — може бути встановлено режим завершення, який вказується в `.spec.completionMode`: + +- `NonIndexed` (стандартно): завдання вважається завершеним, коли є `.spec.completions` успішно завершених Podʼів. Іншими словами, завершення кожного Podʼа гомологічне одне одному. Зверніть увагу, що завдання, у яких `.spec.completions` дорівнює null, неявно є `NonIndexed`. +- `Indexed`: Podʼи завдання отримують асоційований індекс завершення від 0 до `.spec.completions-1`. Індекс доступний через чотири механізми: + - Анотація Podʼа `batch.kubernetes.io/job-completion-index`. + - Мітка Podʼа `batch.kubernetes.io/job-completion-index` (для v1.28 і новіших). Зверніть увагу, що для використання цієї мітки механізм feature gate `PodIndexLabel` повинен бути увімкнений, і він є типово увімкненим. + - Як частина імені хоста Podʼа, за шаблоном `$(job-name)-$(index)`. Коли ви використовуєте індексоване завдання у поєднанні з {{< glossary_tooltip term_id="Service" >}}, Podʼи всередині завдання можуть використовувати детерміністичні імена хостів для адресації одне одного через DNS. Докладні відомості щодо того, як налаштувати це, див. [Завдання з комунікацією від Podʼа до Podʼа](/docs/tasks/job/job-with-pod-to-pod-communication/). + - З контейнера завдання, в змінній середовища `JOB_COMPLETION_INDEX`. + + Завдання вважається завершеним, коли є успішно завершений Pod для кожного індексу. Докладні відомості щодо того, як використовувати цей режим, див. [Індексоване завдання для паралельної обробки зі статичним призначенням роботи](/docs/tasks/job/indexed-parallel-processing-static/). + +{{< note >}} +Хоча це і рідко, може бути запущено більше одного Podʼа для одного і того ж індексу (з різних причин, таких як відмови вузла, перезапуски kubelet чи витіснення Podʼа). У цьому випадку лише перший успішно завершений Pod буде враховуватися при підрахунку кількості завершень та оновленні статусу завдання. Інші Podʼи, які працюють чи завершили роботу для того ж самого індексу, будуть видалені контролером завдання, як тільки він їх виявлять. +{{< /note >}} + +## Обробка відмов Podʼа та контейнера {#handling-pod-and-container-failures} + +Контейнер у Podʼі може вийти з ладу з ряду причин, таких як завершення процесу з ненульовим кодом виходу або примусове припинення роботи контейнера через перевищення ліміту памʼяті та таке інше. Якщо це стається і `.spec.template.spec.restartPolicy = "OnFailure"`, тоді Pod залишається на вузлі, але контейнер перезапускається. Отже, ваш застосунок повинен обробляти випадок, коли він +перезапускається локально, або вказувати `.spec.template.spec.restartPolicy = "Never"`. Докладні відомості про `restartPolicy` див. в розділі [життєвий цикл Podʼа](/docs/concepts/workloads/pods/pod-lifecycle/#example-states). + +Весь Pod також може вийти з ладу з ряду причин, таких як коли Pod видаляється з вузла (вузол оновлюється, перезавантажується, видаляється тощо), або якщо контейнер Podʼа виходить з ладу і `.spec.template.spec.restartPolicy = "Never"`. Коли Pod виходить з ладу, контролер завдання запускає новий Pod. Це означає, що ваш застосунок повинен обробляти випадок, коли він перезапускається у новому +Podʼі. Зокрема, він повинен обробляти тимчасові файли, блокування, неповний вивід та інше, викликане попередніми запусками. + +Типово кожна відмова Podʼа враховується в ліміті `.spec.backoffLimit`, див. [політика відмови Podʼа](#pod-backoff-failure-policy). Однак ви можете налаштовувати обробку відмов Podʼа, встановлюючи [політику відмови Podʼа] (#pod-failure-policy) для завдання. + +Додатково ви можете вирішити враховувати відмови Podʼа незалежно для кожного індексу в [Індексованому](#completion-mode) завданні, встановлюючи поле `.spec.backoffLimitPerIndex` (докладні відомості див. [ліміт затримки на індекс](#backoff-limit-per-index)). + +Зверніть увагу, що навіть якщо ви вказали `.spec.parallelism = 1` і `.spec.completions = 1` і `.spec.template.spec.restartPolicy = "Never"`, той самий програмний код може іноді бути запущений двічі. + +Якщо ви вказали як `.spec.parallelism`, так і `.spec.completions` більше ніж 1, то може бути запущено кілька Podʼів одночасно. Таким чином, ваші Podʼи також повинні бути стійкими до конкурентності. + +Коли вмикаються [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) `PodDisruptionConditions` та `JobPodFailurePolicy`, і поле `.spec.podFailurePolicy` встановлено, контролер завдання не вважає завершення +Podʼа (Pod, який має встановлене поле `.metadata.deletionTimestamp`) за відмову, поки цей Pod не є термінальним (його `.status.phase` — `Failed` або `Succeeded`). Однак контролер завдання створює новий Pod, як тільки стає очевидним завершення. Якщо Pod завершується, контролер завдання оцінює `.backoffLimit` та `.podFailurePolicy` для відповідного завдання, враховуючи цей тепер вже завершений Pod. + +Якщо хоча б одна з цих вимог не виконана, контролер завдання рахує завершення Podʼа негайною відмовою, навіть якщо цей Pod пізніше завершить фазою `"Succeeded"`. + +### Політика відмови затримки Podʼа {#pod-backoff-failure-policy} + +Є ситуації, коли ви хочете відмовити завдання після певної кількості спроб +через логічну помилку в конфігурації тощо. Для цього встановіть `.spec.backoffLimit`, щоб вказати кількість спроб перед тим, як вважати завданням невдалим. Ліміт затримки стандартно встановлено на рівні 6. Помилкові Podʼи, повʼязані з завданням, відновлюються контролером завдань з експоненційною затримкою (10 с, 20 с, 40 с …) з верхнім обмеженням у шість хвилин. + +Кількість спроб обчислюється двома способами: + +- Кількість Podʼів з `.status.phase = "Failed"`. +- При використанні `restartPolicy = "OnFailure"` кількість спроб у всіх контейнерах Podʼів з `.status.phase`, що дорівнює `Pending` або `Running`. + +Якщо хоча б один із розрахунків досягне значення `.spec.backoffLimit`, завдання вважається невдалим. + +{{< note >}} +Якщо ваше завдання має `restartPolicy = "OnFailure"`, майте на увазі, що Pod, який виконує завдання, буде припинений, як тільки ліміт затримки завдання буде досягнуто. Це може ускладнити налагодження виконуваного завдання. Ми радимо встановлювати `restartPolicy = "Never"` під час налагодження завдання або використовувати систему логування, щоб забезпечити, що вивід з невдалого завдання не буде втрачено випадково. +{{< /note >}} + +### Ліміт затримки для кожного індексу {#backoff-limit-per-index} + +{{< feature-state for_k8s_version="v1.29" state="beta" >}} + +{{< note >}} +Ви можете налаштувати ліміт затримки для кожного індексу для завдання з [індексацією](#completion-mode), якщо у вас увімкнено [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `JobBackoffLimitPerIndex` в вашому кластері. +{{< /note >}} + +Коли ви запускаєте [індексоване](#completion-mode) завдання, ви можете вибрати обробку спроб для відмов Podʼа незалежно для кожного індексу. Для цього встановіть +`.spec.backoffLimitPerIndex`, щоб вказати максимальну кількість невдалих спроб Podʼа +для кожного індексу. + +Коли ліміт затримки для кожного індексу перевищується для певного індексу, Kubernetes вважає цей індекс невдалим і додає його до поля `.status.failedIndexes`. Індекси, які виконались успішно, реєструються в полі `.status.completedIndexes`, незалежно від того, чи ви встановили поле `backoffLimitPerIndex`. + +Зауважте, що невдалий індекс не перериває виконання інших індексів. Щойно всі індекси завершаться для завдання, в якому ви вказали ліміт затримки для кожного індексу, якщо хоча б один з цих індексів виявився невдалим, контролер завдань позначає загальне завдання як невдале, встановлюючи умову `Failed` в статусі. Завдання отримує позначку "невдало", навіть якщо деякі, можливо, усі індекси були +оброблені успішно. + +Ви також можете обмежити максимальну кількість позначених невдалих індексів, встановивши поле `.spec.maxFailedIndexes`. Коли кількість невдалих індексів перевищує значення поля `maxFailedIndexes`, контролер завдань запускає завершення всіх залишаються запущеними Podʼами для цього завдання. Щойно всі Podʼи будуть завершені, контролер завдань позначає всю роботу як невдалу, встановлюючи умову `Failed` в статусі завдання. + +Ось приклад маніфесту для завдання, яке визначає `backoffLimitPerIndex`: + +{{< code_sample file="/controllers/job-backoff-limit-per-index-example.yaml" >}} + +У вищенаведеному прикладі контролер завдань дозволяє один перезапуск для кожного з індексів. Коли загальна кількість невдалих індексів перевищує 5, тоді все завдання припиняються. + +Після завершення роботи стан завдання виглядає наступним чином: + +```sh +kubectl get -o yaml job job-backoff-limit-per-index-example +``` + +```yaml + status: + completedIndexes: 1,3,5,7,9 + failedIndexes: 0,2,4,6,8 + succeeded: 5 # 1 succeeded pod for each of 5 succeeded indexes + failed: 10 # 2 failed pods (1 retry) for each of 5 failed indexes + conditions: + - message: Job has failed indexes + reason: FailedIndexes + status: "True" + type: Failed +``` + +Додатково ви можете використовувати ліміт затримки для кожного індексу разом з +[політикою збоїв Podʼа](#pod-failure-policy). Коли використовується ліміт затримки для кожного індексу, доступний новій дії `FailIndex`, який дозволяє вам уникати непотрібних повторів всередині індексу. + +### Політика збою Podʼа {#pod-failure-policy} + +{{< feature-state for_k8s_version="v1.26" state="beta" >}} + +{{< note >}} +Ви можете налаштувати політику збою Podʼа для завдання лише тоді, коли [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `JobPodFailurePolicy` увімкнено у вашому кластері. Крім того, рекомендується увімкнути feature gate `PodDisruptionConditions`, щоб мати можливість виявляти та обробляти умови розладу Podʼа в політиці збою Podʼа (див. також: [умови розладу Podʼа](/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions)). Обидва feature gate доступні в Kubernetes {{< skew currentVersion >}}. +{{< /note >}} + +Політика збою Podʼа, визначена за допомогою поля `.spec.podFailurePolicy`, дозволяє вашому кластеру обробляти відмови Podʼа на основі кодів виходу контейнера та умов Podʼа. + +У деяких ситуаціях вам може знадобитися кращий контроль обробки відмов Podʼа, ніж контроль, який надає [політика збою Podʼа за допомогою затримки збою Podʼа](#pod-backoff-failure-policy), яка базується на `.spec.backoffLimit` завдання. Ось деякі приклади використання: + +- Для оптимізації витрат на виконання завдань, уникнення непотрібних перезапусків Podʼа, ви можете завершити завдання, як тільки один із його Podʼів відмовить із кодом виходу, що вказує на помилку програмного забезпечення. +- Щоб гарантувати, що ваше завдання завершиться, навіть якщо є розлади, ви можете ігнорувати відмови Podʼа, спричинені розладами (такими як {{< glossary_tooltip text="витіснення" term_id="preemption" >}}, {{< glossary_tooltip text="ініційоване API вивільнення ресурсів" term_id="api-eviction" >}} або вивільнення на підставі {{< glossary_tooltip text="маркування" term_id="taint" >}}), щоб вони не враховувалися при досягненні `.spec.backoffLimit` ліміту спроб. + +Ви можете налаштувати політику збою Podʼа в полі `.spec.podFailurePolicy`, щоб відповідати вищенаведеним використанням. Ця політика може обробляти відмови Podʼа на основі кодів виходу контейнера та умов Podʼа. + +Ось маніфест для завдання, яке визначає `podFailurePolicy`: + +{{% code_sample file="/controllers/job-pod-failure-policy-example.yaml" %}} + +У вищенаведеному прикладі перше правило політики збою Podʼа вказує, що завдання слід позначити як невдале, якщо контейнер `main` завершиться кодом виходу 42. Наступні правила стосуються саме контейнера `main`: + +- код виходу 0 означає, що контейнер виконався успішно +- код виходу 42 означає, що **все завдання** виконалося невдало +- будь-який інший код виходу вказує, що контейнер виконався невдало, і, отже, весь Pod буде створений заново, якщо загальна кількість перезапусків менше `backoffLimit`. Якщо `backoffLimit` досягнуте, **все завдання** виконалося невдало. + +{{< note >}} +Оскільки в шаблоні Podʼа вказано `restartPolicy: Never`, kubelet не перезапускає контейнер `main` в тому конкретному Podʼі. +{{< /note >}} + +Друге правило політики збою Podʼа, що вказує дію `Ignore` для невдалих Podʼів з умовою `DisruptionTarget`, виключає Podʼи, які взяли участь в розладах, з хунок ліміту спроб `.spec.backoffLimit`. + +{{< note >}} +Якщо завдання виявилося невдалим, будь-то через політику збою Podʼа, чи через політику затримки збою Podʼа, і завдання виконується декількома Podʼами, Kubernetes завершує всі +Podʼи в цьому завданні, які все ще перебувають у статусах Pending або Running. +{{< /note >}} + +Ось деякі вимоги та семантика API: + +- якщо ви хочете використовувати поле `.spec.podFailurePolicy` для завдання Job, вам також слід визначити шаблон Podʼа цього завдання з `.spec.restartPolicy`, встановленим на `Never`. +- правила політики збою Podʼа, які ви визначаєте у `spec.podFailurePolicy.rules`, оцінюються послідовно. Якщо одне з правил відповідає збою Podʼа, інші правила ігноруються. Якщо жодне правило не відповідає збою Podʼа, застосовується типова обробка. +- ви можете бажати обмежити правило певним контейнером, вказавши його ім'я у `spec.podFailurePolicy.rules[*].onExitCodes.containerName`. Якщо не вказано, правило застосовується до всіх контейнерів. Якщо вказано, воно повинно відповідати імені одного з контейнерів або `initContainer` у шаблоні Podʼа. +- ви можете вказати дію, вживану при відповідності політиці збою Podʼа, у `spec.podFailurePolicy.rules[*].action`. Можливі значення: + - `FailJob`: використовуйте це, щоб вказати, що завдання Podʼа має бути позначено як Failed та всі запущені Podʼи повинні бути завершені. + - `Ignore`: використовуйте це, щоб вказати, що лічильник до `.spec.backoffLimit` не повинен збільшуватися, і повинен бути створений замінюючий Pod. + - `Count`: використовуйте це, щоб вказати, що Pod повинен бути оброблений типовим способом. Лічильник до `.spec.backoffLimit` повинен збільшитися. + - `FailIndex`: використовуйте цю дію разом із [лімітом затримки на кожен індекс](#backoff-limit-per-index) для уникнення непотрібних повторних спроб в межах індексу невдалого Podʼа. + +{{< note >}} +Коли використовується `podFailurePolicy`, контролер завдань враховує лише Podʼи у фазі `Failed`. Podʼи з відміткою про видалення, які не знаходяться в термінальній фазі (`Failed` чи `Succeeded`), вважаються таким що примусово припиняють свою роботу. Це означає, що такі Podʼи зберігають [завершувачі відстеження](#job-tracking-with-finalizers) доки не досягнуть термінальної фази. З Kubernetes 1.27 Kubelet переводить видалені Podʼи в термінальну фазу (див.: [Фаза Podʼа](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)). Це забезпечує видалення завершувачів контролером Job. +{{< /note >}} + +{{< note >}} +Починаючи з Kubernetes v1.28, коли використовується політика збою Podʼа, контролер Job відтворює Podʼи, що припиняються примусово, лише тоді, коли ці Podʼи досягли термінальної фази `Failed`. Це подібно до політики заміщення Podʼа: `podReplacementPolicy: Failed`. Для отримання додаткової інформації див. [Політика заміщення Podʼа](#pod-replacement-policy). +{{< /note >}} + +## Завершення завдання та очищення {#job-termination-and-cleanup} + +Коли завдання завершується, Podʼи більше не створюються, але Podʼи [зазвичай](#pod-backoff-failure-policy) також не видаляються. Тримання їх допомагає переглядати логи завершених Podʼів для перевірки наявності помилок, попереджень чи іншого діагностичного виводу. Обʼєкт завдання також залишається після завершення, щоб ви могли переглядати його статус. Користувачу слід видаляти старі завдання після перегляду їх статусу. Видаліть завдання за допомогою `kubectl` (наприклад, `kubectl delete jobs/pi` або `kubectl delete -f ./job.yaml`). Коли ви видаляєте завдання за допомогою `kubectl`, всі його створені Podʼи також видаляються. + +Стандартно завдання буде виконуватися без перерви, поки Pod не вийде з ладу (`restartPolicy=Never`) або контейнер не вийде з ладу з помилкою (`restartPolicy=OnFailure`), після чого завдання дотримується `.spec.backoffLimit`, описаного вище. Як тільки досягнуто `.spec.backoffLimit`, завдання буде позначене як невдале, і будь-які запущені Podʼи будуть завершені. + +Іншим способом завершити завдання є встановлення граничного терміну виконання. Це робиться шляхом встановлення поля `.spec.activeDeadlineSeconds` завдання кількості секунд. `activeDeadlineSeconds` застосовується до тривалості завдання, незалежно від кількості створених Podʼів. Як тільки Job досягає `activeDeadlineSeconds`, всі його запущені Podʼи завершуються, і статус завдання стане `type: Failed` з `reason: DeadlineExceeded`. + +Зауважте, що `.spec.activeDeadlineSeconds` Job має пріоритет перед його `.spec.backoffLimit`. Отже, завдання, яке повторює один або кілька невдал х Podʼів, не розпочне розгортання додаткових Podʼів, якщо `activeDeadlineSeconds` вже досягнуто, навіть якщо `backoffLimit` не досягнуто. Приклад: + +```yaml +apiVersion: batch/v1 kind: Job +metadata: + name: pi-with-timeout +Стандартноimit: 5 + activeDeadlineSeconds: 100 + template: + spec: + containers: + - name: pi + image: perl:5.34.0 + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Зверніть увагу, що як саме специфікація Job, так і [специфікація шаблону Pod](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) у межах завдання мають поле `activeDeadlineSeconds`. Переконайтеся, що ви встановлюєте це поле на відповідному рівні. + +Памʼятайте, що `restartPolicy` застосовується до Podʼа, а не до самого завдання: автоматичного перезапуску завдання не відбудеться, якщо статус завдання `type: Failed`. Іншими словами, механізми завершення завдання, активовані за допомогою `.spec.activeDeadlineSeconds` і `.spec.backoffLimit`, призводять до постійної невдачі завдання, що вимагає ручного втручання для вирішення. + +## Автоматичне очищення завершених завдань {#clean-up-finished-jobs-automatically} + +Зазвичай завершені завданя вже не потрібні в системі. Зберігання їх в системі може створювати тиск на сервер API. Якщо завдання керується безпосередньо контролером вищого рівня, таким як [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), завдання можна очищати за допомогою CronJobs на основі визначеної політики очищення з урахуванням місткості. + +### Механізм TTL для завершених завдань {#ttl-mechanism-for-finished-jobs} + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +Ще один спосіб автоматично очищати завершені завдання (якщо вони `Complete` або `Failed`) — це використовувати механізм TTL, наданий +[контролером TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) для завершених ресурсів, вказуючи поле `.spec.ttlSecondsAfterFinished` у Job. + +Коли контролер TTL очищує Job, він каскадно видаляє Job, тобто видаляє його залежні обʼєкти, такі як Podʼи, разом з Job. Зверніть увагу що при видаленні Job будуть дотримані гарантії його життєвого циклу, такі як завершувачі. + +Наприклад: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-ttl +spec: + ttlSecondsAfterFinished: 100 + template: + spec: + containers: + - name: pi + image: perl:5.34.0 + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Job `pi-with-ttl` буде призначено для автоматичного видалення через `100` секунд після завершення. + +Якщо поле встановлено в `0`, Job буде призначено для автоматичного видалення негайно після завершення. Якщо поле не вказане, це Job не буде очищено контролером TTL після завершення. + +{{< note >}} +Рекомендується встановлювати поле `ttlSecondsAfterFinished`, оскільки завдання без нагляду (завдання, які ви створили безпосередньо, а не опосередковано через інші API робочого навантаження такі як CronJob) мають станадартну політику видалення `orphanDependents`, що призводить до того, що Podʼи, створені некерованим Job, залишаються після того, як Job повністю видалено. Навіть якщо {{< glossary_tooltip text="панель управління" term_id="control-plane" >}} в кінцевому рахунку [збирає сміття](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) Podʼів з видаленого Job після того, як вони або не вдались, або завершились, іноді ці залишки Podʼів можуть призводити до погіршання продуктивності кластера або в найгіршому випадку можуть спричинити відключення кластера через це погіршення. + +Ви можете використовувати [LimitRanges](/docs/concepts/policy/limit-range/) та [ResourceQuotas](/docs/concepts/policy/resource-quotas/) щоб обмежити кількість ресурсів, які певний простір імен може споживати. +{{< /note >}} + +## Патерни використання завдань (Job) {#job-patterns} + +Обʼєкт завдання (Job) може використовуватися для обробки набору незалежних, але повʼязаних *робочих одиниць*. Це можуть бути електронні листи для надсилання, кадри для відтворення, файли для транскодування, діапазони ключів у базі даних NoSQL для сканування і так далі. + +У складній системі може бути кілька різних наборів робочих одиниць. Тут ми розглядаємо лише один набір робочих одиниць, якими користувач хоче управляти разом — *пакетне завдання*. + +Існує кілька різних патернів для паралельних обчислень, кожен з власними перевагами та недоліками. Компроміси: + +- Один обʼєкт Job для кожної робочої одиниці або один обʼєкт Job для всіх робочих одиниць. Один Job на кожну робочу одиницю створює деяку накладну роботу для користувача та системи при управлінні великою кількістю об'єктів Job. Один Job для всіх робочих одиниць підходить краще для великої кількості одиниць. +- Кількість створених Podʼів дорівнює кількості робочих одиниць або кожен Pod може обробляти кілька робочих одиниць. Коли кількість Podʼів дорівнює кількості робочих одиниць, Podʼи зазвичай вимагають менше змін у наявному коді та контейнерах. Кожен Pod, що обробляє кілька робочих одиниць, підходить краще для великої кількості одиниць. +- Декілька підходів використовують робочу чергу. Це вимагає запуску служби черги та модифікацій існуючої програми чи контейнера, щоб зробити його сумісним із чергою роботи. Інші підходи легше адаптувати до наявного контейнеризованого застосунку. +- Коли Job повʼязаний із [headless Service](/docs/concepts/services-networking/service/#headless-services), ви можете дозволити Podʼам у межах Job спілкуватися один з одним для спільної обчислень. + +Переваги та недоліки узагальнено у таблиці нижче, де стовпці з 2 по 4 відповідають зазначеним вище питанням. Імена патернів також є посиланнями на приклади та більш детальний опис. + +| Патерн | Один обʼєкт Job | Кількість Pods менше за робочі одиниці? | Використовувати застосунок без модифікацій? | +| ----------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:| +| [Черга з Pod на одиницю роботи] | ✓ | | іноді | +| [Черга змінної кількості Pod] | ✓ | ✓ | | +| [Індексована робота із статичним призначенням роботи] | ✓ | | ✓ | +| [Робота із спілкуванням від Pod до Pod] | ✓ | іноді | іноді | +| [Розширення шаблону роботи] | | | ✓ | + +Коли ви вказуєте завершення з `.spec.completions`, кожний Pod, створений контролером Job, має ідентичний [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). Це означає, що всі Podʼи для завдання матимуть однакову командну строку та один і той же шаблон, та (майже) ті ж самі змінні середовища. Ці патерни — це різні способи організації Podʼів для роботи над різними завданнями. + +Ця таблиця показує обовʼязкові налаштування для `.spec.parallelism` та `.spec.completions` для кожного з патернів. Тут `W` — це кількість робочих одиниць. + +| Патерн | `.spec.completions` | `.spec.parallelism` | +| ----------------------------------------------- |:-------------------:|:--------------------:| +| [Черга з Pod на одиницю роботи] | W | будь-яка | +| [Черга змінної кількості Pod] | null | будь-яка | +| [Індексована робота із статичним призначенням роботи] | W | будь-яка | +| [Робота із спілкуванням від Pod до Pod] | W | W | +| [Розширення шаблону роботи] | 1 | повинно бути 1 | + +[Черга з Pod на одиницю роботи]: /docs/tasks/job/coarse-parallel-processing-work-queue/ +[Черга змінної кількості Pod]: /docs/tasks/job/fine-parallel-processing-work-queue/ +[Індексована робота із статичним призначенням роботи]: /docs/tasks/job/indexed-parallel-processing-static/ +[Робота із спілкуванням від Pod до Pod]: /docs/tasks/job/job-with-pod-to-pod-communication/ +[Розширення шаблону роботи]: /docs/tasks/job/parallel-processing-expansion/ + +## Розширене використання завдань (Job) {#advanced-usage} + +### Відкладення завдання {#suspending-a-job} + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Коли створюється Job, контролер Job негайно починає створювати Podʼи, щоб відповісти вимогам Job і продовжує це робити, доки Job не завершиться. Однак іноді ви можете хотіти тимчасово призупинити виконання Job та відновити його пізніше, або створити Jobs у призупиненому стані та мати власний контролер, який вирішить, коли їх запустити. + +Щоб призупинити Job, ви можете оновити поле `.spec.suspend` Job на значення true; пізніше, коли ви захочете відновити його, оновіть його на значення false. Створення Job з `.spec.suspend` встановленим в true створить його в призупиненому стані. + +При відновленні Job з призупинення йому буде встановлено час початку `.status.startTime` в поточний час. Це означає, що таймер `.spec.activeDeadlineSeconds` буде зупинений і перезапущений, коли Job буде призупинено та відновлено. + +Коли ви призупиняєте Job, будь-які запущені Podʼи, які не мають статусу `Completed`, будуть [завершені](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) з сигналом SIGTERM. Буде дотримано період відповідного завершення ваших Podʼів, і вашим Podʼам слід обробити цей сигнал протягом цього періоду. Це може включати в себе збереження прогресу для майбутнього або скасування змін. Podʼи, завершені цим чином, не враховуватимуться при підрахунку `completions` Job. + +Приклад визначення Job в призупиненому стані може виглядати так: + +```shell +kubectl get job myjob -o yaml +``` + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: myjob +spec: + suspend: true + parallelism: 1 + completions: 5 + template: + spec: + ... +``` + +Ви також можете перемикати призупинення Job, використовуючи командний рядок. + +Призупиніть активний Job: + +```shell +kubectl patch job/myjob --type=strategic --patch '{"spec":{"suspend":true}}' +``` + +Відновіть призупинений Job: + +```shell +kubectl patch job/myjob --type=strategic --patch '{"spec":{"suspend":false}}' +``` + +Статус Job може бути використаний для визначення того, чи Job призупинено чи його було зупинено раніше: + +```shell +kubectl get jobs/myjob -o yaml +``` + +```yaml +apiVersion: batch/v1 +kind: Job +# .metadata and .spec пропущено +status: + conditions: + - lastProbeTime: "2021-02-05T13:14:33Z" + lastTransitionTime: "2021-02-05T13:14:33Z" + status: "True" + type: Suspended + startTime: "2021-02-05T13:13:48Z" +``` + +Умова Job типу "Suspended" зі статусом "True" означає, що Job призупинено; поле `lastTransitionTime` може бути використане для визначення того, як довго Job було призупинено. Якщо статус цієї умови є "False", то Job було раніше призупинено і зараз працює. Якщо такої умови не існує в статусі Job, то Job ніколи не був зупинений. + +Також створюються події, коли Job призупинено та відновлено: + +```shell +kubectl describe jobs/myjob +``` + +```none +Name: myjob +... +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 12m job-controller Created pod: myjob-hlrpl + Normal SuccessfulDelete 11m job-controller Deleted pod: myjob-hlrpl + Normal Suspended 11m job-controller Job suspended + Normal SuccessfulCreate 3s job-controller Created pod: myjob-jvb44 + Normal Resumed 3s job-controller Job resumed +``` + +Останні чотири події, зокрема події "Suspended" та "Resumed", є прямим наслідком перемикання поля `.spec.suspend`. Протягом цього часу ми бачимо, що жоден Pods не був створений, але створення Pod розпочалося знову, як тільки Job було відновлено. + +### Змінні директиви планування {#mutable-scheduling-directives} + +{{< feature-state for_k8s_version="v1.27" state="stable" >}} + +У більшості випадків, паралелльні завдання вимагатимуть щоб їхні Podʼи запускались з певними обмеженнями, типу "всі в одній зоні" або "всі на GPU моделі x або y", але не комбінація обох. + +[Поле призупинення](#suspending-a-job) є першим кроком для досягнення цих семантик. Поле призупинення дозволяє власному контролеру черги вирішити, коли повинна початися задача; Однак після того, як задача розпризупинена, власний контролер черги не впливає на те, де насправді буде розташований Pod задачі. + +Ця функція дозволяє оновлювати директиви планування Job до запуску, що дає власному контролеру черги змогу впливати на розташування Podʼів, а в той же час здійснювати власне призначення Podʼів вузлам в kube-scheduler. Це дозволяється тільки для призупинених задач, які ніколи не були розпризупинені раніше. + +Поля в шаблоні Podʼа задачі, які можна оновити, це приналежність до вузла, селектор вузла, толерантності, мітки, анотації та [вікно планування](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/). + +### Вказання власного селектора Podʼа {#specifying-your-own-pod-selector} + +Зазвичай, коли ви створюєте обʼєкт задачі (Job), ви не вказуєте `.spec.selector`. Логіка системного визначення типових значень додає це поле під час створення задачі. Вона обирає значення селектора, яке не буде перекриватися з будь-якою іншою задачею. + +Однак у деяких випадках вам може знадобитися перевизначити цей автоматично встановлений селектор. Для цього ви можете вказати `.spec.selector` задачі. + +Будьте дуже уважні при цьому. Якщо ви вказуєте селектор міток, який не є унікальним для Podʼів цієї задачі, і який відповідає неповʼязаним Podʼам, то Podʼи з неповʼязаною задачею можуть бути видалені, або ця задача може вважати інші Podʼи завершеними, або одна чи обидві задачі можуть відмовитися від створення Podʼів або завершити роботу. Якщо вибираєте ненадійний селектор, то інші контролери (наприклад, ReplicationController) та їхні Podʼи можуть проявляти непередбачувану поведінку також. Kubernetes не зупинить вас від того, що ви можете зробити помилку при зазначені `.spec.selector`. + +Ось приклад ситуації, коли вам може знадобитися використовувати цю функцію. + +Скажімо, задача `old` вже запущена. Ви хочете, щоб існуючі Podʼи продовжували працювати, але ви хочете, щоб решта Podʼів, які вона створює, використовували інший шаблон Pod і щоб у задачі було нове імʼя. Ви не можете оновити задачу, оскільки ці поля не можна оновлювати. Отже, ви видаляєте задачу `old`, але *залишаєте її Podʼи запущеними*, використовуючи `kubectl delete jobs/old --cascade=orphan`. Перед видаленням ви робите помітку, який селектор вона використовує: + +```shell +kubectl get job old -o yaml +``` + +Виввід схожий на цей: + +```yaml +kind: Job +metadata: + name: old + ... +spec: + selector: + matchLabels: + batch.kubernetes.io/controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +Потім ви створюєте нову задачу з імʼям `new` і явно вказуєте той самий селектор. Оскільки існуючі Podʼи мають мітку `batch.kubernetes.io/controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`, вони також контролюються задачею `new`. + +Вам потрібно вказати `manualSelector: true` в новій задачі, оскільки ви не використовуєте селектор, який система зазвичай генерує автоматично. + +```yaml +kind: Job +metadata: + name: new + ... +spec: + manualSelector: true + selector: + matchLabels: + batch.kubernetes.io/controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +Сама нова задача матиме інший uid від `a8f3d00d-c6d2-11e5-9f87-42010af00002`. Встановлення `manualSelector: true` говорить системі, що ви розумієте, що робите, і дозволяє це неспівпадіння. + +### Відстеження задачі за допомогою завершувачів {#job-tracking-with-finalizers} + +{{< feature-state for_k8s_version="v1.26" state="stable" >}} + +Панель управління стежить за Podʼами, які належать будь-якій задачі, і виявляє, чи +Pod був видалений з сервера API. Для цього контролер задачі створює Podʼи з завершувачем `batch.kubernetes.io/job-tracking`. Контролер видаляє завершувач тільки після того, як Pod був врахований в стані задачі, що дозволяє видалити Pod іншими контролерами або користувачами. + +{{< note >}} +Див. [Мій Pod залишається в стані завершення](/docs/tasks/debug/debug-application/debug-pods/), якщо ви спостерігаєте, що Podʼи з задачі залишаються з завершувачем відстеження. +{{< /note >}} + +### Еластичні індексовані задачі {#elastic-indexed-jobs} + +{{< feature-state for_k8s_version="v1.27" state="beta" >}} + +Ви можете масштабувати індексовані задачі вгору чи вниз, змінюючи як `.spec.parallelism`, так і `.spec.completions` разом, з умовою, що `.spec.parallelism == .spec.completions`. Коли увімкнено [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `ElasticIndexedJob` на [сервері API](/docs/reference/command-line-tools-reference/kube-apiserver/), `.spec.completions` є незмінним. + +Сценарії використання для еластичних індексованих задач включають пакетні робочі навантаження, які вимагають масштабування індексованої задачі, такі як навчання MPI, Horovord, Ray, та PyTorch. + +### Відкладене створення замінних Podʼів {#pod-replacement-policy} + +{{< feature-state for_k8s_version="v1.29" state="beta" >}} + +{{< note >}} +Ви можете встановити `podReplacementPolicy` для задач тільки у випадку, якщо увімкнутий [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `JobPodReplacementPolicy` (стандартно увімкнений). +{{< /note >}} + +Типово контролер Job створює Podʼи якнайшвидше, якщо вони або зазнають невдачі, або знаходяться в стані завершення (мають відмітку видалення). Це означає, що в певний момент часу, коли деякі з Podʼів знаходяться в стані завершення, кількість робочих Podʼів для задачі може бути більшою, ніж `parallelism` або більше, ніж один Pod на індекс (якщо ви використовуєте індексовану задачу). + +Ви можете вибрати створення замінних Podʼів лише тоді, коли Podʼи, які знаходиться в стані завершення, повністю завершені (мають `status.phase: Failed`). Для цього встановіть `.spec.podReplacementPolicy: Failed`. Типова політика заміщення залежить від того, чи задача має встановлену політику відмови Podʼів. Якщо для задачі не визначено політику відмови Podʼів, відсутність поля `podReplacementPolicy` вибирає політику заміщення `TerminatingOrFailed`: панель управління створює Podʼи заміни негайно після видалення Podʼів (як тільки панель управління бачить, що Pod для цієї задачі має встановлене значення `deletionTimestamp`). Для задач із встановленою політикою відмови Podʼів стандартне значення `podReplacementPolicy` — це `Failed`, інших значень не передбачено. Докладніше про політики відмови Podʼів для задач можна дізнатися у розділі [Політика відмови Podʼіви](#pod-failure-policy). + +```yaml +kind: Job +metadata: + name: new + ... +spec: + podReplacementPolicy: Failed + ... +``` + +При увімкненому feature gate у вашому кластері ви можете перевірити поле `.status.terminating` задачі. Значення цього поля — це кількість Podʼів, якими володіє задача, які зараз перебувають у стані завершення. + +```shell +kubectl get jobs/myjob -o yaml +``` + +```yaml +apiVersion: batch/v1 +kind: Job +# .metadata and .spec omitted +status: + terminating: 3 # три Podʼи, які перебувають у стані завершення і ще не досягли стану Failed +``` + +## Альтернативи {#alternatives} + +### Тільки Podʼи {#bare-pods} + +Коли вузол, на якому працює Pod, перезавантажується або виходить з ладу, Pod завершується і не буде перезапущений. Однак задача створить нові Podʼи для заміщення завершених. З цієї причини ми рекомендуємо використовувати задачу замість тільки Podʼів, навіть якщо ваш застосунок вимагає тільки рлного Podʼу. + +### Контролер реплікації {#replication-controller} + +Задачі є доповненням до [контролера реплікації](/docs/concepts/workloads/controllers/replicationcontroller/). Контролер реплікації керує Podʼами, які не повинні завершуватися (наприклад, вебсервери), і задача керує Podʼами, які очікують завершення (наприклад, пакетні завдання). + +Якщо врахувати [життєвий цикл Podʼа](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *лише* придатний для Podʼів з `RestartPolicy`, рівним `OnFailure` або `Never`. (Примітка: Якщо `RestartPolicy` не встановлено, стандартне значення — `Always`.) + +### Один Job запускає контролер Podʼів {#single-job-starts-controller-pod} + +Ще один підхід — це те, що одна задача створює Podʼи, які своєю чергою створюють інші Podʼи, виступаючи як свого роду власний контролер для цих Podʼів. Це дає найбільшу гнучкість, але може бути дещо складним для початку використання та пропонує меншу інтеграцію з Kubernetes. + +Один приклад такого підходу — це задача, яка створює Podʼи, яка виконує сценарій, який з свого боку запускає контролер Spark master (див. [приклад Spark](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)), запускає драйвер Spark, а потім робить очищення. + +Перевагою цього підходу є те, що загальний процес отримує гарантію завершення обʼєкта задачі, але при цьому повністю контролюється те, які Podʼи створюються і яке навантаження їм призначається. + +## {{% heading "whatsnext" %}} + +- Дізнайтеся про [Podʼи](/docs/concepts/workloads/pods). +- Дізнайтеся про різні способи запуску задач: + - [Груба паралельна обробка за допомогою робочої черги](/docs/tasks/job/coarse-parallel-processing-work-queue/) + - [Дрібна паралельна обробка за допомогою робочої черги](/docs/tasks/job/fine-parallel-processing-work-queue/) + - Використовуйте [індексовану задачу для паралельної обробки із статичним призначенням навантаження](/docs/tasks/job/indexed-parallel-processing-static/) + - Створіть кілька задач на основі шаблону: [Паралельна обробка з використанням розширень](/docs/tasks/job/parallel-processing-expansion/) +- Перейдіть за посиланням [Автоматичне очищення завершених задач](#clean-up-finished-jobs-automatically), щоб дізнатися більше про те, як ваш кластер може очищати завершені та/або невдачливі завдання. +- `Job` є частиною REST API Kubernetes. Ознайомтесь з визначенням обʼєкта {{< api-reference page="workload-resources/job-v1" >}}, щоб зрозуміти API для задач. +- Прочитайте про [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/), який ви можете використовувати для визначення серії задач, які будуть виконуватися за розкладом, схожим на інструмент UNIX `cron`. +- Попрактикуйтесь в налаштувані обробки відмовних і невідмовних збоїв Podʼів за допомогою `podFailurePolicy` на основі покрокових [прикладів](/docs/tasks/job/pod-failure-policy/). diff --git a/content/uk/docs/concepts/workloads/controllers/replicaset.md b/content/uk/docs/concepts/workloads/controllers/replicaset.md new file mode 100644 index 0000000000000..84c7ad14fa804 --- /dev/null +++ b/content/uk/docs/concepts/workloads/controllers/replicaset.md @@ -0,0 +1,358 @@ +--- +reviewers: +- Kashomon +- bprashanth +- madhusudancs +title: ReplicaSet +feature: + title: Самовідновлення + anchor: Як працює ReplicaSet + description: > + Перезапуск контейнерів, що зізнали збою, заміна та перепланування контейнерів при відмові вузлів, примусове завершення роботи контейнерів, які не відповідають визначеному користувачем стану під час перевірки, очікування їх готовності до роботи перед тим, як надати до них доступ користувачам. +content_type: concept +description: >- + Призначення ReplicaSet полягає в забезпеченні стабільного набору реплік Podʼів, які працюють у будь-який момент часу. Зазвичай ви визначаєте Deployment та дозволяєте цьому Deployment автоматично керувати ReplicaSets. +weight: 20 +hide_summary: true # Listed separately in section index +--- + + + +Призначення ReplicaSet полягає в забезпеченні стабільного набору реплік Podʼів, які працюють у будь-який момент часу. Тож, ReplicaSet часто використовується для гарантування наявності вказаної кількості ідентичних Podʼів. + + + +## Як працює ReplicaSet {#how-a-replicaset-works} + +ReplicaSet визначається полями, включаючи селектор, який вказує, як ідентифікувати Podʼи, які він може отримати, кількість реплік, що вказує, скільки Podʼів він повинен підтримувати, і шаблон Podʼа, який вказує дані для нових Podʼів, які слід створити для відповідності критеріям кількості реплік. ReplicaSet виконує своє призначення, створюючи та видаляючи Podʼи за необхідності для досягнення їх бажаної кількості. Коли ReplicaSet потребує створення нових Podʼів, він використовує свій шаблон Podʼа. + +ReplicaSet повʼязаний зі своїми Podʼами через поле [metadata.ownerReferences](/docs/concepts/architecture/garbage-collection/#owners-dependents) Podʼа, яке вказує, яким ресурсом є власник поточного обʼєкта. Усі Podʼи, які отримав ReplicaSet, мають інформацію про ідентифікацію їхнього власного ReplicaSet у полі ownerReferences. Завдяки цим посиланням ReplicaSet знає про стан Podʼів, які він підтримує, і планує дії відповідно. + +ReplicaSet визначає нові Podʼи для отримання за допомогою свого селектора. Якщо існує Pod, який не має OwnerReference або OwnerReference не є {{< glossary_tooltip term_id="controller" text="контролером">}}, і він відповідає селектору ReplicaSet, його негайно отримає вказаний ReplicaSet. + +## Коли використовувати ReplicaSet {#when-to-use-a-replicaset} + +ReplicaSet забезпечує наявність вказаної кількості реплік Podʼів у будь-який момент часу. Проте Deployment є концепцією вищого рівня, яка управляє ReplicaSets і надає декларативні оновлення для Podʼів, разом із багатьма іншими корисними можливостями. Тому ми рекомендуємо використовувати Deployments замість безпосереднього використання ReplicaSets, якщо вам необхідне настроювання оркестрування оновлень або взагалі не потрібні оновлення. + +Це означає, що вам можливо навіть не доведеться працювати з обʼєктами ReplicaSet: використовуйте Deployment та визначайте ваш застосунок у розділі spec. + +## Приклад {#example} + +{{% code_sample file="controllers/frontend.yaml" %}} + +Зберігаючи цей маніфест у файл `frontend.yaml` та застосовуючи його до кластера Kubernetes ви створите визначений обʼєкт ReplicaSet та Podʼи, якими він керує. + +```shell +kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml +``` + +Ви можете переглянути створений ReplicaSet за допомогою команди: + +```shell +kubectl get rs +``` + +І побачите що створено frontend: + +```none +NAME DESIRED CURRENT READY AGE +frontend 3 3 3 6s +``` + +Ви також можете перевірити стан ReplicaSet: + +```shell +kubectl describe rs/frontend +``` + +Ви побачите вивід подібний до цього: + +```none +Name: frontend +Namespace: default +Selector: tier=frontend +Labels: app=guestbook + tier=frontend +Annotations: kubectl.kubernetes.io/last-applied-configuration: + {"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",... +Replicas: 3 current / 3 desired +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +Pod Template: + Labels: tier=frontend + Containers: + php-redis: + Image: gcr.io/google_samples/gb-frontend:v3 + Port: + Host Port: + Environment: + Mounts: + Volumes: +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 117s replicaset-controller Created pod: frontend-wtsmm + Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-b2zdv + Normal SuccessfulCreate 116s replicaset-controller Created pod: frontend-vcmts +``` + +І нарешті, ви можете перевірити, що Podʼи створені: + +```shell +kubectl get pods +``` + +І побачите щось подібне до цього: + +```none +NAME READY STATUS RESTARTS AGE +frontend-b2zdv 1/1 Running 0 6m36s +frontend-vcmts 1/1 Running 0 6m36s +frontend-wtsmm 1/1 Running 0 6m36s +``` + +Ви можете також перевірити, що посилання на власника цих Podʼів вказує на ReplicaSet. Для цього отримайте деталі одного з Pod в форматі YAML: + +```shell +kubectl get pod frontend-b2zdv -o yaml +``` + +Вихід буде схожий на цей, з інформацією ReplicaSet, встановленою в полі ownerReferences метаданих: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + creationTimestamp: "2020-02-12T07:06:16Z" + generateName: frontend- + labels: + tier: frontend + name: frontend-b2zdv + namespace: default + ownerReferences: + - apiVersion: apps/v1 + blockOwnerDeletion: true + controller: true + kind: ReplicaSet + name: frontend + uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf +... +``` + +## Володіння Podʼами без шаблону {#non-template-pod-acquisition} + +Хоча ви можете створювати прості Podʼи без проблем, настійно рекомендується переконатися, що ці прості Podʼи не мають міток, які відповідають селектору одного з ваших ReplicaSets. Причина цього полягає в тому, що ReplicaSet не обмежується володінням Podʼів, зазначених у його шаблоні — він може отримати інші Podʼи у спосіб, визначений в попередніх розділах. + +Візьмемо приклад попереднього ReplicaSet для фронтенду та Podʼів, визначених у наступному маніфесті: + +{{% code_sample file="pods/pod-rs.yaml" %}} + +Оскільки ці Podʼи не мають контролера (або будь-якого обʼєкта) як власника та відповідають селектору ReplicaSet для фронтенду, вони одразу перейдуть у його володіння. + +Припустимо, ви створюєте Podʼи після того, як ReplicaSet для фронтенду буде розгорнуто та встановлено свої початкові репліки Podʼів для виконання вимог до кількості реплік: + +```shell +kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml +``` + +Нові Podʼи будуть отримані ReplicaSet та негайно завершені, оскільки ReplicaSet буде мати більше, ніж його бажана кількість. + +Отримання Podʼів: + +```shell +kubectl get pods +``` + +Вивід покаже, що нові Podʼи або вже завершено, або в процесі завершення: + +``` +NAME READY STATUS RESTARTS AGE +frontend-b2zdv 1/1 Running 0 10m +frontend-vcmts 1/1 Running 0 10m +frontend-wtsmm 1/1 Running 0 10m +pod1 0/1 Terminating 0 1s +pod2 0/1 Terminating 0 1s +``` + +Якщо ви створите Podʼи спочатку: + +```shell +kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml +``` + +А потім створите ReplicaSet таким чином: + +```shell +kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml +``` + +Ви побачите, що ReplicaSet отримав Podʼи та створив нові лише відповідно до свого опису, доки кількість його нових Podʼів та оригінальних не відповідала його бажаній кількості. Якщо отримати Podʼи: + +```shell +kubectl get pods +``` + +Вивід покаже, що: + +```none +NAME READY STATUS RESTARTS AGE +frontend-hmmj2 1/1 Running 0 9s +pod1 1/1 Running 0 36s +pod2 1/1 Running 0 36s +``` + +Таким чином, ReplicaSet може володіти неоднорідним набором Podʼів. + +## Написання маніфесту ReplicaSet {#writing-a-replicaset-manifest} + +Як і усі інші обʼєкти API Kubernetes, ReplicaSet потребує полів `apiVersion`, `kind` та `metadata`. Для ReplicaSet `kind` завжди є ReplicaSet. + +Коли панель управління створює нові Podʼи для ReplicaSet, `.metadata.name` ReplicaSet є частиною основи для найменування цих Podʼів. Назва ReplicaSet повинна бути дійсним значенням [DNS-піддомену](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names), але це може призвести до неочікуваних результатів для імен хостів Podʼа. Для найкращої сумісності назва має відповідати більш обмеженим правилам для [DNS-мітки](/docs/concepts/overview/working-with-objects/names#dns-label-names). + +ReplicaSet також потребує розділу [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Шаблон Podʼа {#pod-template} + +`.spec.template` — це [шаблон Podʼа](/docs/concepts/workloads/pods/#pod-templates), який також повинен мати встановлені мітки. У нашому прикладі `frontend.yaml` ми мали одну мітку: `tier: frontend`. Будьте обережні, щоб селектори не перекривалися з селекторами інших контролерів, інакше вони можуть намагатися взяти контроль над Podʼом. + +Для політики перезапуску шаблону [restart policy](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy), `.spec.template.spec.restartPolicy`, є допустимим тільки значення `Always`, яке є стандартним значенням. + +### Селектор Podʼа {#pod-selector} + +Поле `.spec.selector` є [селектором міток](/docs/concepts/overview/working-with-objects/labels/). Як обговорювалося [раніше](#how-a-replicaset-works), це мітки, які використовуються для ідентифікації потенційних Podʼів для володіння. У нашому прикладі `frontend.yaml` селектор був: + +```yaml +matchLabels: + tier: frontend +``` + +У ReplicaSet `.spec.template.metadata.labels` має відповідати `spec.selector`, інакше він буде відхилений API. + +{{< note >}} +Для 2 ReplicaSets, які вказують на однаковий `.spec.selector`, але різні `.spec.template.metadata.labels` та `.spec.template.spec` поля, кожен ReplicaSet ігнорує +Podʼи, створені іншим ReplicaSet. +{{< /note >}} + +### Репліки {#replicas} + +Ви можете вказати, скільки Podʼів мають виконуватись одночасно, встановивши значення `.spec.replicas`. ReplicaSet буде створювати/видаляти свої Podʼи щоб кількість Podʼів відповідала цьому числу. Якщо ви не вказали `.spec.Podʼа`, то типово значення дорівнює 1. + +## Робота з ReplicaSets {#working-with-replicasets} + +### Видалення ReplicaSet та його Podʼів {#deleting-a-replicaset-and-its-pods} + +Щоб видалити ReplicaSet і всі його Podʼи, використовуйте [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Збирач сміття [Garbage collector](/docs/concepts/architecture/garbage-collection/) автоматично видаляє всі +залежні Podʼи. + +При використанні REST API або бібліотеки `client-go`, вам потрібно встановити `propagationPolicy` в `Background` або `Foreground` в опції `-d`. Наприклад: + +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \ + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ + -H "Content-Type: application/json" +``` + +### Видалення лише ReplicaSet {#deleting-just-a-replicaset} + +Ви можете видалити ReplicaSet, не впливаючи на його Podʼи за допомогою +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) з опцією `--cascade=orphan`. При використанні REST API або бібліотеки `client-go`, вам потрібно встановити `propagationPolicy` в `Orphan`. Наприклад: + +```shell +kubectl proxy --port=8080 +curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \ + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ + -H "Content-Type: application/json" +``` + +Після видалення оригіналу ви можете створити новий ReplicaSet для заміни. До тих пір поки старий та новий `.spec.selector` однакові, новий прийме старі Podʼи. Однак він не буде намагатися повʼязувати наявні Podʼи з новим, відмінним шаблоном Podʼа. Для оновлення Podʼів до нової специфікації у контрольований спосіб використовуйте [Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment), оскільки ReplicaSets безпосередньо не підтримують rolling update. + +### Ізолювання Podʼів від ReplicaSet {#isolating-pods-from-a-replicaset} + +Ви можете видалити Podʼи з ReplicaSet, змінивши їх мітки. Цей метод може бути використаний для вилучення Podʼів з обслуговування з метою налагодження, відновлення даних і т.д. Podʼи, які вилучаються цим способом, будуть автоматично замінені (за умови, що кількість реплік також не змінюється). + +### Масштабування ReplicaSet {#scaling-a-replicaset} + +ReplicaSet можна легко масштабувати вгору або вниз, просто оновивши поле `.spec.replicas`. Контролер ReplicaSet забезпечує, що бажана кількість Podʼів з відповідним селектором міток доступна та працює. + +При зменшенні масштабу ReplicaSet контролер ReplicaSet вибирає Podʼи для видалення, сортуючи доступні Podʼи, щоб визначити, які Podʼи видаляти в першу чергу, використовуючи наступний загальний алгоритм: + +1. Перш за все прибираються Podʼи, що перебувають в очікуванні. +1. Якщо встановлено анотацію `controller.kubernetes.io/pod-deletion-cost`, то Pod із меншою вартістю буде видалено першим. +1. Podʼи на вузлах з більшою кількістю реплік йдуть перед Podʼами на вузлах з меншою кількістю реплік. +2. Якщо часи створення Podʼів відрізняються, то Pod, створений недавно, йде перед старішим Podʼом (часи створення розділені на цілочисельний логарифмічний масштаб, коли увімкнено [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `LogarithmicScaleDown`) + +Якщо все вище вказане збігається, вибір випадковий. + +### Вартість видалення Podʼа {#pod-deletion-cost} + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +За допомогою анотації [`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) користувачі можуть встановити вподобання щодо порядку видалення Podʼів під час зменшення масштабу ReplicaSet. + +Анотація повинна бути встановлена на Podʼі, діапазон — [-2147483648, 2147483647]. Вона представляє вартість видалення Podʼа порівняно з іншими Podʼами, які належать тому ж ReplicaSet. Podʼи з меншою вартістю видалення видаляються першими на відміну Podʼами з більшою вартістю видалення. + +Неявне значення для цієї анотації для Podʼів, які його не мають, — 0; допустимі відʼємні значення. Неприпустимі значення будуть відхилені API-сервером. + +Ця функція є бета-версією та увімкнена типов. Ви можете вимкнути її, використовуючи [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodDeletionCost` як в kube-apiserver, так і в kube-controller-manager. + +{{< note >}} + +- Цей підхід використовується як найкраще, тому він не пропонує жодних гарантій щодо порядку видалення Podʼів. +- Користувачам слід уникати частого оновлення анотації, такого як оновлення її на основі значення метрики, оскільки це призведе до значного числа оновлень Podʼів на apiserver. + {{< /note >}} + +#### Приклад Використання {#example-use-case} + +Різні Podʼи застосунку можуть мати різний рівень використання. При зменшенні масштабу застосунок може віддавати перевагу видаленню Podʼів з меншим використанням. Щоб уникнути частого оновлення Podʼів, застосунок повинен оновити `controller.kubernetes.io/pod-deletion-cost` один раз перед зменшенням масштабу +(встановлення анотації в значення, пропорційне рівню використання Podʼа). Це працює, якщо сам застосунок контролює масштабування вниз; наприклад, драйвер розгортання Spark. + +### ReplicaSet як ціль горизонтального автомасштабування Podʼа {#replicaset-as-a-horizontal-pod-autoscaler-target} + +ReplicaSet також може бути ціллю для [Горизонтального Автомасштабування Podʼа (HPA)](/docs/tasks/run-application/horizontal-pod-autoscale/). Іншими словами, ReplicaSet може автоматично масштабуватися за допомогою HPA. Ось приклад HPA, який застосовується до ReplicaSet, створеному у попередньому прикладі. + +{{% code_sample file="controllers/hpa-rs.yaml" %}} + +Збереження цього маніфесту в `hpa-rs.yaml` та його застосування до кластера Kubernetes повинно створити визначене HPA, яке автоматично змінює масштаб цільового ReplicaSet залежно від використання ЦП реплікованими Podʼами. + +```shell +kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml +``` + +Або ви можете використовувати команду `kubectl autoscale` для досягнення того ж самого (і це простіше!) + +```shell +kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 +``` + +## Альтернативи ReplicaSet {#alternatives-to-replicaset} + +### Deployment (рекомендовано) {#deployment-recommended} + +[`Deployment`](/docs/concepts/workloads/controllers/deployment/) — це обʼєкт, який може володіти ReplicaSets і оновлювати їх та їхні Podʼи через декларативні оновлення на стороні сервера. Хоча ReplicaSets можуть використовуватися незалежно, на сьогодні вони головним чином використовуються Deployments як механізм для +оркестрування створення, видалення та оновлення Podʼів. Коли ви використовуєте Deployments, вам не потрібно турбуватися про керування ReplicaSets, які вони створюють. Deployments володіють і керують своїми ReplicaSets. Таким чином, рекомендується використовувати Deployments, коли вам потрібні ReplicaSets. + +### Чисті Podʼи {#bare-pods} + +На відміну від випадку, коли користувач безпосередньо створює Podʼи, ReplicaSet замінює Podʼи, які видаляються або завершуються з будь-якої причини, такої як випадок відмови вузла чи розбирання вузла, таке як оновлення ядра. З цього приводу ми рекомендуємо використовувати ReplicaSet навіть якщо ваш застосунок вимагає лише одного Podʼа. Подібно до наглядача процесів, він наглядає за кількома Podʼами на різних вузлах замість окремих процесів на одному вузлі. ReplicaSet делегує перезапуск локальних контейнерів до агента на вузлі, такого як Kubelet. + +### Job + +Використовуйте [`Job`](/docs/concepts/workloads/controllers/job/) замість ReplicaSet для Podʼів, які повинні завершитися самостійно (тобто пакетні завдання). + +### DaemonSet + +Використовуйте [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) замість ReplicaSet для Podʼів, які надають функції на рівні машини, такі як моніторинг стану машини або реєстрація машини. Ці Podʼи мають термін служби, який повʼязаний з терміном служби машини: Pod повинен працювати на машині перед тим, як інші Podʼи почнуть роботу, і можуть бути безпечно завершені, коли машина готова до перезавантаження/вимкнення. + +### ReplicationController + +ReplicaSets — є наступниками [ReplicationControllers](/docs/concepts/workloads/controllers/replicationcontroller/). Обидва служать тому ж самому призначенню та поводяться схоже, за винятком того, що ReplicationController не підтримує вимоги +вибору на основі множини, як описано в [посібнику про мітки](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Таким чином, ReplicaSets має перевагу над ReplicationControllers. + +## {{% heading "whatsnext" %}} + +- Дізнайтеся про [Podʼи](/docs/concepts/workloads/pods). +- Дізнайтеся про [Deploуments](/docs/concepts/workloads/controllers/deployment/). +- [Запустіть Stateless Application за допомогою Deployment](/docs/tasks/run-application/run-stateless-application-deployment/), що ґрунтується на роботі ReplicaSets. +- `ReplicaSet` — це ресурс верхнього рівня у Kubernetes REST API. Прочитайте визначення обʼєкта {{< api-reference page="workload-resources/replica-set-v1" >}}, щоб розуміти API для реплік. +- Дізнайтеся про [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) та як ви можете використовувати його для управління доступністю застосунку під час перебоїв. + diff --git a/content/uk/docs/concepts/workloads/controllers/replicationcontroller.md b/content/uk/docs/concepts/workloads/controllers/replicationcontroller.md new file mode 100644 index 0000000000000..4a6ef22af1fbd --- /dev/null +++ b/content/uk/docs/concepts/workloads/controllers/replicationcontroller.md @@ -0,0 +1,236 @@ +--- +reviewers: +- bprashanth +- janetkuo +title: ReplicationController +content_type: concept +weight: 90 +description: >- + Застаріле API для управління навантаженням, яке може горизонтально масштабуватися. Замінено API Deployment та ReplicaSet. +--- + + + +{{< note >}} +[`Deployment`](/docs/concepts/workloads/controllers/deployment/), який налаштовує [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/), тепер є рекомендованим способом налаштування реплікації. +{{< /note >}} + +_ReplicationController_ гарантує, що завжди запущено зазначену кількість реплік Podʼів. Іншими словами, ReplicationController переконується, що Pod або однорідний набір Podʼів завжди працює та доступний. + + + +## Як працює ReplicationController {#how-a-replicationcontroller-works} + +Якщо є занадто багато Podʼів, ReplicationController завершує зайві Podʼи. Якщо Podʼів замало, ReplicationController запускає додаткові. На відміну від вручну створених Podʼів, Podʼи, якими керує ReplicationController, автоматично замінюються, якщо вони відмовляють, видаляються або завершуються. Наприклад, ваші Podʼи перестворюються на вузлі після руйнівного обслуговування, такого як оновлення ядра. З цієї причини ви повинні використовувати ReplicationController навіть якщо ваша програма вимагає лише одного Podʼа. ReplicationController схожий на менеджер процесів, але замість того, щоб наглядати за окремими процесами на одному вузлі, ReplicationController наглядає за кількома Podʼами на різних вузлах. + +ReplicationController часто скорочується до "rc" в обговореннях та як скорочення в командах kubectl. + +Простим випадком є створення одного обʼєкта ReplicationController для надійного запуску одного екземпляра Pod нескінченно. Складніший випадок — це запуск кількох ідентичних реплік реплікованої служби, такої як вебсервери. + +## Запуск прикладу ReplicationController {#running-an-example-replicationcontroller} + +Цей приклад конфігурації ReplicationController запускає три копії вебсервера nginx. + +```shell +kubectl apply -f https://k8s.io/examples/controllers/replication.yaml +``` + +Вивід подібний до такого: + +```none +replicationcontroller/nginx created +``` + +Перевірте стан ReplicationController за допомогою цієї команди: + +```shell +kubectl describe replicationcontrollers/nginx +``` + +Вивід подібний до такого: + +```none +Name: nginx +Namespace: default +Selector: app=nginx +Labels: app=nginx +Annotations: +Replicas: 3 current / 3 desired +Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed +Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx + Port: 80/TCP + Environment: + Mounts: + Volumes: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- ---- ------ ------- + 20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-qrm3m + 20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-3ntk0 + 20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-4ok8v +``` + +Тут створено три Podʼи, але жоден ще не працює, можливо, через те, що виконується витягування образу. Трохи пізніше та ж команда може показати: + +```shell +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +``` + +Щоб перелічити всі Podʼи, які належать ReplicationController у формі, придатній для машинного читання, можна використовувати команду на зразок: + +```shell +pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name}) +echo $pods +``` + +Вивід подібний до такого: + +```none +nginx-3ntk0 nginx-4ok8v nginx-qrm3m +``` + +Тут селектор такий самий, як і селектор для ReplicationController (бачимо у виводі `kubectl describe`), і в іншій формі у `replication.yaml`. Опція `--output=jsonpath` вказує вираз з іменем кожного Podʼу в отриманому списку. + +## Створення маніфесту ReplicationController {#writing-a-replicationcontroller-manifest} + +Як і з усіма іншими конфігураціями Kubernetes, для ReplicationController потрібні поля `apiVersion`, `kind` і `metadata`. + +Коли панель управління створює нові Podʼи для ReplicationController, `.metadata.name` ReplicationController є частиною основи для найменування цих Podʼів. Назва ReplicationController повинна бути дійсним значенням [DNS-піддомену](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names), але це може призводити до неочікуваних результатів для імен хостів Podʼів. Для забезпечення найкращої сумісності імʼя повинно відповідати більш обмеженим правилам для [DNS-мітки](/docs/concepts/overview/working-with-objects/names#dns-label-names). + +Для загальної інформації про роботу з файлами конфігурації дивіться [управління обʼєктами](/docs/concepts/overview/working-with-objects/object-management/). + +ReplicationController також потребує розділу [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Шаблон Pod {#pod-template} + +`.spec.template` — єдине обовʼязкове поле в розділі `.spec`. + +`.spec.template` — це [шаблон pod](/docs/concepts/workloads/pods/#pod-templates). Він має точно таку ж схему, як і {{< glossary_tooltip text="Pod" term_id="pod" >}}, за винятком того, що він вкладений і не має `apiVersion` або `kind`. + +Окрім обовʼязкових полів для Pod, шаблон pod в ReplicationController повинен вказати відповідні мітки та відповідну політику перезапуску. Щодо міток, переконайтеся, що вони не перекриваються з іншими контролерами. Див. [селектор pod](#pod-selector). + +Дозволяється лише [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy), рівна `Always`, якщо не вказано інше, що є стандартним значенням. + +Для локальних перезапусків контейнерів ReplicationControllers делегують агентові на вузлі, наприклад, [Kubelet](/docs/reference/command-line-tools-reference/kubelet/). + +### Мітки на ReplicationController {#labels-on-the-replicationcontrollers} + +ReplicationController може мати власні мітки (`.metadata.labels`). Зазвичай ви встановлюєте їх так само, як і `.spec.template.metadata.labels`; якщо `.metadata.labels` не вказано, то вони cnfylfhnyj встановлюються як `.spec.template.metadata.labels`. Однак вони можуть бути різними, і `.metadata.labels` не впливають на поведінку ReplicationController. + +### Селектор Pod {#pod-selector} + +Поле `.spec.selector` є [селектором міток](/docs/concepts/overview/working-with-objects/labels/#label-selectors). ReplicationController керує всіма Podʼами з мітками, які відповідають селектору. Він не робить різниці між Podʼами, які він створив чи видалив, і Podʼами, які створив чи видалив інший процес чи особа. Це дозволяє замінити ReplicationController без впливу на робочі Podʼи. + +Якщо вказано, то `.spec.template.metadata.labels` повинні бути рівні `.spec.selector`, або вони буде відхилені API. Якщо `.spec.selector` не вказано, він буде встановлений типово як `.spec.template.metadata.labels`. + +Також, як правило, ви не повинні створювати жодних Podʼів, мітки яких відповідають цьому селектору, безпосередньо, з іншим ReplicationController або з іншим контролером, таким як Job. Якщо ви це зробите, то ReplicationController вважатиме, що він створив інші Podʼами. Kubernetes не забороняє вам це робити. + +Якщо у вас все-таки виникає кілька контролерів з однаковими селекторами, вам доведеться керувати видаленням самостійно (див. [нижче](#working-with-replicationcontrollers)). + +### Декілька Реплік {#multiple-replicas} + +Ви можете вказати, скільки Podʼів повинно працювати одночасно, встановивши `.spec.replicas` рівним кількості Podʼів, які ви хочете мати одночасно. Кількість, що працює в будь-який момент, може бути більшою або меншою, наприклад, якщо репліки тільки що були збільшені або зменшені, чи якщо Pod коректно зупинено, і запускається його заміна. + +Якщо ви не вказали `.spec.replicas`, то типово встановлюється 1. + +## Робота з ReplicationControllers {#working-with-replicationcontrollers} + +### Видалення ReplicationController та його Podʼів {#deleting-a-replicationcontroller-and-its-pods} + +Щоб видалити ReplicationController та всі його Podʼи, використовуйте команду [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl масштабує ReplicationController до нуля і чекає, доки кожний Pod буде видалено, перед видаленням самого ReplicationController. Якщо цю команду kubectl перервати, її можна перезапустити. + +При використанні REST API або [бібліотеки клієнта](/docs/reference/using-api/client-libraries), вам потрібно виконати кроки явно (масштабування реплік до 0, очікування видалення Podʼів, а потім видалення самого ReplicationController). + +### Видалення лише ReplicationController {#deleting-only-a-replicationcontroller} + +Ви можете видалити ReplicationController, не впливаючи на його Podʼи. + +При використанні kubectl вкажіть опцію `--cascade=orphan` команді [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). + +При використанні REST API або [бібліотеки клієнта](/docs/reference/using-api/client-libraries) ви можете видалити обʼєкт ReplicationController. + +Після видалення оригіналу ви можете створити новий ReplicationController, щоб замінити його. Поки старий та новий `.spec.selector` однакові, то новий прийме старі Podʼи. Однак він не буде вживати жодних зусиль, щоб наявні Podʼи відповідали новому, відмінному від оригінального, шаблону Podʼа. Щоб оновити Podʼи за новою специфікацією у керований спосіб, використовуйте [кероване оновлення](#rolling-updates). + +### Ізолювання Podʼів від ReplicationController {#isolating-pods-from-a-replicationcontroller} + +Podʼи можуть бути вилучені із цільового набору ReplicationController, зміною їх мітки. Цей метод може бути використаний для відокремлення Podʼів від служби для налагодження та відновлення даних. Podʼи, які були виокремлені цим способом, будуть автоматично замінені (за умови, що кількість реплік також не змінюється). + +## Загальні патерни використання {#common-usage-patterns} + +### Перепланування {#rescheduling} + +Як було зазначено вище, чи у вас є 1 Pod, який вам потрібно тримати в роботі, чи 1000, ReplicationController гарантує, що зазначена кількість Podʼів існує, навіть у випадку відмови вузла або завершення Podʼа (наприклад, через дію іншого агента управління). + +### Масштабування {#scaling} + +ReplicationController дозволяє масштабувати кількість реплік вгору або вниз, як вручну, так і за допомогою агента автомасштабування, оновлюючи поле `replicas`. + +### Поступові оновлення {#rolling-updates} + +ReplicationController призначений для полегшення поступового оновлення служби за допомогою заміни Podʼів один за одним. + +Як пояснено в [#1353](https://issue.k8s.io/1353), рекомендований підхід — створити новий ReplicationController з 1 реплікою, масштабувати нові (+1) та старі (-1) контролери по одному, а потім видалити старий контролер після досягнення 0 реплік. Це передбачувано оновлює набір Podʼів незалежно від неочікуваних відмов. + +В ідеалі, контролер поступового оновлення мав би враховувати готовність застосунків і гарантувати, що достатня кількість Podʼів завжди працює. + +Два ReplicationController повинні створювати Podʼи із принаймні однією відмінною міткою, такою як теґ образу основного контейнера Podʼа, оскільки це зазвичай оновлення образу, що мотивує поступові оновлення. + +### Кілька треків випуску {#multiple-release-tracks} + +Крім того, щоб запустити кілька випусків застосунку під час процесу поступового оновлення, часто використовують кілька треків випуску протягом тривалого періоду часу або навіть постійно, використовуючи кілька треків випуску. Треки можуть бути розрізнені за допомогою міток. + +Наприклад, служба може охоплювати всі Podʼи з `tier in (frontend), environment in (prod)`. Тепер скажімо, у вас є 10 реплікованих Podʼів, які складають цей рівень. Але ви хочете мати можливість 'канаркову' нову версію цього компонента. Ви можете налаштувати ReplicationController із `replicas`, встановленим на 9 для більшості реплік, з мітками `tier=frontend, environment=prod, track=stable`, та інший ReplicationController із `replicas`, встановленим на 1 для канарки, з мітками `tier=frontend, environment=prod, track=canary`. Тепер служба охоплює як канаркові, так і не канаркові Podʼи. Але ви можете окремо взаємодіяти з ReplicationControllers, щоб тестувати речі, відстежувати результати і т.д. + +### Використання ReplicationControllers з Service {#using-replicationcontrollers-with-services} + +Декілька ReplicationControllers можуть бути розміщені поза одним Service, так що, наприклад, частина трафіку іде до старої версії, а частина до нової. + +ReplicationController ніколи не завершиться самостійно, але не очікується, що він буде таким тривалим, як Service. Service можуть складатися з Podʼів, які контролюються кількома ReplicationControllers, і передбачається, що протягом життя Service (наприклад, для виконання оновлення Podʼів, які виконують Service) буде створено і знищено багато ReplicationControllers. Як самі Service, так і їх клієнти повинні залишатися осторонь від ReplicationControllers, які утримують Podʼи Service. + +## Написання програм для Replication {#writing-programs-for-replication} + +Створені ReplicationController'ом Podʼи призначені бути взаємозамінними та семантично ідентичними, хоча їх конфігурації можуть ставати різноманітними з часом. Це очевидний вибір для реплікованих stateless серверів, але ReplicationControllers також можна використовувати для забезпечення доступності застосунків, які вибирають майстра, або мають розподілені, або пул робочих задач. Такі застосунки повинні використовувати механізми динамічного призначення роботи, такі як [черги роботи RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-two-python.html), на відміну від статичної / одноразової настроюваної конфігурації кожного Podʼа, що вважається анти-патерном. Будь-яке настроювання Podʼа, таке як вертикальне автоматичне масштабування ресурсів (наприклад, процесора чи памʼяті), повинно виконуватися іншим процесом контролю в режимі реального часу, подібним до самого ReplicationController. + +## Обовʼязки ReplicationController {#responsibilities-of-the-replicationcontroller} + +ReplicationController забезпечує відповідність бажаної кількості Podʼів його селектору міток та їхню функціональність. Наразі з його підрахунку виключаються лише завершені Podʼи. У майбутньому можливо буде враховувати інформацію про [готовність](https://issue.k8s.io/620) та інші дані, доступні від системи, можливо буде додано більше елементів керування над політикою заміщення, і планується генерація подій, які можуть використовуватися зовнішніми клієнтами для впровадження довільних складних політик заміщення та / або масштабування вниз. + +ReplicationController завжди обмежується цією вузькою відповідальністю. Він самостійно не буде виконувати перевірки готовності або тестів на життєздатність. Замість автоматичного масштабування він призначений для управління зовнішнім автомасштабувальником (як обговорюється в [#492](https://issue.k8s.io/492)), який буде змінювати його поле `replicas`. Ми не будемо додавати політик планування (наприклад, [розподілення](https://issue.k8s.io/367#issuecomment-48428019)) до ReplicationController. Він також не повинен перевіряти, чи відповідають контрольовані Podʼи поточному зазначеному шаблону, оскільки це може заважати автоматичному зміщенню розміру та іншим автоматизованим процесам. Також термінові строки виконання, залежності від порядку, розширення конфігурації та інші функції належать іншим місцям. Навіть планується виділити механізм масового створення Podʼів ([#170](https://issue.k8s.io/170)). + +ReplicationController призначений бути базовим примітивом для побудови композиційних структур. Ми очікуємо, що на його основі та інших взаємодіючих примітивів у майбутньому буде побудовано високорівневі API та / або інструменти для зручності користувачів. "Макро" операції, які наразі підтримуються kubectl (run, scale), є прикладами концепції. Наприклад, можемо уявити щось на зразок [Asgard](https://netflixtechblog.com/asgard-web-based-cloud-management-and-deployment-2c9fc4e4d3a1), що управляє ReplicationControllers, автомасштабувальниками, сервісами, політиками планування, канарковими розгортаннями та іншими аспектами. + +## Обʼєкт API {#api-object} + +ReplicationController є ресурсом верхнього рівня в Kubernetes REST API. Докладніша інформація про обʼєкт API може бути знайдена за посиланням: [Обʼєкт API ReplicationController](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replicationcontroller-v1-core). + +## Альтернативи ReplicationController {#alternatives-to-replicationcontroller} + +### ReplicaSet + +[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) — це ReplicationController нового покоління, який підтримує нові [вимоги щодо вибору міток на основі множин](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement). Він використовується головним чином [Deployment](/docs/concepts/workloads/controllers/deployment/) як механізм для оркестрування створення, видалення та оновлення Podʼів. Зауважте, що ми рекомендуємо використовувати Deployments замість безпосереднього використання Replica Sets, якщо вам потрібна власне оркестрування оновлення або взагалі не потрібні оновлення. + +### Deployment (Рекомендовано) {#deployment-recommended} + +[`Deployment`](/docs/concepts/workloads/controllers/deployment/) — це обʼєкт API вищого рівня, який оновлює свої базові Replica Sets та їхні Podʼи. Deployments рекомендуються, якщо вам потрібна функціональність плавного оновлення, оскільки вони є декларативними, виконуються на сервері та мають додаткові функції. + +### Тільки Podʼи {#bare-pods} + +На відміну від випадку, коли користувач створює Podʼи безпосередньо, ReplicationController замінює Podʼи, які видаляються або завершуються з будь-якого приводу, такого як випадок відмови вузла або руйнівне технічне обслуговування вузла, таке як оновлення ядра. З цієї причини ми рекомендуємо використовувати ReplicationController навіть якщо ваша програма вимагає лише одного Podʼу. Вважайте це подібним наглядачу процесів, тільки він наглядає за кількома Podʼами на кількох вузлах, а не за окремими процесами на одному вузлі. ReplicationController делегує перезапуск контейнерів локальній системі, наприклад Kubelet. + +### Job + +Використовуйте [`Job`](/docs/concepts/workloads/controllers/job/) замість ReplicationController для Podʼів, які мають завершуватись самі по собі (іншими словами, пакетні завдання). + +### DaemonSet + +Використовуйте [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) замість ReplicationController для Podʼів, які забезпечують функцію рівня машини, таку як моніторинг машини або ведення логу машини. Ці Podʼи мають термін служби, який повʼязаний із терміном служби машини: Pod повинty працювати на машині перед тим, як інші Podʼи почнуть працювати, і може бути безпечно завершений, коли машина готова до перезавантаження або вимкнення. + +## {{% heading "whatsnext" %}} + +* Більше про [Podʼи](/docs/concepts/workloads/pods). +* Дізнайтеся більше про [Deployment](/docs/concepts/workloads/controllers/deployment/), альтернативу ReplicationController. +* `ReplicationController` — це частина Kubernetes REST API. Ознайомтесь з визначенням обʼєкта {{< api-reference page="workload-resources/replication-controller-v1" >}}, щоб зрозуміти API для контролерів реплікації. diff --git a/content/uk/docs/concepts/workloads/controllers/statefulset.md b/content/uk/docs/concepts/workloads/controllers/statefulset.md new file mode 100644 index 0000000000000..52cdef3142167 --- /dev/null +++ b/content/uk/docs/concepts/workloads/controllers/statefulset.md @@ -0,0 +1,327 @@ +--- +reviewers: +- enisoc +- erictune +- foxish +- janetkuo +- kow3ns +- smarterclayton +title: StatefulSets +content_type: concept +description: >- + StatefulSet — це обʼєкт робочого навантаження API, який використовується для управління застосунками зі збереженням стану. Він запускає групу Podʼів і зберігає стійку ідентичність для кожного з цих Podʼів. Це корисно для керування + застосвунками, які потребують постійного сховища або стабільної, унікальної мережевої ідентичності. +weight: 30 +hide_summary: true # Listed separately in section index +--- + + + +StatefulSet — це обʼєкт робочого навантаження API, який використовується для управління застосунками зі збереженням стану. + +{{< glossary_definition term_id="statefulset" length="all" >}} + + + +## Використання StatefulSets {#using-statefulsets} + +StatefulSets є цінним інструментом для застосунків, які потребують однієї або декількох речей з наступного. + +* Стабільних, унікальних мережевих ідентифікаторів. +* Стабільного, постійного сховища. +* Упорядкованого, відповідного розгортання та масштабування. +* Упорядкованих, автоматизованих поступових (rolling) оновлень. + +У випадку відсутності потреби в стабільних ідентифікаторах або упорядкованому розгортанні, видаленні чи масштабуванні, вам слід розгортати свою програму за допомогою робочого об'єкта, який забезпечує набір реплік без збереження стану (stateless). [Deployment](/docs/concepts/workloads/controllers/deployment/) або [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) можуть бути більш придатними для ваших потреб. + +## Обмеження {#limitations} + +* Місце для зберігання для певного Podʼу повинно буде виділене чи вже виділено + [PersistentVolume Provisioner](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md) на основі запиту `storage class`, або виділено адміністратором наперед. +* Видалення та/або масштабування StatefulSet вниз *не* призведе до видалення томів, повʼязаних з StatefulSet. Це зроблено для забезпечення безпеки даних, яка загалом є важливішою, ніж автоматичне очищення всіх повʼязаних ресурсів StatefulSet. +* Наразі для StatefulSets обовʼязково потрібний [Headless Service](/docs/concepts/services-networking/service/#headless-services) щоб відповідати за мережевий ідентифікатор Podʼів. Вам слід створити цей Сервіс самостійно. +* StatefulSets не надають жодних гарантій щодо припинення роботи Podʼів при видаленні StatefulSet. Для досягнення упорядкованого та відповідного завершення роботи Podʼів у StatefulSet можливо зменшити масштаб StatefulSet до 0 перед видаленням. +* При використанні [Поступових Оновлень](#rolling-updates) використовуючи стандартну [Політику Керування Podʼів](#pod-management-policies) (`OrderedReady`), можливе потрапляння в стан, що вимагає [ручного втручання для виправлення](#forced-rollback). + +## Компоненти {#components} + +Наведений нижче приклад демонструє компоненти StatefulSet. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: nginx + labels: + app: nginx +spec: + ports: + - port: 80 + name: web + clusterIP: None + selector: + app: nginx +--- +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: web +spec: + selector: + matchLabels: + app: nginx # повинно відповідати .spec.template.metadata.labels + serviceName: "nginx" + replicas: 3 # типово 1 + minReadySeconds: 10 # типово 0 + template: + metadata: + labels: + app: nginx # повинно відповідати .spec.selector.matchLabels + spec: + terminationGracePeriodSeconds: 10 + containers: + - name: nginx + image: registry.k8s.io/nginx-slim:0.8 + ports: + - containerPort: 80 + name: web + volumeMounts: + - name: www + mountPath: /usr/share/nginx/html + volumeClaimTemplates: + - metadata: + name: www + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: "my-storage-class" + resources: + requests: + storage: 1Gi +``` + +{{< note >}} +Цей приклад використовує режим доступу `ReadWriteOnce`, для спрощення. Для +промислового використання проєкт Kubernetes рекомендує використовувати режим доступу +`ReadWriteOncePod`. +{{< /note >}} + +У вищенаведеному прикладі: + +* Використовується Headless Service, з назвою `nginx`, для управління мережевим доменом. +* StatefulSet, названий `web`, має Spec, який вказує на те, що буде запущено 3 репліки контейнера nginx в унікальних Podʼах. +* `volumeClaimTemplates` буде забезпечувати стійке зберігання за допомогою [PersistentVolumes](/docs/concepts/storage/persistent-volumes/), виділених PersistentVolume Provisioner. + +Назва обʼєкта StatefulSet повинна бути дійсною [DNS міткою](/docs/concepts/overview/working-with-objects/names#dns-label-names). + +### Селектор Podʼів {#pod-selector} + +Вам слід встановити поле `.spec.selector` StatefulSet, яке збігається з міткам його +`.spec.template.metadata.labels`. Нездатність вказати відповідний селектор Pod призведе до помилки перевірки під час створення StatefulSet. + +### Шаблони заявок на місце для зберігання {#volume-claim-templates} + +Ви можете встановити поле `.spec.volumeClaimTemplates`, яке може забезпечити стійке зберігання за допомогою [PersistentVolumes](/docs/concepts/storage/persistent-volumes/), виділених PersistentVolume Provisioner. + +### Мінімальний час готовності {#minimum-ready-seconds} + +{{< feature-state for_k8s_version="v1.25" state="stable" >}} + +`.spec.minReadySeconds` є необовʼязковим полем, яке вказує мінімальну кількість секунд, протягом яких новий створений Pod повинен працювати та бути готовим, без виходу будь-яких його контейнерів з ладу, щоб вважатися доступним. Це використовується для перевірки прогресу розгортання при використанні стратегії [Поступового Оновлення](#rolling-updates). Це поле станлартно дорівнює 0 (Pod вважатиметься доступним одразу після готовності). Дізнайтеся більше про те, коли +Pod вважається готовим, див. [Проби Контейнера](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). + +## Ідентичність Podʼа {#pod-identity} + +Podʼи StatefulSet мають унікальну ідентичність, яка складається з порядкового номера, стабільного мережевого ідентифікатора та стійкого сховища. Ця ідентичність залишається прикріпленою до Podʼа, незалежно від того, на якому вузлі він перепланований чи знову запланований. + +### Порядковий індекс {#ordinal-index} + +Для StatefulSet з N [реплік](#replicas) кожному Podʼу в StatefulSet буде призначено ціле число, яке є унікальним у наборі. Стандартно Podʼам буде призначено порядкові номери від 0 до N-1. Контролер StatefulSet також додасть мітку Podʼа з цим індексом: `apps.kubernetes.io/pod-index`. + +### Початковий порядковий номер {#start-ordinal} + +{{< feature-state for_k8s_version="v1.27" state="beta" >}} + +`.spec.ordinals` — це необовʼязкове поле, яке дозволяє налаштовувати цілі числові порядкові номери, призначені кожному Podʼу. Стандартно це поле дорівнює nil. Вам потрібно увімкнути власний [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `StatefulSetStartOrdinal`, щоб використовувати це поле. Після увімкнення ви можете налаштувати наступні параметри: + +* `.spec.ordinals.start`: Якщо встановлено поле `.spec.ordinals.start`, Podʼам будуть призначені порядкові номери від `.spec.ordinals.start` до + `.spec.ordinals.start + .spec.replicas - 1`. + +### Стабільний мережевий ідентифікатор {#stable-network-id} + +Кожен Pod в StatefulSet виводить назву свого хосту з імені StatefulSet та порядкового номера Podʼа. Шаблон для створеного імені хосту має вигляд `$(ім'я statefulset)-$(порядковий номер)`. У вищезазначеному прикладі буде створено три Podʼа з іменами `web-0,web-1,web-2`. StatefulSet може використовувати [Headless Service](/docs/concepts/services-networking/service/#headless-services) +для управління доменом своїх Podʼів. Домен, яким управляє цей сервіс, має вигляд: +`$(ім'я сервісу).$(простір імен).svc.cluster.local`, де "cluster.local" — це кластерний домен. При створенні кожного Podʼа він отримує відповідний DNS-піддомен, який має вигляд: `$(ім'я Podʼа).$(головний домен сервісу)`, де головний сервіс визначається полем `serviceName` в StatefulSet. + +Залежно від того, як налаштований DNS у вашому кластері, ви можливо не зможете одразу знаходити DNS-імʼя для нового Podʼа. Це можливо, коли інші клієнти в кластері вже відправили запити на імʼя хосту Podʼа до його створення. Негативне кешування (зазвичай для DNS) означає, що результати попередніх невдалих пошуків запамʼятовуються та використовуються, навіть після того, як Pod вже працює, принаймні кілька секунд. + +Якщо вам потрібно виявити Podʼи негайно після їх створення, у вас є кілька варіантів: + +* Запитуйте API Kubernetes безпосередньо (наприклад, використовуючи режим спостереження), а не покладаючись на DNS-запити. +* Зменште час кешування в вашому постачальнику DNS Kubernetes (зазвичай це означає редагування ConfigMap для CoreDNS, який зараз кешує протягом 30 секунд). + +Як зазначено в розділі [Обмеження](#limitations), ви відповідаєте за створення +[Headless Service](/docs/concepts/services-networking/service/#headless-services), відповідального за мережевий ідентифікатор Podʼів. + +Ось деякі приклади варіантів вибору кластерного домену, імені сервісу, +імені StatefulSet та того, як це впливає на DNS-імена Podʼів StatefulSet. + +Кластерний домен | Сервіс (ns/ім'я) | StatefulSet (ns/ім'я) | Домен StatefulSet | DNS Podʼа | Імʼя хоста Podʼа | +-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ | + cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} | + cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} | + kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | + +{{< note >}} +Кластерний домен буде встановлено як `cluster.local`, якщо не буде +[інших налаштувань](/docs/concepts/services-networking/dns-pod-service/). +{{< /note >}} + +### Стійке сховище {#stable-storage} + +Для кожного вхідного запису `volumeClaimTemplates`, визначеного в StatefulSet, кожен Pod отримує один PersistentVolumeClaim. У прикладі з nginx кожен Pod отримує один PersistentVolume з StorageClass `my-storage-class` та 1 ГБ зарезервованого сховища. Якщо не вказано StorageClass, то використовуватиметься стандартний розмір сховища. Коли Pod переплановується на вузлі, його `volumeMounts` монтує PersistentVolumes, повʼязані із його PersistentVolume Claims. Зазначте, що PersistentVolumes, повʼязані із PersistentVolume Claims Podʼів, не видаляються при видаленні Podʼів чи StatefulSet. Це слід робити вручну. + +### Мітка імені Podʼа {#pod-name-label} + +Коли StatefulSet {{}} створює Pod, він додає мітку `statefulset.kubernetes.io/pod-name`, яка дорівнює назві Podʼа. Ця мітка дозволяє прикріплювати Service до конкретного Podʼа в StatefulSet. + +### Мітка індексу Podʼа + +{{< feature-state for_k8s_version="v1.28" state="beta" >}} + +Коли StatefulSet {{}} створює Pod, новий Pod має мітку `apps.kubernetes.io/pod-index`. Значення цієї мітки — це порядковий індекс Podʼа. Ця мітка дозволяє маршрутизувати трафік до певного індексу Podʼа, фільтрувати логи/метрики за допомогою мітки індексу Podʼа та інше. Зауважте, що feature gate `PodIndexLabel` повинен бути увімкнений для цієї +функції, і стандартно він увімкнений. + +## Гарантії розгортання та масштабування {#deployment-and-scaling-guarantees} + +* Для StatefulSet із N реплік, при розгортанні Podʼи створюються послідовно, у порядку від {0..N-1}. +* При видаленні Podʼів вони закінчуються у зворотньому порядку, від {N-1..0}. +* Перед тим як застосувати масштабування до Podʼа, всі його попередники повинні бути запущені та готові. +* Перед тим як Pod буде припинено, всі його наступники повинні бути повністю зупинені. + +StatefulSet не повинен вказувати `pod.Spec.TerminationGracePeriodSeconds` рівним 0. Це практика небезпечна і настійно не рекомендується. Для отримання додаткової інформації, зверніться до [примусового видалення Podʼів StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/). + +Коли створюється приклад nginx вище, три Podʼа будуть розгорнуті в порядку web-0, web-1, web-2. web-1 не буде розгорнуто, поки web-0 не буде [запущений і готовий](/docs/concepts/workloads/pods/pod-lifecycle/), і web-2 не буде розгорнуто, поки +web-1 не буде запущений і готовий. Якщо web-0 виявиться несправним, після того, як web-1 стане запущеним і готовим, але до запуску web-2, web-2 не буде запущено, поки web-0 успішно перезапуститься і стане запущеним і готовим. + +Якщо користувач масштабує розгорнутий приклад, застосовуючи патчи до StatefulSet так, так щоб `replicas=1`, спочатку буде припинено web-2. web-1 не буде припинено, поки web-2 повністю не завершить свою роботу та буде видалено. Якщо web-0 виявиться невдалим після того, як web-2 вже був припинений і повністю завершено, але перед видаленням web-1, web-1 не буде припинено, поки web-0 не стане запущеним і готовим. + +### Політики управління Podʼами {#pod-management-policies} + +StatefulSet дозволяє зменшити його гарантії послідовності, зберігаючи при цьому його гарантії унікальності та ідентичності за допомогою поля `.spec.podManagementPolicy`. + +#### Політика управління Podʼами "OrderedReady" {#orderedready-pod-management} + +`OrderedReady` є типовим значенням політики управління Podʼами для StatefulSet. Вона реалізує поведінку, описану [вище](#deployment-and-scaling-guarantees). + +#### Політика управління Podʼами "Parallel" {#parallel-pod-management} + +"Parallel" вказує контролеру StatefulSet запускати або припиняти всі Podʼи паралельно, і не чекати, поки Podʼи стануть запущеними та готовими або повністю припиняться перед запуском або видаленням іншого Podʼа. Ця опція впливає лише на поведінку операцій масштабування. Оновлення не підпадають під вплив. + +## Стратегії оновлення {#update-strategies} + +Поле `.spec.updateStrategy` обʼєкта StatefulSet дозволяє налаштовувати +та вимикати автоматизовані поетапні оновлення для контейнерів, міток, ресурсів (запити/обмеження) та анотацій для Podʼів у StatefulSet. Є два можливих значення: + +`OnDelete` +: Коли поле `.spec.updateStrategy.type` StatefulSet встановлено в `OnDelete`, контролер StatefulSet не буде автоматично оновлювати Podʼи в StatefulSet. Користувачам необхідно вручну видаляти Podʼи, щоб спричинити створення контролером нових Podʼів, які відображають зміни, внесені в `.spec.template` StatefulSet. + +`RollingUpdate` +: Стратегія оновлення `RollingUpdate` реалізує автоматизовані, поетапні оновлення для Podʼів у StatefulSet. Це значення є стандартною стратегією оновлення. + +## Поступові оновлення {#rolling-updates} + +Коли поле `.spec.updateStrategy.type` StatefulSet встановлено на `RollingUpdate`, +контролер StatefulSet буде видаляти та знову створювати кожен Pod у StatefulSet. Він буде продовжувати в тому ж порядку, що й завершення роботи Podʼа (від найбільшого індексу до найменшого), оновлюючи кожен Pod по одному. + +Панель управління Kubernetes чекає, доки оновлений Pod буде переведений в стан Running and Ready, перш ніж оновити його попередника. Якщо ви встановили `.spec.minReadySeconds` (див. [Мінімальна кількість секунд готовності](#minimum-ready-seconds)), панель управління також чекає вказану кількість секунд після того, як Pod стане готовим, перш ніж перейти далі. + +### Оновлення з розділенням {#partitions} + +Стратегію оновлення `RollingUpdate` можна розділити, вказавши `.spec.updateStrategy.rollingUpdate.partition`. Якщо вказано розділ, всі Podʼи з індексом, який більший або рівний розділу, будуть оновлені при оновленні `.spec.template` StatefulSet. Усі Podʼи з індексом, який менший за розділ, не будуть оновлені та, навіть якщо вони будуть видалені, вони будуть відновлені на попередню версію. Якщо `.spec.updateStrategy.rollingUpdate.partition` StatefulSet більше, ніж `.spec.replicas`, оновлення `.spec.template` не буде розповсюджуватися на його Podʼи. У більшості випадків вам не знадобиться використовувати розподіл, але вони корисні, якщо ви хочете розгортати оновлення, робити канарейкові розгортання або виконати поетапне впровадження. + +### Максимальна кількість недоступних Podʼів {#maximal-unavailable-pods} + +{{< feature-state for_k8s_version="v1.24" state="alpha" >}} + +Ви можете контролювати максимальну кількість Podʼів, які можуть бути недоступні під час оновлення, вказавши поле `.spec.updateStrategy.rollingUpdate.maxUnavailable`. Значення може бути абсолютним числом (наприклад, `5`) або відсотком від бажаних Podʼів (наприклад, `10%`). Абсолютне число обчислюється з відсоткового значення заокругленням вгору. Це поле не може бути 0. Стандартне значення — 1. + +Це поле застосовується до всіх Podʼів у діапазоні від `0` до `replicas - 1`. Якщо є будь-який недоступний Pod у діапазоні від `0` до `replicas - 1`, він буде враховуватися в `maxUnavailable`. + +{{< note >}} +Поле `maxUnavailable` знаходиться на етапі альфа-тестування і враховується тільки API-серверами, які працюють з увімкненим [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `MaxUnavailableStatefulSet` +{{< /note >}} + +### Примусовий відкат {#forced-rollback} + +При використанні [поступових оновлень](#rolling-updates) зі стандартною [політикою управління Podʼами](#pod-management-policies) (`OrderedReady`), існує можливість потрапити в становище, яке вимагає ручного втручання для виправлення. + +Якщо ви оновлюєте шаблон Podʼа до конфігурації, яка ніколи не стає в стан Running and Ready (наприклад, через поганий бінарний файл або помилку конфігурації на рівні застосунку), StatefulSet припинить розгортання і залишиться у стані очікування. + +У цьому стані недостатньо повернути шаблон Podʼа до справної конфігурації. Через [відомий дефект](https://github.com/kubernetes/kubernetes/issues/67250), StatefulSet продовжуватиме очікувати, доки неробочий Pod стане готовим (що ніколи не відбувається), перед тим як спробувати повернути його до робочої конфігурації. + +Після повернення до шаблону вам також слід видалити будь-які Podʼи, які StatefulSet вже намагався запустити з поганою конфігурацією. Після цього StatefulSet почне перестворювати Podʼи, використовуючи відновлений шаблон. + +## Збереження PersistentVolumeClaim {#persistentvolumeclaim-retention} + +{{< feature-state for_k8s_version="v1.27" state="beta" >}} + +Необовʼязкове поле `.spec.persistentVolumeClaimRetentionPolicy` контролює, чи і як видаляються PVC під час життєвого циклу StatefulSet. Вам потрібно увімкнути [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `StatefulSetAutoDeletePVC` на сервері API та менеджері контролера, щоб використовувати це поле. Після активації ви можете налаштувати дві політики для кожного StatefulSet: + +`whenDeleted` +: налаштовує поведінку зберігання тому, яке застосовується при видаленні StatefulSet + +`whenScaled` +: налаштовує поведінку зберігання тому, яке застосовується при зменшенні кількості реплік у StatefulSet, наприклад, при масштабуванні вниз. + +Для кожної політики, яку ви можете налаштувати, ви можете встановити значення `Delete` або `Retain`. + +`Delete` +: PVC, створені за допомогою `volumeClaimTemplate` StatefulSet, видаляються для кожного Podʼа, який впливає на політику. З політикою `whenDeleted` всі PVC від `volumeClaimTemplate` видаляються після того, як їх Podʼи були видалені. З політикоюю `whenScaled`, лише PVC, що відповідають реплікам Podʼа, які зменшуються видаляються після того, як їх Podʼи були видалені. + +`Retain` (стандартно) +: PVC від `volumeClaimTemplate` не змінюються, коли їх Pod видаляється. Це поведінка до цієї нової функції. + +Звертайте увагу, що ці політики **застосовуються лише** при вилученні Podʼів через видалення або масштабування StatefulSet. Наприклад, якщо Pod, пов'язаний із StatefulSet, зазнає відмови через відмову вузла, і панель управління створює замінний Pod, StatefulSet зберігає поточний PVC. Поточний том не піддається впливу, і кластер прикріплює його до вузла, де має запуститися новий Pod. + +Станадртно для політик встановлено `Retain`, відповідно до поведінки StatefulSet до цієї нової функції. + +Ось приклад політики. + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +... +spec: + persistentVolumeClaimRetentionPolicy: + whenDeleted: Retain + whenScaled: Delete +... +``` + +Контролер StatefulSet додає [посилання на власника](/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications) до своїх PVC, які потім видаляються {{}} після завершення Podʼа. Це дозволяє Podʼу чисто демонтувати всі томи перед видаленням PVC (і перед видаленням PV та обсягу, залежно від політики збереження). Коли ви встановлюєте `whenDeleted` політику `Delete`, посилання власника на екземпляр StatefulSet поміщається на всі PVC, повʼязані із цим StatefulSet. + +Політика `whenScaled` повинна видаляти PVC тільки при зменшенні розміру Podʼа, а не при видаленні Podʼа з іншої причини. Під час узгодження контролер StatefulSet порівнює очікувану кількість реплік із фактичними Podʼами, що присутні на кластері. Будь-який Pod StatefulSet, ідентифікатор якого більший за кількість реплік, засуджується та позначається для видалення. Якщо політика `whenScaled` є `Delete`, засуджені Podʼи спочатку встановлюються власниками для відповідних PVC зразків StatefulSet, перед видаленням Podʼа. Це призводить до того, що PVC видаляються збирачем сміття тільки після видалення таких Podʼів. + +Це означає, що якщо контролер виходить з ладу і перезапускається, жоден Pod не буде видалено до того моменту, поки його посилання на власника не буде відповідно оновлено згідно з політикою. Якщо засуджений Pod видаляється примусово, коли контролер вимкнено, посилання на власника може бути або встановлене, або ні, залежно від того, коли відбулася аварія контролера. Для оновлення посилань на власника може знадобитися кілька циклів врегулювання, тому деякі засуджені Podʼи можуть мати встановлені посилання на власника, а інші — ні. З цієї причини ми рекомендуємо зачекати, поки контролер знову запуститься, що перевірить посилання на власника перед завершенням роботи Podʼів. Якщо це неможливо, оператор повинен перевірити посилання на власника на PVC, щоб забезпечити видалення очікуваних обʼєктів при примусовому видаленні Podʼів. + +### Репліки {#replicas} + +`.spec.replicas` — це необовʼязкове поле, яке вказує кількість бажаних Podʼів. Стандартно воно дорівнює 1. + +Якщо ви масштабуєте Deployment вручну, наприклад, через `kubectl scale statefulset statefulset --replicas=X`, а потім оновлюєте цей StatefulSet на основі маніфесту (наприклад, за допомогою `kubectl apply -f statefulset.yaml`), то застосування цього маніфесту перезапише попереднє ручне масштабування. + +Якщо [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (або будь-який подібний API для горизонтального масштабування) керує масштабуванням StatefulSet, не встановлюйте `.spec.replicas`. Замість цього дозвольте {{}} Kubernetes автоматично керувати полем `.spec.replicas`. + +## {{% heading "whatsnext" %}} + +* Дізнайтеся про [Podʼи](/docs/concepts/workloads/pods). +* Дізнайтеся, як використовувати StatefulSets + * Спробуйте приклад [розгортання stateful застосунків](/docs/tutorials/stateful-application/basic-stateful-set/). + * Спробуйте приклад [розгортання Cassandra з Stateful Sets](/docs/tutorials/stateful-application/cassandra/). + * Спробуйте приклад [запуску реплікованого stateful застосунку](/docs/tasks/run-application/run-replicated-stateful-application/). + * Дізнайтеся, як [масштабувати StatefulSet](/docs/tasks/run-application/scale-stateful-set/). + * Дізнайтеся, що включає в себе [видалення StatefulSet](/docs/tasks/run-application/delete-stateful-set/). + * Дізнайтеся, як [налаштувати Pod для використання тома для зберігання](/docs/tasks/configure-pod-container/configure-volume-storage/). + * Дізнайтеся, як [налаштувати Pod для використання PersistentVolume для зберігання](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). +* `StatefulSet` є ресурсом верхнього рівня в API REST Kubernetes. Ознайомтесь з визначеням обʼєкта {{< api-reference page="workload-resources/stateful-set-v1" >}} для розуміння API. +* Дізнайтеся про [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) та як його можна використовувати для управління доступністю застосунків під час відключень. diff --git a/content/uk/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/uk/docs/concepts/workloads/controllers/ttlafterfinished.md new file mode 100644 index 0000000000000..0b209e0cde5cf --- /dev/null +++ b/content/uk/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -0,0 +1,53 @@ +--- +reviewers: +- janetkuo +title: Автоматичне очищення завершених задач +content_type: concept +weight: 70 +description: >- + Механізм визначення часу життя для автоматичного очищення старих задач, які завершили виконання. +--- + + + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +Коли ваша задача завершилася, корисно залишити цю задачу в API (і не видаляти її відразу), щоб ви могли визначити, чи вдалося, чи не вдалося завдання. + +{{}} Kubernetes часу життя після завершення забезпечує механізм TTL (time to live), щоб обмежити термін життя обʼєктів задачі, які завершили виконання. + + + +## Очищення завершених задач {#cleanup-for-finished-jobs} + +Контролер часу життя після завершення підтримується лише для задач. Ви можете використовувати цей механізм для автоматичного очищення завершених завдань (як `Complete`, так і `Failed`), автоматично вказавши поле `.spec.ttlSecondsAfterFinished` задачі, як у цьому [прикладі](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically). + +Контролер часу життя після завершення передбачає, що задачу можна очистити через TTL секунд після завершення роботи. Відлік починається, коли умова статусу задачі змінюється, щоб показати, що задача є або `Complete`, або `Failed`; як тільки TTL закінчився, ця задача стає придатною для [каскадного](/docs/concepts/architecture/garbage-collection/#cascading-deletion) видалення. Коли контролер часу життя після завершення очищає задачу, він видалить її каскадно, іншими словами, він видалить її залежні обʼєкти разом з нею. + +Kubernetes дотримується гарантій життєвого циклу обʼєкта для задачі, таких як очікування [завершувачів](/docs/concepts/overview/working-with-objects/finalizers/). + +Ви можете встановити TTL секунд у будь-який момент. Ось деякі приклади встановлення поля `.spec.ttlSecondsAfterFinished` задачі: + +* Вказуйте це поле в маніфесті задачі, щоб задачу можна було автоматично очистити через певний час після її завершення. +* Вручну встановлюйте це поле вже наявним завершеним завданням, щоб вони стали придатними для очищення. +* Використовуйте [змінний вебхук доступу](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) для динамічного встановлення цього поля під час створення задачі. Адміністратори кластера можуть використовувати це, щоб накладати політику TTL для завершених задач. +* Використовуйте [змінний вебхук доступу](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) для динамічного встановлення цього поля після завершення задачі та вибору різних значень TTL на основі статусу завдання, міток. У цьому випадку вебзапит повинен виявляти зміни в полі `.status` задачі та встановлювати TTL лише тоді, коли задача позначається як завершена. +* Напишіть свій власний контролер для управління часом життя TTL для задач, які відповідають певному {{< glossary_tooltip term_id="selector" text="селектору" >}}. + +## Обмеження {#coveats} + +### Оновлення TTL для завершених задач {#updating-ttl-for-finished-jobs} + +Ви можете змінювати період TTL, наприклад, поле `.spec.ttlSecondsAfterFinished` для задач, після створення або завершення задачі. Якщо ви збільшуєте період TTL після закінчення поточного періоду `ttlSecondsAfterFinished`, Kubernetes не гарантує збереження цієї задачі, навіть якщо оновлення для збільшення TTL повертає успішну API відповідь. + +### Зсув часу {#time-skew} + +Оскільки контролер часу життя після завершення використовує відмітки часу, збережені в задачах Kubernetes, для визначення того, чи TTL минув, чи ні, ця функція чутлива до зсуву часу в кластері, що може призвести до очищення обʼєктів задачі в неправильний час. + +Годинники не завжди вірні, але різниця повинна бути дуже мала. Будь ласка, будьте уважні при встановленні ненульового TTL. + +## {{% heading "whatsnext" %}} + +* Прочитайте [Автоматичне очищення задач](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) + +* Зверніться до [Пропозиції з покращення Kubernetes](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md) (KEP) для додавання цього механізму. diff --git a/content/uk/docs/concepts/workloads/pods/_index.md b/content/uk/docs/concepts/workloads/pods/_index.md new file mode 100644 index 0000000000000..1f6b74641b2e4 --- /dev/null +++ b/content/uk/docs/concepts/workloads/pods/_index.md @@ -0,0 +1,227 @@ +--- +reviewers: +- erictune +title: Podʼи +content_type: concept +weight: 10 +no_list: true +--- + + + +_Podʼи_ — найменші обчислювальні одиниці, які ви можете створити та керувати ними в Kubernetes. + +_Pod_ (як у випадку з групою китів або гороховим стручком) — це група з одного або кількох {{< glossary_tooltip text="контейнерів" term_id="container" >}}, які мають спільні ресурси зберігання та мережі, а також специфікацію щодо того, як запускати контейнери. Вміст Podʼу завжди розташований та запускається разом, та працює в спільному контексті. Pod моделює "логічний хост" для вашого застосунку: він містить один або кілька контейнерів застосунку, які мають відносно тісний звʼязок один з одним. По за контекстом хмар, застосунки, що виконуються на одному фізичному або віртуальному компʼютері, аналогічні застосункам, що виконуються на одному логічному хості. + +Так само як і контейнери застосунків, Podʼи можуть містити [контейнери ініціалізації](/docs/concepts/workloads/pods/init-containers/), які запускаються під час старту Podʼу. Ви також можете впровадити [тимчасові контейнери](/docs/concepts/workloads/pods/ephemeral-containers/) для налагодження, якщо ваш кластер це підтримує. + + + +## Що таке Pod? {#what-is-a-pod} + +{{< note >}} +Вам потрібно встановити [середовище виконання контейнерів](/docs/setup/production-environment/container-runtimes/) на кожному вузлі кластера, щоб контейнери могли працювати там. +{{< /note >}} + +Спільний контекст Podʼу — це набір Linux-просторів імен, cgroups та, можливо, інших аспектів ізоляції — ті самі речі, які ізолюють {{< glossary_tooltip text="контейнер" term_id="container" >}}. В межах контексту Podʼу окремі застосунки можуть мати додаткові підізоляції. + +Pod схожий на набір контейнерів із спільними просторами імен та спільними ресурсами файлових систем. + +## Використання Podʼів {#using-pods} + +Нижче наведено приклад Pod, який складається з контейнера, який запускає образ `nginx:1.14.2`. + +{{% code_sample file="pods/simple-pod.yaml" %}} + +Для створення Podʼу, показаного вище, виконайте наступну команду: + +```shell +kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml +``` + +Як правило Podʼи не створюються напряму, навіть одиничні Podʼи. Замість цього, створюйте їх за допомогою ресурсів робочих навантажень. Дивіться [Робота з Podʼами](#working-with-pods) для отримання додаткової інформації про те, як Podʼи використовуються разом з ресурсами робочих навантажень. + +### Ресурси навантаження для керування Podʼами {#workload-resources-for-managing-pods} + +Зазвичай у вас немає потреби у створенні окремих Pod напряму в Kubernetes, навіть одиничних Podʼів. Натомість створюйте їх за допомогою ресурсів робочих навантажень, таких як {{< glossary_tooltip text="Deployment" term_id="deployment" >}} або {{< glossary_tooltip text="Job" term_id="job" >}}. Якщо ваші Podʼи потребують відстеження стану, розгляньте використання ресурсу {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}. + +Podʼи в кластері Kubernetes використовуються двома основними способами: + +* **Podʼи, що керують одним контейнером**. Модель "один контейнер на Pod" є найпоширенішим використанням в Kubernetes. У цьому випадку Pod можна розглядати як обгортку навколо одного контейнера; Kubernetes керує Podʼами, а не контейнерами безпосередньо. +* **Podʼи, що керують кількома контейнерами, які мають працювати разом**. Pod може інкапсулювати застосунок, який складається з кількох розміщених разом контейнерів, які тісно повʼязані та мають спільні ресурси. Такі контейнери утворюють єдиний обʼєкт служби — наприклад, один контейнер може надавати дані, що зберігаються в спільному томі, тоді як інший _sidecar_ контейнер може оновлювати ці файли. Pod огортає ці контейнери, спільні ресурси зберігання та тимчасовий ідентифікатор мережі як єдиний обʼєкт. + + {{< note >}} + Група кількох контейнерів, розміщених разом в одному Podʼі є відносно складним прикладом. Ви повинні використовувати цей шаблон тільки в конкретних випадках, коли ваші контейнери тісно повʼязані. + {{< /note >}} + +Кожен Pod призначений для запуску одного екземпляра застосунку. Якщо ви хочете масштабувати свій застосунок горизонтально (щоб надати більше ресурсів, запустивши більше екземплярів), вам слід використовувати кілька Podʼів, по одному для кожного екземпляра. У Kubernetes це зазвичай називається _реплікацією_. Репліковані Podʼи створюються та керуються як група ресурсів робочих навантажень разом з їх {{< glossary_tooltip text="контролером" term_id="controller" >}}. + +Ознайомтесь з [Podʼи та контролери](#pods-and-controllers) для отримання додаткової інформації про те, як Kubernetes використовує ресурси робочих навантажень та їх контролери для реалізації масштабування та автоматичного відновлення роботи застосунку. + +### Як Podʼи керують кількома контейнерами {#how-pods-manage-multiple-containers} + +Podʼи спроєктовано для підтримки кількох співпрацюючих процесів (таких як контейнери), які утворюють єдиний обʼєкт служби. Контейнери в Pod автоматично спільно розміщуються та плануються на тому ж фізичному або віртуальному компʼютері в кластері. Контейнери можуть спільно використовувати ресурси та залежності, спілкуватися один з одним та координувати, коли та як вони завершують роботу. + +Наприклад, у вас може бути контейнер, який виконує функції вебсервера для файлів у спільному томі, та окремий "sidecar" контейнер, який оновлює ці файли з віддаленого джерела, як показано на наступній діаграмі: + +{{< figure src="/images/docs/pod.svg" alt="Діаграма створення Podʼу" class="diagram-medium" >}} + +Деякі Podʼи мають {{< glossary_tooltip text="контейнери ініціалізації" term_id="init-container" >}} та {{< glossary_tooltip text="контейнери застосунку" term_id="app-container" >}}. Типово, контейнери ініціалізації запускаються та завершують роботу перед тим, як почнуть працювати контейнери застосунку. + +{{< feature-state for_k8s_version="v1.29" state="beta" >}} + +Типово увімкнено, функція `SidecarContainers` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) дозволяє вам вказати `restartPolicy: Always` для контейнерів ініціалізації. Встановлення політики перезапуску `Always` гарантує, що контейнери ініціалізації, де ви встановили це, будуть працювати протягом усього життєвого циклу Pod. Дивіться [Контейнери sidecar та restartPolicy](/docs/concepts/workloads/pods/init-containers/#sidecar-containers-and-restartpolicy) для отримання додаткової інформації. + +Podʼи можуть надавати два види спільних ресурсів для своїх підпорядкованих контейнерів: [мережу](#pod-networking) та [зберігання](#pod-storage). + +## Робота з Podʼами {#working-with-pods} + +Ви навряд чи створюватимете окремі Pod напряму в Kubernetes, навіть одиничні Podʼи. Це тому, що Podʼи спроєктовано бути відносно ефемерними, одноразовими обʼєктами, які можуть бути втрачені в будь-який момент. Коли Pod створено (чи це зроблено вами, чи це зроблено автоматично за допомогою {{< glossary_tooltip text="контролера" term_id="controller" >}}), новий Pod планується на виконання на {{< glossary_tooltip text="вузлі" term_id="node" >}} вашого кластера. Pod залишається на цьому вузлі до тих пір, поки він не завершить роботу, обʼєкт Pod видалено, Pod _виселено_ за відсутності ресурсів, або вузол зазнав збою. + +{{< note >}} +Перезапуск контейнера в Pod не слід плутати з перезапуском Podʼу. Pod — це не процес, а середовище для запуску контейнера(ів). Pod існує до тих пір, поки його не видалено. +{{< /note >}} + +Назва Podʼу має бути дійсним [DNS-піддоменом](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names), але це може призвести до неочікуваних результатів для імені хоста Podʼу. Для найкращої сумісності, імʼя має відповідати більш обмеженим правилам для [DNS-мітки](/docs/concepts/overview/working-with-objects/names#dns-label-names). + +### Операційна система Podʼу {#pod-os} + +{{< feature-state state="stable" for_k8s_version="v1.25" >}} + +Ви маєте вказати значення поля `.spec.os.name` як `linux` або `windows`, щоб вказати ОС, на якій ви хочете запустити Pod. Ці дві ОС підтримуються Kubernetes. У майбутньому цей список може бути розширений. + +В Kubernetes v{{< skew currentVersion >}}, значення, яке ви встановлюєте для цього поля, не впливає на {{< glossary_tooltip text="планування" term_id="kube-scheduler" >}} Podʼів. Встановлення `.spec.os.name` допомагає однозначно ідентифікувати ОС Podʼу та використовувати його для валідації. {{< glossary_tooltip text="Kubelet" term_id="kubelet" >}} відмовляється запускати Pod, де ви вказали ОС Pod, якщо вона не збігається з операційною системою вузла, на якому працює цей kubelet. +[Стандарти безпеки Pod](/docs/concepts/security/pod-security-standards/) також використовують це поле, щоб уникнути застосування політик, які не є відповідними для цієї операційної системи. + +### Podʼи та контролери {#pods-and-controllers} + +Ви можете використовувати ресурси робочих навантажень для створення та керування Podʼами. Контролери ресурсів опікуються реплікацією та розгортанням Podʼів, а також автоматичним відновленням роботи застосунку в разі відмови. Наприклад, якщо Node впав, контролер помітить, що Pod на цьому вузлі перестав працювати, він створить заміну Podʼу. Планувальник поміщає Pod заміну до нового працездатного вузла. + +Ось кілька прикладів ресурсів робочих наватнажень, які керують одним чи більше Podʼами: + +* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} + +### Pod templates + +Контролери ресурсів {{< glossary_tooltip text="робочих навантажень" term_id="workload" >}} створюють Pod з _pod template_ та керують цими Podʼом від вашого імені. + +PodTemplate — це специфікація для створення Pod, і вона включена в ресурси робочих навантажень, такі як [Deployment](/docs/concepts/workloads/controllers/deployment/), [Job](/docs/concepts/workloads/controllers/job/) та [DaemonSet](/docs/concepts/workloads/controllers/daemonset/). + +Кожен контролер ресурсів робочих навантажень використовує `PodTemplate` всередині обʼєкта робочого навантаження для створення фактичних Podʼів. `PodTemplate` є частиною бажаного стану будь-якого ресурсу робочого навантаження, який ви використовуєте для запуску вашого застосунку. + +Приклад нижче — це маніфест простого Job з `template`, який запускає один контейнер. Контейнер в цьому Podʼі виводить повідомлення, а потім призупиняється. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: hello +spec: + template: + # Це шаблон Podʼу + spec: + containers: + - name: hello + image: busybox:1.28 + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # Кінець щаблону Podʼу +``` + +Зміна template або перемикання на новий template не має прямого впливу на Podʼи, які вже існують. Якщо ви змінюєте template Podʼу для ресурсу робочого навантаження, цей ресурс має створити Pod заміну, який використовує оновлений template. + +Наприклад, контролер StatefulSet переконується, що запущені Pod відповідають поточному template для кожного обʼєкта StatefulSet. Якщо ви редагуєте StatefulSet, щоб змінити його template, StatefulSet починає створювати нові Pod на основі оновленого template. З часом всі старі Pod замінюються новими і оновлення завершується. + +Кожен ресурс робочого навантаження реалізує власні правила для обробки змін у template Podʼу. Якщо ви хочете дізнатися більше про StatefulSet, прочитайте [Стратегія оновлення](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) в посібнику StatefulSet Basics. + +На вузлах {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} безпосередньо не спостерігає або керує жодними деталями щодо template Podʼу та оновлень; ці деталі абстраговані. Ця абстракція та розділення відповідальностей спрощує семантику системи та робить можливим розширення поведінки кластера без зміни наявного коду. + +## Оновлення та заміна Podʼів {#pod-update-and-replacement} + +Як зазначено в попередньому розділі, коли template Podʼу для ресурсу робочого навантаження змінюється, контролер створює нові Podʼи на основі оновленого template замість оновлення або латання наявних Podʼів. + +Kubernetes не забороняє вам керувати Pod напряму. Ви можете оновлювати деякі поля запущеного Pod, на місці. Однак операції оновлення Pod, такі як [`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) та [`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core), мають деякі обмеження: + +* Більшість метаданих про Pod є незмінними. Наприклад, ви не можете змінити поля `namespace`, `name`, `uid` або `creationTimestamp`; поле `generation` є унікальним. Воно приймає лише оновлення, які збільшують поточне значення поля. +* Якщо `metadata.deletionTimestamp` встановлено, новий запис не може бути доданий до списку `metadata.finalizers`. +* Оновлення Pod може не змінювати поля, крім `spec.containers[*].image`, `spec.initContainers[*].image`, `spec.activeDeadlineSeconds` або `spec.tolerations`. Для `spec.tolerations` ви можете додавати лише нові записи. +* Коли ви оновлюєте `spec.activeDeadlineSeconds`, дозволені два типи оновлень: + 1. встановлення непризначеному полю позитивного числа; + 2. оновлення поля з позитивного числа на менше, невідʼємне число. + +## Спільні ресурси та комунікація {#resource-sharing-and-communication} + +Podʼи дозволяють контейнерам спільно використовувати ресурси та спілкуватися один з одним. + +### Збереження в Podʼах {#pod-storage} + +Кожен Pod може вказати набір спільних {{< glossary_tooltip text="ресурсів зберігання" term_id="volume" >}}. Всі контейнери в Pod можуть отримати доступ до спільних томів, що дозволяє цим контейнерам спільно використовувати дані. Також томи дозволяють постійним даним в Pod вижити в разі перезапуску одного з контейнерів. Дивіться [Зберігання](/docs/concepts/storage/) для отримання додаткової інформації про те, як Kubernetes реалізує спільне зберігання та робить його доступним для Podʼів. + +### Мережі та Pod {#pod-networking} + +Кожен Pod отримує власну унікальну IP-адресу для кожного сімейства адрес. Кожен контейнер в Pod використовує спільний простір імен мережі, включаючи IP-адресу та мережеві порти. В межах Pod (і **тільки** там) контейнери, які належать до Pod, можуть спілкуватися один з одним, використовуючи `localhost`. Коли контейнери в Pod спілкуються з іншими обʼєктами _по за Podʼом_, вони повинні координуватись, як вони використовують спільні мережеві ресурси (такі як порти). В межах Pod контейнери спільно використовують IP-адресу та порти, і можуть знаходити один одного через `localhost`. Контейнери в різних Podʼах мають власні IP-адреси та не можуть спілкуватися за допомогою міжпроцесового звʼязку ОС без спеціальної конфігурації. Контейнери, які хочуть взаємодіяти з контейнером, що працює в іншому Pod, можуть використовувати IP-мережу для комунікації. + +Контейнери в Pod бачать системне імʼя хоста таким самим, як і вказане `name` для Pod. Більше про це ви можете прочитати в розділі [мережі](/docs/concepts/cluster-administration/networking/). + +## Привілейований режим контейнерів {#privileged-mode-for-containers} + +{{< feature-state for_k8s_version="v1.26" state="stable" >}} + +{{< note >}} +Ваше {{< glossary_tooltip text="середовище виконання контейнерів" term_id="container-runtime" >}} повинно підтримувати концепцію привілейованих контейнерів, щоб цей параметр був релевантним. +{{< /note >}} + +Будь-який контейнер в Pod може працювати в привілейованому режимі, щоб використовувати адміністративні можливості операційної системи, які інакше були б недоступні. Це доступно як для Windows, так і для Linux. + +### Привілейовані контейнери Linux {#linux-privileged-containers} + +В Linux будь-який контейнер в Pod може ввімкнути привілейований режим, використовуючи прапорець `privileged` (Linux) в [контексті безпеки](/docs/tasks/configure-pod-container/security-context/) специфікації контейнера. Це корисно для контейнерів, які хочуть використовувати адміністративні можливості операційної системи, такі як маніпулювання мережевим стеком або доступ до апаратних пристроїв. + +### Привілейовані контейнери Windows {#windows-privileged-containers} + +{{< feature-state for_k8s_version="v1.26" state="stable" >}} + +У Windows ви можете створити [Windows HostProcess pod](/docs/tasks/configure-pod-container/create-hostprocess-pod), встановивши прапорець `windowsOptions.hostProcess` в контексті безпеки специфікації Pod. Всі контейнери в цих Pod повинні працювати як контейнери Windows HostProcess. HostProcess Pod працюють безпосередньо на хості та також можуть використовуватися для виконання адміністративних завдань, як це робиться з Linux привілейованими контейнерами. + +## Статичні Podʼи {#static-pods} + +{{< feature-state for_k8s_version="v1.22" state="stable" >}} + +_Static Pods_ керуються безпосередньо демоном kubelet на конкретному вузлі, без спостереження з боку {{< glossary_tooltip text="сервера API" term_id="kube-apiserver" >}}. У той час як більшість Podʼів керуються панеллю управління (наприклад, {{< glossary_tooltip text="Deployment" term_id="deployment" >}}), для статичних Podʼів kubelet безпосередньо наглядає за кожним статичним Pod (та перезапускає його, якщо він падає). + +Статичні Podʼи завжди привʼязані до одного {{< glossary_tooltip term_id="kubelet" text="Kubeletʼу" >}} на конкретному вузлі. Основне використання статичних Podʼів — це запуск самостійної панелі управління: іншими словами, використання kubelet для нагляду за окремими [компонентами панелі управління](/docs/concepts/overview/components/#control-plane-components). + +Kublet автоматично намагається створити {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}} на сервері API Kubernetes для кожного статичного Pod. Це означає, що Pod, які працюють на вузлі, видно на сервері API, але ними не можна керувати звідти. Дивіться [Створення статичних Podʼів](/docs/tasks/configure-pod-container/static-pod) для отримання додаткової інформації. + +{{< note >}} +Розділ `spec` статичного Pod не може посилатися на інші API-обʼєкти (наприклад, {{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}, {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, {{< glossary_tooltip text="Secret" term_id="secret" >}} тощо). +{{< /note >}} + +## Перевірки контейнерів {#container-probes} + +_Probe_ — це діагностика, яку періодично виконує kubelet на контейнері. Для виконання діагностики kubelet може використовувати різні дії: + +* `ExecAction` (виконується за допомогою процесу виконання контейнера) +* `TCPSocketAction` (перевіряється безпосередньо the kubelet) +* `HTTPGetAction` (перевіряється безпосередньо kubelet) + +Ви можете дізнатися більше про [перевірки](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) в документації про життєвий цикл Podʼів + +## {{% heading "whatsnext" %}} + +* Дізнайтесь про [життєвий цикл Podʼів](/docs/concepts/workloads/pods/pod-lifecycle/). +* Дізнайтесь про [RuntimeClass](/docs/concepts/containers/runtime-class/) та як ви можете використовувати його для налаштування різних Pod з різними конфігураціями середовища виконання контейнера. +* Дізнайтесь про [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) та як ви можете використовувати його для керування доступністю застосунку під час збоїв. +* Pod є ресурсом найвищого рівня в Kubernetes REST API. Обʼєкт {{< api-reference page="workload-resources/pod-v1" >}} детально описує його. +* [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) пояснює загальні макети для Pod з більш ніж одним контейнером. +* Дізнайтесь про [Топологію обмежень розподілу Podʼів](/docs/concepts/scheduling-eviction/topology-spread-constraints/) + +Для розуміння контексту того, чому Kubernetes обгортає загальний API Pod іншими ресурсами (такими як {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} або {{< glossary_tooltip text="Deployments" term_id="deployment" >}}), ви можете прочитати про попередні роботи, включаючи: + +* [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) +* [Borg](https://research.google.com/pubs/pub43438.html) +* [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) +* [Omega](https://research.google/pubs/pub41684/) +* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). diff --git a/content/uk/docs/concepts/workloads/pods/disruptions.md b/content/uk/docs/concepts/workloads/pods/disruptions.md new file mode 100644 index 0000000000000..28daa5ed957b5 --- /dev/null +++ b/content/uk/docs/concepts/workloads/pods/disruptions.md @@ -0,0 +1,223 @@ +--- +reviewers: +- erictune +- foxish +- davidopp +title: Розлади +content_type: concept +weight: 70 +--- + + +Цей посібник призначений для власників pfcnjceyrsd, які хочуть створити високодоступні застосунки та, таким чином, повинні розуміти, які типи розладів можуть трапитися з Podʼами. + +Також це стосується адміністраторів кластера, які хочуть виконувати автоматизовані дії з кластером, такі як оновлення та автомасштабування кластерів. + + + +## Добровільні та невідворотні розлади {#voluntary-and-involuntary-disruptions} + +Podʼи не зникають, поки хтось (людина або контролер) не знищить їх, або не трапиться невідворотня помилка обладнання чи системного програмного забезпечення. + +Ми називаємо ці невідворотні випадки *невідворотніми розладами* застосунку. Приклади: + +- відмова обладнання фізичної машини, яка підтримує вузол +- адміністратор кластера видаляє віртуальну машину (екземпляр) помилково +- відмова хмарного провайдера або гіпервізора призводить до зникнення віртуальної машини +- kernel panic +- вузол зникає з кластера через поділ мережі кластера +- витіснення Podʼу через [вичерпання ресурсів](/docs/concepts/scheduling-eviction/node-pressure-eviction/) вузла. + +Крім умов, повʼязаних із вичерпанням ресурсів, всі ці умови повинні бути знайомими більшості користувачів; вони не є специфічними для Kubernetes. + +Ми називаємо інші випадки *добровільними розладами*. До них належать як дії, ініційовані власником застосунку, так і ті, які ініціює адміністратор кластера. Типові дії власника застосунку включають: + +- видалення розгортання або іншого контролера, який управляє Podʼом +- оновлення шаблону розгортання Podʼа, що призводить до перезапуску +- безпосереднє видалення Podʼу (наприклад, випадково) + +Дії адміністратора кластера включають: + +- [Вивільнення вузла](/docs/tasks/administer-cluster/safely-drain-node/) для ремонту чи оновлення. +- Відведення вузла з кластера для зменшення масштабу кластера (дізнайтеся більше про [автомасштабування кластера](https://github.com/kubernetes/autoscaler/#readme)). +- Видалення Podʼа з вузла, щоб щось інше помістилося на цей вузол. + +Ці дії можуть бути виконані безпосередньо адміністратором кластера чи за допомогою автоматизації, запущеної адміністратором кластера, або вашим провайдером хостингу кластера. + +Зверніться до адміністратора кластера або проконсультуйтеся з документацією вашого хмарного провайдера або дистрибутиву, щоб визначити, чи увімкнено які-небудь джерела добровільних розладів для вашого кластера. Якщо жодне з них не увімкнено, ви можете пропустити створення бюджетів розладів Podʼів (Pod Disruption Budget). + +{{< caution >}} +Не всі добровільні розлади обмежені бюджетами розладів Podʼів. Наприклад, видалення Deployment чи Pod обходить бюджети розладів Podʼів. +{{< /caution >}} + +## Управління розладами {#dealing-with-disruptions} + +Ось кілька способів помʼякшення невідворотних розладів: + +- Переконайтеся, що ваш Pod [звератється по необхідні ресурси](/docs/tasks/configure-pod-container/assign-memory-resource). +- Реплікуйте своє застосунки, якщо вам потрібна вища доступність. (Дізнайтеся про запуск реплікованих [stateless](/docs/tasks/run-application/run-stateless-application-deployment/) та [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) застосунків.) +- Для ще більшої доступності при запуску реплікованих застосунків розподіліть їх по стійках (за допомогою [anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)) чи по зонах (якщо використовуєте + [кластер з кількома зонами](/docs/setup/multiple-zones).) + +Частота добровільних розладів різниться. На базовому кластері Kubernetes немає автоматизованих добровільних розладів (тільки ті, які ініціює користувач). Однак адміністратор кластера або постачальник хостингу може запускати деякі додаткові служби, які призводять до добровільних розладів. Наприклад, розгортання оновлень програмного забезпечення вузла може призвести до добровільних розладів. Також деякі реалізації автомасштабування кластера (вузла) можуть призводити до добровільних розладів для дефрагментації та ущільнення вузлів. Адміністратор кластера або постачальник хостингу повинні документувати, на якому рівні добровільних розладів, якщо такі є, можна розраховувати. +Деякі параметри конфігурації, такі як [використання PriorityClasses](/docs/concepts/scheduling-eviction/pod-priority-preemption/) у вашій специфікації Podʼу, також можуть призводити до добровільних (і невідворотних) розладів. + +## Бюджет розладів Podʼів {#pod-disruption-budgets} + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + +Kubernetes пропонує функції, що допомагають запускати застосунки з високою доступністю навіть тоді, коли ви вводите часті добровільні розлади. + +Як власник застосунку, ви можете створити Бюджет розладів Podʼів (PodDisruptionBudget або PDB) для кожного застосунку. PDB обмежує кількість Podʼів, які можуть бути одночасно вимкнені через добровільні розлади для реплікованого застосунку. Наприклад, застосунок, який працює на основі кворуму, хоче забезпечити, що кількість реплік ніколи не знизиться нижче необхідної для кворуму. Вебінтерфейс, наприклад, може бажати забезпечити, що кількість реплік, які обслуговують навантаження, ніколи не падатиме нижче певного відсотка від загальної кількості. + +Менеджери кластерів та постачальники хостингу повинні використовувати інструменти, які дотримуються бюджетів розладів Podʼів, викликаючи [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) замість прямого видалення Podʼу або Deployment. + +Наприклад, команда `kubectl drain` дозволяє вам позначити вузол, як виводиться з експлуатації. Коли ви виконуєте `kubectl drain`, інструмент намагається витіснити всі Podʼи з вузла, який ви виводите з експлуатації. Запит на виведення, який `kubectl` робить від вашого імені, може тимчасово бути відхилено, тому інструмент періодично повторює всі невдалі запити, поки всі Podʼи на цільовому вузлі не будуть завершені, або досягне вказаного тайм-ауту. + +PDB визначає кількість реплік, які застосунок може терпіти, порівняно з тим, скільки він має намір мати. Наприклад, Deployment, який має `.spec.replicas: 5`, повинен мати 5 Podʼів в будь-який момент часу. Якщо PDB дозволяє бути 4 Podʼам одночасно, то API виведення дозволить добровільне відключення одного (але не двох) Podʼів одночасно. + +Група Podʼів, з яких складається застосунок, визначається за допомогою селектора міток, такого самого, як і той, який використовується контролером застосунку (deployment, stateful-set і т. д.). + +"Очікувана" кількість Podʼів обчислюється з `.spec.replicas` ресурсу робочого навантаження (Workload), який управляє цими Podʼами. Панель управління визначає ресурс робочого навантаження, оглядаючи `.metadata.ownerReferences` Podʼа. + +[Невідворотні розлади](#voluntary-and-involuntary-disruptions) не можуть бути усунуті за допомогою PDB; однак вони враховуються в бюджеті. + +Podʼи, які видаляються або недоступні через поетапне оновлення застосунку, дійсно враховуються в бюджеті розладів, але ресурси робочого навантаження (такі як Deployment і StatefulSet) не обмежуються PDB під час поетапного оновлення. Замість цього обробка невдач під час оновлення застосунку конфігурується в специфікації конкретного ресурсу робочого навантаження. + +Рекомендується встановлювати [політику витиснення](/docs/tasks/run-application/configure-pdb/#unhealthy-pod-eviction-policy) `AlwaysAllow` у ваших бюджетах розладів podʼів для підтримки виведення неправильно працюючих застосунків під час виведення вузла. Стандартна поведінка полягає в тому, що очікується, коли Podʼи застосунку стануть [справними](/docs/tasks/run-application/configure-pdb/#healthiness-of-a-pod) перед тим, як виведення може продовжитися. + +Коли Pod виводиться за допомогою API витиснення, він [завершується](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) відповідним чином, з урахуванням налаштувань `terminationGracePeriodSeconds` у його [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). + +## Приклад бюджету розладів поди {#pdb-example} + +Припустимо, що у кластері є 3 вузли: `node-1` до `node-3`. +Кластер виконує кілька застосунків. Один з них має 3 репліки, які спочатку називаються `pod-a`, `pod-b` і `pod-c`. Інший, неповʼязаний з ними Pod без PDB, називається `pod-x`. Спочатку Podʼи розташовані наступним чином: + +| node-1 | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| pod-a *доступний* | pod-b *доступний* | pod-c *доступний* | +| pod-x *доступний* | | | + +Усі 3 Podʼи є частиною Deployment, і вони разом мають PDB, який вимагає, щоб одночасно було доступними принаймні 2 з 3 Podʼів. + +Наприклад, припустимо, що адміністратор кластера хоче запровадити нову версію ядра ОС, щоб виправити помилку в ядрі. Адміністратор кластера спочатку намагається вивести з експлуатації `node-1` за допомогою команди `kubectl drain`. Цей інструмент намагається витіснити `pod-a` і `pod-x`. Це відбувається миттєво. Обидві Podʼа одночасно переходять в стан `terminating`. Це переводить кластер у стан: + +| node-1 *виведений* | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| pod-a *виводиться* | pod-b *доступний* | pod-c *доступний* | +| pod-x *виводиться* | | | + +Deployment помічає, що один з Podʼів виводиться, тому він створює заміну під назвою `pod-d`. Оскільки `node-1` закритий, він опиняється на іншому вузлі. Також, щось створило `pod-y` як заміну для `pod-x`. + +(Примітка: для StatefulSet, `pod-a`, який міг би мати назву щось на зразок `pod-0`, повинен був би повністю завершити свою роботу, +перш ніж його заміна, яка також має назву `pod-0`, але має інший UID, може бути створений. В іншому випадку приклад застосовується і до StatefulSet.) + +Тепер кластер перебуває у такому стані: + +| node-1 *виведений* | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| pod-a *виводиться* | pod-b *доступний* | pod-c *доступний* | +| pod-x *виводиться* | pod-d *запускається* | pod-y | + +У якийсь момент Podʼи завершують свою роботу, і кластер виглядає так: + +| node-1 *виведений* | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| | pod-b *доступний* | pod-c *доступний* | +| | pod-d *доступний* | pod-y | + +На цьому етапі, якщо нетерплячий адміністратор кластера намагається вивести з експлуатації `node-2` або `node-3`, команда виведення буде блокуватися, оскільки доступно тільки 2 Podʼи для Deployment, і його PDB вимагає принаймні 2. Після того, як пройде певний час, `pod-d` стає доступним. + +Тепер стан кластера виглядає так: + +| node-1 *виведений* | node-2 | node-3 | +|:--------------------:|:-------------------:|:------------------:| +| | pod-b *доступний* | pod-c *доступний* | +| | pod-d *доступний* | pod-y | + +Тепер адміністратор кластера намагається вивести з експлуатації `node-2`. Команда виведення спробує витіснити два Podʼи у деякому порядку, скажімо, спочатку `pod-b`, а потім `pod-d`. Їй вдасться витіснити `pod-b`. Але, коли вона спробує витіснити `pod-d`, отримає відмову через те, що це залишить тільки один доступний Pod для Deployment. + +Deployment створює заміну для `pod-b` з назвою `pod-e`. Оскільки в кластері недостатньо ресурсів для планування `pod-e`, виведення знову буде заблоковано. Кластер може опинитися в такому +стані: + +| node-1 *виведений* | node-2 | node-3 | *немає вузла* | +|:--------------------:|:-------------------:|:------------------:|:------------------:| +| | pod-b *виводиться* | pod-c *доступний* | pod-e *очікується* | +| | pod-d *доступний* | pod-y | | + +На цьому етапі адміністратор кластера повинен додати вузол назад до кластера, щоб продовжити оновлення. + +Ви можете побачити, як Kubernetes змінює частоту випадків розладів відповідно до: + +- скільки реплік потрібно для застосунку +- скільки часу потрібно для відповідного вимикання екземпляра +- скільки часу потрібно для запуску нового екземпляра +- типу контролера +- ресурсів кластера + +## Умови розладу поду {#pod-disruption-conditions} + +{{< feature-state for_k8s_version="v1.26" state="beta" >}} + +{{< note >}} +Для використання цієї функціональності слід увімкнути [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodDisruptionConditions` у вашому кластері. +{{< /note >}} + +При увімкненні цієї функціональності для Podʼу додається окрема умова `DisruptionTarget` [condition](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions), яка вказує, що Pod має бути видалений через {{}}. Поле `reason` умови додатково вказує на одну з наступних причин завершення роботи Podʼу: + +`PreemptionByScheduler` +: Pod має бути {{}} планувальником для надання місця новому Podʼу з вищим пріоритетом. Докладніше дивіться [Витіснення за пріоритетом Podʼу](/docs/concepts/scheduling-eviction/pod-priority-preemption/). + +`DeletionByTaintManager` +: Pod має бути видалений Менеджером Taint (який є частиною контролера життєвого циклу вузла в `kube-controller-manager`) через `NoExecute` taint, який Pod не толерує; див. витіснення на основі {{}}. + +`EvictionByEvictionAPI` +: Pod був позначений для {{}}. + +`DeletionByPodGC` +: Pod, який повʼязаний із вузлом, якого вже не існує, має бути видалений за допомогою [збирання сміття Podʼів](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection). + +`TerminationByKubelet` +: Pod був завершений kubelet, через витіснення з вузла через {{}} або [відповідне вимикання вузла](/docs/concepts/architecture/nodes/#graceful-node-shutdown). + +{{< note >}} +Розлад Podʼу може бути перерваний. Панель управління може повторно намагатися продовжити розлад того ж Podʼу, але це не гарантується. У результаті умова `DisruptionTarget` може бути додана до Podʼу, але цей Pod може фактично не бути видалений. У такій ситуації після певного часу умова розладу Pod буде видалена. +{{< /note >}} + +При увімкненні функціональності `PodDisruptionConditions` разом із видаленням Podʼів, збирач сміття подів (PodGC) також відзначатиме їх як неуспішні, якщо вони знаходяться в не фазі завершення роботи (див. також [Збирання сміття Podʼів](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)). + +При використанні Job (або CronJob) вам може знадобитися використовувати ці умови розладу Podʼу як частину політики невдачі вашого Job [Політики невдачі Podʼу](/docs/concepts/workloads/controllers/job#pod-failure-policy). + +## Розділення ролей власника кластера та власника застосунку {#Separating-cluster-owner-and-application-owner-roles} + +Часто корисно розглядати Менеджера кластера і Власника застосунку як окремі ролі з обмеженим знанням одне про одного. Це розділення обовʼязків може мати сенс у таких сценаріях: + +- коли багато команд розробки застосунків використовують спільний кластер Kubernetes і є природна спеціалізація ролей +- коли використовуються інструменти або сервіси сторонніх розробників для автоматизації управління кластером + +Бюджети розладу Podʼів підтримують це розділення ролей, надаючи +інтерфейс між цими ролями. + +Якщо у вашій організації немає такого розділення обовʼязків, +вам може не знадобитися використовувати бюджети розладу Podʼів. + +## Як виконати дії з розладу у вашому кластері {#how-to-perform-disruptive-actions-on-your-cluster} + +Якщо ви є адміністратором кластера і вам потрібно виконати дію розладу на всіх вузлах вашого кластера, таку як оновлення вузла чи системного програмного забезпечення, ось кілька варіантів: + +- Примиритись з періодом простою під час оновлення. +- Перемикнутися на іншу повну репліку кластера. + - Відсутність простою, але може бути дорогою як для дубльованих вузлів, так і для зусиль людей для оркестрування перемикання. +- Розробляти застосунки, що терплять розлади, і використовувати бюджети розладу Podʼів. + - Відсутність простою. + - Мінімальне дублювання ресурсів. + - Дозволяє більше автоматизації адміністрування кластера. + - Написання застосунків, що терплять розлади, складне, але робота з підтримкою добровільних розладів в основному збігається з роботою з підтримкою автомасштабування і толеруючи інші типи рощладів розлади. + +## {{% heading "whatsnext" %}} + +- Слідкуйте за кроками для захисту вашого застосунку, [налаштовуючи бюджет розладу Podʼів](/docs/tasks/run-application/configure-pdb/). + +- Дізнайтеся більше про [виведення вузлів з експлуатації](/docs/tasks/administer-cluster/safely-drain-node/). + +- Дізнайтеся про [оновлення Deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment), включаючи кроки забезпечення його доступності під час впровадження. diff --git a/content/uk/docs/concepts/workloads/pods/downward-api.md b/content/uk/docs/concepts/workloads/pods/downward-api.md new file mode 100644 index 0000000000000..50debe6f9d535 --- /dev/null +++ b/content/uk/docs/concepts/workloads/pods/downward-api.md @@ -0,0 +1,115 @@ +--- +title: Downward API +content_type: concept +weight: 170 +description: "Є два способи використання полів обʼєкта Pod та контейнера у працюючому контейнері: як змінні середовища та як файли, які заповнюються спеціальним типом тома. Разом ці два способи використання полів об'єкта Pod та контейнера називають Downward API." +--- + + + +Іноді корисно, щоб контейнер мав інформацію про себе, не будучи занадто повʼязаним із Kubernetes. _downward API_ дозволяє контейнерам використовувати інформацію про себе чи кластер, не використовуючи клієнт Kubernetes або API-сервер. + +Наприклад, поточний застосунок, який передбачає, що відома змінна середовища містить унікальний ідентифікатор. Однією з можливостей є обгортання застосунку, але це нудно та помилкове, і воно суперечить меті вільного звʼязку. Кращий варіант — використовувати імʼя Podʼу як ідентифікатор та впровадити імʼя Podʼу у відому змінну середовища. + +В Kubernetes існують два способи використання полів обʼєкта Pod та контейнера: + +* як [змінні середовища](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) +* як [файли в томі `downwardAPI`](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) + +Разом ці два способи використання полів обʼєкта Pod та контейнера називають _downward API_. + + + +## Доступні поля {#available-fields} + +Через _downward API_ доступні не всі поля обʼєкта Kubernetes API. У цьому розділі перераховано доступні поля. + +Ви можете передавати інформацію з доступних полів рівня Pod, використовуючи `fieldRef`. На рівні API `spec` для Pod завжди визначає принаймні один [Контейнер](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container). Ви можете передавати інформацію з доступних полів рівня Container, використовуючи +`resourceFieldRef`. + +### Інформація, доступна за допомогою `fieldRef` {#downwardapi-fieldRef} + +Для деяких полів рівня Pod ви можете передати їх контейнеру як змінні середовища або використовуючи том `downwardAPI`. Поля, доступні через обидва механізми, наступні: + +`metadata.name` +: імʼя Pod + +`metadata.namespace` +: {{< glossary_tooltip text="namespace" term_id="namespace" >}} Pod + +`metadata.uid` +: унікальний ідентифікатор Pod + +`metadata.annotations['']` +: значення {{< glossary_tooltip text="аннотації" term_id="annotation" >}} Pod з іменем `` (наприклад, `metadata.annotations['myannotation']`) + +`metadata.labels['']` +: текстове значення {{< glossary_tooltip text="мітки" term_id="label" >}} Pod з іменем `` (наприклад, `metadata.labels['mylabel']`) + +Наступна інформація доступна через змінні середовища, **але не як поле `fieldRef` тома `downwardAPI`**: + +`spec.serviceAccountName` +: імʼя {{< glossary_tooltip text="service account" term_id="service-account" >}} Pod + +`spec.nodeName` +: імʼя {{< glossary_tooltip term_id="node" text="вузла">}}, на якому виконується Pod + +`status.hostIP` +: основна IP-адреса вузла, до якого призначено Pod + +`status.hostIPs` +: IP-адреси — це версія подвійного стека `status.hostIP`, перша завжди така сама, як і `status.hostIP`. Поле доступно, якщо увімкнути [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodHostIPs`. + +`status.podIP` +: основна IP-адреса Pod (зазвичай, його IPv4-адреса) + +`status.podIPs` +: IP-адреси — це версія подвійного стека `status.podIP`, перша завжди така сама, як і `status.podIP` + +Наступна інформація доступна через том `downwardAPI` `fieldRef`, **але не як змінні середовища**: + +`metadata.labels` +: всі мітки Pod, в форматі `label-key="escaped-label-value"` з однією міткою на рядок + +`metadata.annotations` +: всі аннотації поду, у форматі `annotation-key="escaped-annotation-value"` з однією аннотацією на рядок + +### Інформація, доступна за допомогою `resourceFieldRef` {#downwardapi-resourceFieldRef} + +Ці поля рівня контейнера дозволяють надавати інформацію про [вимоги та обмеження](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) для ресурсів, таких як CPU та памʼять. + +`resource: limits.cpu` +: Обмеження CPU контейнера + +`resource: requests.cpu` +: Вимога CPU контейнера + +`resource: limits.memory` +: Обмеження памʼяті контейнера + +`resource: requests.memory` +: Вимога памʼяті контейнера + +`resource: limits.hugepages-*` +: Обмеження hugepages контейнера + +`resource: requests.hugepages-*` +: Вимога hugepages контейнера + +`resource: limits.ephemeral-storage` +: Обмеження ефемерних сховищ контейнера + +`resource: requests.ephemeral-storage` +: Вимога ефемерних сховищ контейнера + +#### Резервні інформаційні обмеження для ресурсів {#fallback-information-for-resource-limits} + +Якщо ліміти CPU та памʼяті не вказані для контейнера, і ви використовуєте _downward API_ для спроби викриття цієї інформації, тоді kubelet типово використовує значення для CPU та памʼяті на основі розрахунку [розподілених вузлів](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). + +## {{% heading "whatsnext" %}} + +Ви можете прочитати про [томи `downwardAPI`](/docs/concepts/storage/volumes/#downwardapi). + +Ви можете спробувати використовувати _downward API_ для поширення інформації на рівні контейнера чи Pod: +* як [змінні середовища](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) +* як [файли в томі `downwardAPI`](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) diff --git a/content/uk/docs/concepts/workloads/pods/ephemeral-containers.md b/content/uk/docs/concepts/workloads/pods/ephemeral-containers.md new file mode 100644 index 0000000000000..463283496f48c --- /dev/null +++ b/content/uk/docs/concepts/workloads/pods/ephemeral-containers.md @@ -0,0 +1,49 @@ +--- +reviewers: +- verb +- yujuhong +title: Ефемерні контейнери +content_type: concept +weight: 60 +--- + + + +{{< feature-state state="stable" for_k8s_version="v1.25" >}} + +Ця сторінка надає огляд ефемерних контейнерів: особливого типу контейнера, який працює тимчасово в наявному {{< glossary_tooltip term_id="pod" >}} для виконання дій, ініційованих користувачем, таких як усунення несправностей. Ви можете використовувати ефемерні контейнери для інспектування служб, а не для створення застосунків. + + + +## Розуміння ефемерних контейнерів {#understanding-ephemeral-containers} + +{{< glossary_tooltip text="Podʼи" term_id="pod" >}} є фундаментальним елементом застосунків Kubernetes. Оскільки Podʼи призначені бути одноразовими та замінними, ви не можете додавати контейнер до Podʼа, якщо він вже був створений. Замість цього ви зазвичай видаляєте та замінюєте Podʼи у контрольований спосіб, використовуючи {{< glossary_tooltip text="Deployment" term_id="deployment" >}}. + +Іноді, однак, необхідно оглянути стан наявного Podʼа, наприклад, для усунення несправностей, коли важко відтворити помилку. У цих випадках ви можете запустити ефемерний контейнер в Podʼі, щоб оглянути його стан та виконати певні довільні команди. + +### Що таке ефемерний контейнер? {#what-is-an-ephemeral-container} + +Ефемерні контейнери відрізняються від інших контейнерів тим, що вони не мають гарантій щодо ресурсів або виконання, і їх ніколи автоматично не перезапускають, тому вони не підходять для створення Застосунків. Ефемерні контейнери описуються за допомогою того ж `ContainerSpec`, що й звичайні контейнери, але багато полів +несумісні та заборонені для ефемерних контейнерів. + +- У ефемерних контейнерів не може бути портів, тому такі поля, як `ports`, `livenessProbe`, `readinessProbe`, заборонені. +- Виділення ресурсів для Podʼа незмінне, тому встановлення `resources` заборонене. +- Для повного списку дозволених полів дивіться [документацію по ефемерним контейнерам (EphemeralContainer)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core). + +Ефемерні контейнери створюються за допомогою спеціального обробника `ephemeralcontainers` в API замість того, щоб додавати їх безпосередньо до `pod.spec`, тому не можна додавати ефемерний контейнер за допомогою `kubectl edit`. + +{{< note >}} +Ефемерні контейнери не підтримуються [статичними Podʼами](/docs/tasks/configure-pod-container/static-pod/). +{{< /note >}} + +## Використання ефемерних контейнерів {#uses-for-ephemeral-containers} + +Ефемерні контейнери корисні для інтерактивного усунення несправностей, коли `kubectl exec` недостатній, оскільки контейнер впав або образ контейнера не містить засобів налагодження. + +Зокрема [образи distroless](https://github.com/GoogleContainerTools/distroless) дозволяють вам розгортати мінімальні образи контейнерів, які зменшують площу атаки та вразливість. Оскільки образи distroless не включають оболонку або будь-які засоби налагодження, складно налагоджувати образи distroless, використовуючи лише `kubectl exec`. + +При використанні ефемерних контейнерів корисно включити [спільний простір імен процесу (process namespace sharing)](/docs/tasks/configure-pod-container/share-process-namespace/), щоб ви могли переглядати процеси в інших контейнерах. + +## {{% heading "whatsnext" %}} + +- Дізнайтеся, як [налагоджувати Podʼи за допомогою ефемерних контейнерів](/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container). diff --git a/content/uk/docs/concepts/workloads/pods/init-containers.md b/content/uk/docs/concepts/workloads/pods/init-containers.md new file mode 100644 index 0000000000000..b537333d196cd --- /dev/null +++ b/content/uk/docs/concepts/workloads/pods/init-containers.md @@ -0,0 +1,282 @@ +--- +reviewers: +- erictune +title: Контейнери ініціалізації +content_type: concept +weight: 40 +--- + + +Ця сторінка надає загальний огляд контейнерів ініціалізації: спеціалізованих контейнерів, які запускаються перед запуском контейнерів застосунків в {{< glossary_tooltip text="Podʼі" term_id="pod" >}}. Контейнери ініціалізації можуть містити утиліти або сценарії налаштування, які відсутні в образі застосунка. + +Ви можете вказати контейнери ініціалзації в специфікації Podʼа разом із масивом `containers` (який описує контейнери застосунка). + +У Kubernetes [контейнер sidecar](/docs/concepts/workloads/pods/sidecar-containers/) — це контейнер, який запускається перед основним контейнером застосунку і _продовжує працювати_. Цей документ стосується контейнерів ініціалізації — контейнерів, які завершують свою роботу після ініціалізації Podʼа. + + + +## Контейнери ініціалізації {#understanding-init-containers} + +У {{< glossary_tooltip text="Pod" term_id="pod" >}} може бути кілька контейнерів, які виконують застосунки всередині нього, але також може бути один чи кілька контейнерів ініціалізації, які виконуються до того, як стартують контейнери застосунків. + +Контейнери ініціалізації абсолютно такі ж, як і звичайні контейнери, окрім того: + +* Контейнери ініціалізації завжди завершуються після виконання завдань ініціалізації. +* Кожен контейнер ініціалізації повинен успішно завершити свою роботу, перш ніж почнуть свою роботу наступні. + +Якщо контейнер init Pod виходить з ладу, kubelet неодноразово перезапускає цей контейнер, поки він не досягне успіху. Однак якщо у Pod встановлено `restartPolicy` рівне Never, і контейнер ініціалізації виходить з ладу під час запуску Pod, Kubernetes розглядає весь Pod як неуспішний. + +Для зазначення контейнера ініціалізації для Pod додайте поле `initContainers` у [специфікацію Podʼа](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec), у вигляді масиву обʼєктів `container` (аналогічно полю `containers` контейнерів застосунку і їх змісту). Дивіться [Container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) в +довідці API для отримання докладнішої інформації. + +Стан контейнерів внвціалізації повертається у полі `.status.initContainerStatuses` у вигляді масиву станів контейнерів (аналогічно полю `.status.containerStatuses`). + +### Відмінності від звичайних контейнерів {#differences-from-regular-containers} + +Контейнери ініціалізації підтримують всі поля та можливості контейнерів застосунків, включаючи обмеження ресурсів, [томи](/docs/concepts/storage/volumes/) та налаштування безпеки. Однак +запити та обмеження ресурсів для контейнера ініціалізації обробляються по-іншому, як описано в розділі [Спільне використання ресурсів в межах контейнерів](#resource-sharing-within-containers). + +Звичайні контейнери ініціалізації (іншими словами, виключаючи контейнери sidecar) не підтримують поля `lifecycle`, `livenessProbe`, `readinessProbe` чи `startupProbe`. Контейнери ініціалізації повинні успішно завершити свою роботу перед тим, як Pod може бути готовий; контейнери sidecar продовжують працювати протягом життєвого циклу Podʼа і _підтримують_ деякі проби. Дивіться [контейнер sidecar](/docs/concepts/workloads/pods/sidecar-containers/) для отримання додаткової інформації про nfrs контейнери. + +Якщо ви вказали кілька контейнерів ініціалізації для Podʼа, kubelet виконує кожен такий контейнер послідовно. Кожен контейнер ініціалізації повинен успішно завершити свою роботу, перш ніж може бути запущено наступний. Коли всі контейнери ініціалізації завершать свою роботу, kubelet ініціалізує контейнери застосунків для Podʼа та запускає їх як зазвичай. + +### Відмінності від контейнерів sidecar {#differences-from-sidecar-containers} + +Контейнери ініціалізації запускаються і завершують свої завдання до того, як розпочнеться робота основного контейнера застосунку. На відміну від [контейнерів sidecar](/docs/concepts/workloads/pods/sidecar-containers), контейнери ініціалізації не продовжують працювати паралельно з основними контейнерами. + +Контейнери ініціалізації запускаються і завершують свою роботу послідовно, і основний контейнер не починає свою роботу, доки всі контейнери ініціалізації успішно не завершать свою роботу. + +Контейнери ініціалізації не підтримують `lifecycle`, `livenessProbe`, `readinessProbe` чи `startupProbe`, у той час, як контейнери sidecar підтримують всі ці [пробі](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe), щоб керувати своїм життєвим циклом. + +Контейнери ініціалізації використовують ті ж ресурси (CPU, памʼять, мережу) що й основні контейнери застосунків, але не взаємодіють з ними напряму. Однак вони можуть використовувати спільні томи для обміну даними. + +### Використання контейнерів ініціалізації {#using-init-containers} + +Оскільки контейнери ініціалізації мають окремі образи від контейнерів застосунків, вони мають кілька переваг для коду, повʼязаного із запуском: + +* Контейнери ініціалізації можуть містити утиліти або власний код для налаштування, які відсутні в образі застосунку. Наприклад, немає потреби створювати образ `FROM` іншого образу лише для використання інструменту, такого як `sed`, `awk`, `python` чи `dig` під час налаштування. +* Ролі створення та розгортання образу застосунку можуть працювати незалежно одна від одної без необхідності спільного створення єдиного образу застосунку. +* Контейнери ініціалізації можуть працювати з різними видами файлових систем порівняно з контейнерами застосунків у тому ж Podʼі. Вони, отже, можуть мати доступ до {{< glossary_tooltip text="Secret" term_id="secret" >}}, до яких контейнери застосунків не можуть отримати доступ. +* Оскільки контейнери ініціалізації завершують свою роботу, перш ніж будь-які контейнери застосунків розпочнуть свою роботу, вони пропонують механізм блокування або затримки запуску контейнера застосунку до виконання певних умов. Після того, як умови виконані, всі контейнери застосунків у Pod можуть стартувати паралельно. +* Контейнери ініціалізації можуть безпечно виконувати утиліти або власний код, який інакше зробив би образ контейнера застосунку менш безпечним. Відокремлюючи непотрібні інструменти, ви можете обмежити область атак для вашого образу контейнера застосунку. + +### Приклади {#examples} + +Ось кілька ідей, як використовувати контейнери ініціалізації: + +* Очікування на створення {{< glossary_tooltip text="Service" term_id="service">}}, використовуючи команду оболонки у вигляді одного рядка, наприклад: + + ```shell + for i in {1..100}; do sleep 1; if nslookup myservice; then exit 0; fi; done; exit 1 + ``` + +* Реєстрація Подʼу у віддаленому сервері зі значеннями, отриманими з Downward API за допомогою команди, подібної цій: + + ```shell + curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$()&ip=$()' + ``` + +* Очікування певного часу перед запуском контейнера застосунку за допомогою команди, подібної цій: + + ```shell + sleep 60 + ``` + +* Клонування репозиторію Git в {{< glossary_tooltip text="Том" term_id="volume" >}} + +* Додавання значень у файл конфігурації та виклик інструменту шаблонування для динамічного створення файлу конфігурації для основного контейнера застосунку. Наприклад, додайте значення `POD_IP` у конфігурації та створюйте основний файл конфігурації застосунку, що використовує Jinja. + +#### Використання контейнерів ініціалізації {#init-containers-in-use} + +У цьому прикладі визначається простий Pod, який має два контейнери ініціалізації. Перший чекає на `myservice`, а другий — на `mydb`. Як тільки обидва контейнери ініціалізації завершаться, Pod запускає контейнер застосунку зі свого розділу `spec`. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: myapp-pod + labels: + app.kubernetes.io/name: MyApp +spec: + containers: + - name: myapp-container + image: busybox:1.28 + command: ['sh', '-c', 'echo The app is running! && sleep 3600'] + initContainers: + - name: init-myservice + image: busybox:1.28 + command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"] + - name: init-mydb + image: busybox:1.28 + command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"] +``` + +Ви можете запустити цей Pod, використовуючи: + +```shell +kubectl apply -f myapp.yaml +``` + +Вивід подібний до цього: + +```none +pod/myapp-pod created +``` + +І перевірте його статус за допомогою: + +```shell +kubectl get -f myapp.yaml +``` + +Вивід подібний до цього: + +```none +NAME READY STATUS RESTARTS AGE +myapp-pod 0/1 Init:0/2 0 6m +``` + +або для отримання більше деталей: + +```shell +kubectl describe -f myapp.yaml +``` + +Вивід подібний до цього: + +```none +Name: myapp-pod +Namespace: default +[...] +Labels: app.kubernetes.io/name=MyApp +Status: Pending +[...] +Init Containers: + init-myservice: +[...] + State: Running +[...] + init-mydb: +[...] + State: Waiting + Reason: PodInitializing + Ready: False +[...] +Containers: + myapp-container: +[...] + State: Waiting + Reason: PodInitializing + Ready: False +[...] +Events: + FirstSeen LastSeen Count From SubObjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 16s 16s 1 {default-scheduler } Normal Scheduled Successfully assigned myapp-pod to 172.17.4.201 + 16s 16s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulling pulling image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox" + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container init-myservice + 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container init-myservice +``` + +Щоб переглянути журнали контейнерів ініціалізації у цьому Pod, виконайте: + +```shell +kubectl logs myapp-pod -c init-myservice # Огляд першого контейнера ініціалізації +kubectl logs myapp-pod -c init-mydb # Огляд другого контейнера ініціалізації +``` + +На цей момент ці контейнери ініціалізації будуть чекати виявлення {{< glossary_tooltip text="Сервісів" term_id="service" >}} з іменами `mydb` та `myservice`. + +Ось конфігурація, яку ви можете використовувати для того, щоб ці Services зʼявилися: + +```yaml +--- +apiVersion: v1 +kind: Service +metadata: + name: myservice +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9376 +--- +apiVersion: v1 +kind: Service +metadata: + name: mydb +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9377 +``` + +Щоб створити Services `mydb` та `myservice`: + +```shell +kubectl apply -f services.yaml +``` + +Вивід подібний до цього: + +```none +service/myservice created +service/mydb created +``` + +Потім ви побачите, що ці контейнери ініціалізації завершаться, і Pod `myapp-pod` переходить у стан Running: + +```shell +kubectl get -f myapp.yaml +``` + +Вивід подібний до цього: + +```none +NAME READY STATUS RESTARTS AGE +myapp-pod 1/1 Running 0 9m +``` + +Цей простий приклад повинен дати вам натхнення для створення ваших власних контейнерів ініціалізації. У розділі [Що далі](#what-s-next) є посилання на більш детальний приклад. + +### Спільне використання ресурсів між контейнерами {#resource-sharing-within-containers} + +З урахуванням порядку виконання контейнерів ініціалізації, обслуговування та застосунків застосовуються наступні правила +використання ресурсів: + +* Найвищий запит чи обмеження будь-якого конкретного ресурсу, визначеного у всіх контейнерах ініціалізації, вважається _ефективним запитом/обмеженням ініціалізації_. Якщо для будь-якого ресурсу не вказано обмеження, це вважається найвищим обмеженням. +* _Ефективний запит/обмеження Pod\у_ для ресурсу — більше з: + * сума всіх запитів/обмежень контейнерів застосунків для ресурсу + * ефективний запит/обмеження для ініціалізації для ресурсу +* Планування виконується на основі ефективних запитів/обмежень, що означає, що контейнери ініціалізації можуть резервувати ресурси для ініціалізації, які не використовуються протягом життя Podʼа. +* Рівень якості обслуговування (QoS), _рівень QoS Podʼа_ — є рівнем QoS як для контейнерів ініціалізації, так і для контейнерів застосунків. + +Обмеження та ліміти застосовуються на основі ефективного запиту та +ліміту Podʼа. + +cgroups рівня Podʼа базуються на ефективному запиті та ліміті Podʼа, так само як і планувальник. + +{{< comment >}} +Цей розділ також присутній на сторінці [контейнерів sidecar](/docs/concepts/workloads/pods/sidecar-containers/). Якщо ви редагуєте цей розділ, змінюйте ці обидва місця. +{{< /comment >}} + +### Причини перезапуску Pod {#pod-restart-reasons} + +Pod може перезапускатися, що призводить до повторного виконання контейнерів ініціалізації, з наступних причин: + +* Перезапускається контейнер інфраструктури Podʼа. Це рідкісне явище і його має виконати тільки той, хто має root-доступ до вузлів. +* Всі контейнери в Podʼі завершуються, коли `restartPolicy` встановлено в `Always`, що примушує до перезапуску, а запис про завершення контейнера ініціалізації був втрачено через {{< glossary_tooltip text="збирання сміття" term_id="garbage-collection" >}}. + +Pod не буде перезапущено, коли змінюється образ контейнера ініціалізації, або запис про завершення контейнера ініціалізації був втрачений через збирання сміття. Це стосується Kubernetes v1.20 і пізніших версій. Якщо ви використовуєте попередню версію Kubernetes, ознайомтеся з документацією версії, яку ви використовуєте. + +## {{% heading "whatsnext" %}} {#what-s-next} + +Дізнайтеся більше про наступне: + +* [Створення Podʼа з контейнером ініціалізації](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container). +* [Налагодження контейнерів ініціалізації](/docs/tasks/debug/debug-application/debug-init-containers/). +* Огляд [kubelet](/docs/reference/command-line-tools-reference/kubelet/) та [kubectl](/docs/reference/kubectl/). +* [Види проб](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe): liveness, readiness, startup probe. +* [Контейнери sidecar](/docs/concepts/workloads/pods/sidecar-containers). diff --git a/content/uk/docs/concepts/workloads/pods/pod-lifecycle.md b/content/uk/docs/concepts/workloads/pods/pod-lifecycle.md new file mode 100644 index 0000000000000..d9342de6e4636 --- /dev/null +++ b/content/uk/docs/concepts/workloads/pods/pod-lifecycle.md @@ -0,0 +1,361 @@ +--- +title: Життєвий цикл Pod +content_type: concept +weight: 30 +--- + + + +Ця сторінка описує життєвий цикл Pod. Podʼи слідують визначеному життєвому циклу, починаючи з [фази](#pod-phase) `Pending`, переходячи до фази `Running`, якщо принаймні один з його основних контейнерів запускається добре, а потім до фаз `Succeeded` або `Failed`, залежно від того, чи завершився будь-який контейнер у Pod з помилкою. + +Поки Pod працює, kubelet може перезапускати контейнери, щоб вирішити деякі види несправностей. У межах Pod Kubernetes відстежує різні [стани контейнера](#container-states) і визначає дії, які слід вжити, щоб знову забезпечити справність Pod. + +В API Kubernetes у Pod є як специфікація, так і фактичний стан. Стан для обʼєкта Pod складається з набору [умов Pod](#pod-conditions). Ви також можете вставляти [власні дані готовності](#pod-readiness-gate) в дані умови для Pod, якщо це корисно для вашого застосунку. + +Podʼи плануються лише [один раз](/docs/concepts/scheduling-eviction/) протягом свого життя. Як тільки Pod призначено (сплановано) для вузла, Pod працює на цьому вузлі до тих пір, поки не зупиниться або не буде [завершений](#pod-termination). + + + +## Тривалість життя Pod {#pod-lifetime} + +Podʼи, подібно окремим контейнерам застосунків, вважаються відносно ефемерними (а не постійними) обʼєктами. Podʼи створюються, отримують унікальний ідентифікатор ([UID](/docs/concepts/overview/working-with-objects/names/#uids)) і призначаються вузлам, де вони залишаються до моменту завершення (відповідно до політики перезапуску) або видалення. Якщо {{< glossary_tooltip term_id="node" text="вузол">}} відмовляє, Podʼи, призначені до цього вузла, [призначаються для видалення](#pod-garbage-collection) після періоду затримки. + +Самі по собі Podʼи не здатні до самовідновлення. Якщо Pod призначено до {{< glossary_tooltip text="вузла" term_id="node" >}}, який потім відмовляє, Pod видаляється; подібно до того, Pod не виживе при відмові через відсутність ресурсів або обслуговування вузла. Kubernetes використовує більш абстрактний рівень, який називається {{< glossary_tooltip term_id="controller" text="контролер" >}}, який відповідає за управління відносно одноразовими екземплярами Podʼа. + +Даний Pod (визначений UID) ніколи не "переплановується" на інший вузол; замість цього, цей Pod може бути замінений новим, майже ідентичним Podʼом, навіть з тією самою назвою, якщо це потрібно, але з іншим UID. + +Коли говорять, що щось має такий самий термін життя, як і Pod, таке як {{< glossary_tooltip term_id="volume" text="volume" >}}, це означає, що ця річ існує стільки часу, скільки існує цей конкретний Pod (з таким самим UID). Якщо цей Pod буде видалений з будь-якої причини, і навіть якщо буде створений ідентичний замінник, повʼязана річ (у цьому прикладі — том) також буде знищена і створена знову. + +{{< figure src="/images/docs/pod.svg" title="Діаграма Podʼа" class="diagram-medium" >}} + +Багатоконтейнерний Pod, який містить витягувач файлів та вебсервер, який використовує постійний том для спільного сховища для контейнерів. + +## Фази Pod {#pod-phase} + +Поле `status` обʼєкта [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) Podʼа містить поле `phase`. + +Фази Pod — це простий, високорівневий підсумок того, на якому етапі свого життєвого циклу знаходиться Pod. Фаза не призначена бути всеосяжним підсумком спостережень за станом контейнера чи Pod, і бути процесом за спостереженням стану. + +Кількість та значення фаз Pod є строго прописаними. Крім того, що зазначено тут, не слід вважати, що щось відомо про Podʼи з певним значенням `phase`. + +Ось можливі значення для `phase`: + +Значення | Опис +:------------|:----------- +`Pending` | Pod прийнятий кластером Kubernetes, але один чи кілька контейнерів ще не було налаштовано та готові до запуску. Це включає час, який Pod витрачає на очікування планування, а також час, який витрачається на завантаження образів контейнерів з мережі. +`Running` | Pod привʼязаний до вузла, і всі контейнери створені. Принаймні один контейнер все ще працює або перебуває у процесі запуску чи перезапуску. +`Succeeded` | Всі контейнери в Podʼі завершили роботу успішно і не будуть перезапущені. +`Failed` | Всі контейнери в Podʼі завершили роботу, і принаймні один контейнер завершився з помилкою. Іншими словами, контейнер вийшов зі статусом, відмінним від нуля, або його завершила система. +`Unknown` | З якоїсь причини не вдалося отримати стан Podʼа. Ця фаза, як правило, виникає через помилку в комунікації з вузлом, де повинен виконуватися Pod. + +{{< note >}} +Коли Pod видаляється, за деякими командами kubectl він позначається як `Terminating`. Цей статус `Terminating` не є однією з фаз Podʼа. Pod отримує термін на відповідне завершення, який типово становить 30 секунд. Ви можете використовувати прапорець `--force` для [примусового завершення роботи Podʼа](/docs/concepts/workloads/pods/pod-lifecycle/#forced). +{{< /note >}} + +Починаючи з Kubernetes 1.27, kubelet переводить видалені Podʼи, крім [статичних Podʼів](/docs/tasks/configure-pod-container/static-pod/) та [примусово видалених Podʼів](/docs/concepts/workloads/pods/pod-lifecycle/#forced) без завершувача, в термінальну фазу (`Failed` або `Succeeded` залежно від статусів exit контейнерів Podʼа) перед їх видаленням із сервера API. + +Якщо вузол вмирає або відключається від іншої частини кластера, Kubernetes застосовує політику встановлення `phase` всіх Podʼів на втраченому вузлі у Failed. + +## Стани контейнера {#container-states} + +Окрім [фаз](#pod-phase) Podʼа загалом Kubernetes відстежує стан кожного контейнера всередині Podʼа. Ви можете використовувати [хуки життєвого циклу контейнера](/docs/concepts/containers/container-lifecycle-hooks/), щоб запускати події на певних етапах життєвого циклу контейнера. + +Як тільки {{< glossary_tooltip text="планувальник" term_id="kube-scheduler" >}} призначає Pod вузлу, kubelet починає створювати контейнери для цього Podʼа, використовуючи {{< glossary_tooltip text="середовище виконання контейнерів" term_id="container-runtime" >}}. Існує три можливі стани контейнера: `Waiting` (Очікування), `Running` (Виконання) та `Terminated` (Завершено). + +Щоб перевірити стан контейнерів Podʼа, ви можете використовувати `kubectl describe pod <ім'я-пода>`. Вивід показує стан для кожного контейнера в межах цього Podʼа. + +Кожен стан має конкретне значення: + +### `Waiting` {#container-state-waiting} + +Якщо контейнер не перебуває в стані або `Running`, або `Terminated`, то він знаходиться в стані `Waiting` (Очікування). Контейнер в стані `Waiting` все ще виконує операції, які він потребує для завершення запуску: наприклад, витягує образ контейнера із реєстру образів контейнерів або застосовує {{< glossary_tooltip text="Secret" term_id="secret" >}}. Коли ви використовуєте `kubectl` для опитування Podʼа із контейнером, який перебуває в стані `Waiting`, ви також бачите поле Reason, щоб узагальнити причину, чому контейнер знаходиться в цьому стані. + +### `Running` {#container-state-running} + +Статус `Running` вказує на те, що виконання контейнера відбувається без проблем. Якщо існує налаштований хук `postStart` — його роботу завершено. Коли ви використовуєте `kubectl` для опитування Podʼа із контейнером, який перебуває в стані `Running`, ви також бачите інформацію про те, коли контейнер увійшов в стан `Running`. + +### `Terminated` {#container-state-terminated} + +Контейнер в стані `Terminated` розпочав виконання і потім або завершив його успішно, або зазнав відмови з певних причин. Коли ви використовуєте `kubectl` для опитування Podʼа із контейнером, який перебуває в стані `Terminated`, ви бачите причину, код виходу та час початку та завершення періоду виконання цього контейнера. + +Якщо у контейнера є налаштований хук `preStop`, цей хук запускається перед тим, як контейнер увійде в стан `Terminated`. + +## Політика перезапуску контейнера {#restart-policy} + +У полі `spec` Podʼа є поле `restartPolicy` із можливими значеннями Always, OnFailure та Never. Стандартне значення — Always. + +`restartPolicy` для Podʼа застосовується до {{< glossary_tooltip text="контейнер застосунків" term_id="app-container" >}} в Podʼі та до звичайних [контейнерів ініціалізації](/docs/concepts/workloads/pods/init-containers/). [Контейнери Sidecar](/docs/concepts/workloads/pods/sidecar-containers/) не звертають уваги на поле `restartPolicy` на рівні Podʼа: в Kubernetes, sidecar визначається як запис всередині `initContainers`, який має свою політику перезапуску контейнера на рівні контейнера, встановлену на `Always`. Для контейнерів ініціалізації, які завершують роботу із помилкою, kubelet виконує їх перезапуск, якщо політика перезапуску Podʼа встановлена як `OnFailure` або `Always`. + +Коли kubelet обробляє перезапуск контейнера згідно з налаштованою політикою перезапуску, це стосується лише перезапусків, які призводять до заміни контейнерів всередині того ж Podʼа та на тому ж вузлі. Після завершення контейнерів у Podʼі, kubelet перезапускає їх із затримкою, що зростає експоненційно (10 с, 20 с, 40 с, …), і обмеженою пʼятьма хвилинами. Якщо контейнер виконується протягом 10 хвилин без проблем, kubelet скидає таймер затримки перезапуску для цього контейнера. [Контейнери Sidecar та життєвий цикл Podʼа](/docs/concepts/workloads/pods/sidecar-containers/#sidecar-containers-and-pod-lifecycle) пояснює поведінку `контейнерів ініціалізації` при вказанні поля `restartpolicy` для нього. + +## Умови Podʼа {#pod-conditions} + +У Podʼа є статус, який містить масив [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core), через які Pod проходить чи не проходить. Kubelet управляє наступними PodConditions: + +* `PodScheduled`: Pod був запланований на вузол. +* `PodReadyToStartContainers`: (бета-функція; типово [увімкнено](#pod-has-network)) + Pod sandbox був успішно створений, і була налаштована мережа. +* `ContainersReady`: всі контейнери в Pod готові. +* `Initialized`: всі [контейнери ініціалізації](/docs/concepts/workloads/pods/init-containers/) успішно завершили виконання. +* `Ready`: Pod може обслуговувати запити і його слід додати до балансування навантаження всіх відповідних Services. + +Назва поля | Опис +:--------------------|:----------- +`type` | Імʼя цієї умови Podʼа. +`status` | Вказує, чи застосовується ця умова, з можливими значеннями "`True`", "`False`" або "`Unknown`". +`lastProbeTime` | Відмітка часу останнього запиту стану Podʼа. +`lastTransitionTime` | Відмітка часу для останнього переходу Podʼа з одного статусу в інший. +`reason` | Машиночитаний текст у форматі UpperCamelCase, який вказує причину останньої зміни умови. +`message` | Повідомлення, яке вказує подробиці щодо останнього переходу стану, яке може розібрати людина. + +### Готовність Podʼа {#pod-readiness-gate} + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +Ваш застосунок може внести додатковий зворотний звʼязок або сигнали в PodStatus: _готовність Podʼа_. Щоб використовувати це, встановіть `readinessGates` в `spec` Podʼа, щоб вказати список додаткових умов, які kubelet оцінює для готовності Podʼа. + +Умови готовності визначаються поточним станом полів `status.condition` для Podʼа. Якщо Kubernetes не може знайти таку умову в полі `status.conditions` Podʼа, стан умови подається як "`False`". + +Наприклад: + +```yaml +kind: Pod +... +spec: + readinessGates: + - conditionType: "www.example.com/feature-1" +status: + conditions: + - type: Ready # вбудована умова Пода + status: "False" + lastProbeTime: null + lastTransitionTime: 2018-01-01T00:00:00Z + - type: "www.example.com/feature-1" # додаткова умова Пода + status: "False" + lastProbeTime: null + lastTransitionTime: 2018-01-01T00:00:00Z + containerStatuses: + - containerID: docker://abcd... + ready: true +... +``` + +Умови Podʼа, які ви додаєте, повинні мати імена, які відповідають [формату ключа міток](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) Kubernetes. + +### Стан для готовності Podʼа {#pod-readiness-status} + +Команда `kubectl patch` не підтримує зміну статусу обʼєкта накладанням патчів. Щоб встановити ці `status.conditions` для Podʼа, застосунки та {{< glossary_tooltip term_id="operator-pattern" text="оператори">}} повинні використовувати дію `PATCH`. Ви можете використовувати [бібліотеку клієнтів Kubernetes](/docs/reference/using-api/client-libraries/) для написання коду, який встановлює власні умови Podʼа для готовності Podʼа. + +Для Podʼа, який використовує власні умови, Pod оцінюється як готовий **тільки** коли застосовуються обидві наступні твердження: + +* Всі контейнери в Pod готові. +* Всі умови, вказані в `readinessGates`, рівні `True`. + +Коли контейнери Podʼа готові, але принаймні одна власна умова відсутня або `False`, kubelet встановлює умову Podʼа [ContainersReady](#pod-conditions) в `True`. + +### Готовність мережі Podʼа {#pod-has-network} + +{{< feature-state for_k8s_version="v1.29" state="beta" >}} + +{{< note >}} +На початкових стадіях створення цю умову називали `PodHasNetwork`. +{{< /note >}} + +Після того, як Pod отримує призначення на вузол, йому потрібно бути допущеним до kubelet та мати встановлені всі необхідні томи зберігання. Як тільки ці фази завершаться, kubelet співпрацює з середовищем виконання контейнерів (використовуючи {{< glossary_tooltip term_id="cri" >}}), щоб налаштувати ізольоване середовище виконання та налаштувати мережу для Podʼа. Якщо +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodReadyToStartContainersCondition` увімкнено (є типово увімкненим для Kubernetes {{< skew currentVersion >}}), умова `PodReadyToStartContainers` буде додана до поля `status.conditions` Podʼа. + +Умова `PodReadyToStartContainers` встановлюється в `False` Kubelet, коли він виявляє, що у Podʼа немає ізольованого середовища виконання із налаштованою мережею. Це трапляється в +наступних випадках: + +* На початковому етапі життєвого циклу Podʼа, коли kubelet ще не почав налаштовувати середовище виконання для Podʼа за допомогою середовища виконання контейнерів. +* Пізніше в життєвому циклі Podʼа, коли sandbox Podʼа був знищений через: + * перезавантаження вузла без вилучення Podʼа + * для середовищ виконання контейнерів, які використовують віртуальні машини для ізоляції, Pod sandbox віртуальної машини перезавантажується, що потім вимагає створення нового sandbox та свіжої конфігурації мережі контейнера. + +Умова `PodReadyToStartContainers` встановлюється в `True` kubelet після успішного завершення створення і налаштування ізольованого середовища виконання для Podʼа за допомогою втулка виконання. Kubelet може почати витягувати образ контейнера та створювати контейнери після встановлення умови `PodReadyToStartContainers` в `True`. + +Для Podʼа з контейнерами ініціалізації kubelet встановлює умову `Initialized` в `True` після успішного завершення контейнерів ініціалізації (що відбувається після успішного створення sandbox та налаштування мережі контейнером втулка виконання). Для Podʼа без контейнерів ініціалізації kubelet встановлює умову `Initialized` в `True` перед початком створення sandbox та налаштування мережі. + +### Готовність планування Podʼа {#pod-scheduling-readiness-gate} + +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +Дивіться [документацію про умови готовності планування Podʼа](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/). + +## Діагностика контейнера {#container-probes} + +Проба (_probe_) — це діагностика, яку періодично виконує [kubelet](/docs/reference/command-line-tools-reference/kubelet/) для контейнера. Для виконання діагностики kubelet або виконує код всередині контейнера, або виконує мережевий запит. + +### Механізми перевірки {#probe-check-methods} + +Існує чотири різних способи перевірки контейнера за допомогою проб. Кожна проба повинна визначати один з чотирьох цих механізмів: + +`exec` +: Виконує вказану команду всередині контейнера. Діагностика вважається успішною, якщо команда виходить з кодом стану 0. + +`grpc` +: Виконує віддалений виклик процедури [gRPC](https://grpc.io/). Цільовий обʼєкт повинен мати підтримку [gRPC health checks](https://grpc.io/grpc/core/md_doc_health-checking.html). Діагностика вважається успішною, якщо `status` відповіді рівний `SERVING`. + +`httpGet` +: Виконує HTTP-запит `GET` до IP-адреси Podʼа з вказаним портом та шляхом. Діагностика вважається успішною, якщо код стану відповіді більший або рівний 200 і менше ніж 400. + +`tcpSocket` +: Виконує перевірку TCP до IP-адреси Podʼа за вказаним портом. Діагностика вважається успішною, якщо порт відкритий. Якщо віддалена система (контейнер) відразу закриває зʼєднання після відкриття, це вважається нормальним. + +{{< caution >}} На відміну від інших механізмів, виконання проби `exec` передбачає створення/розгалуження кількох процесів при кожному виконанні. В результаті використання проб з exec на кластерах з високою щільністю Pod, низькими інтервалами `initialDelaySeconds`, `periodSeconds`, конфігуруючи будь-яку пробу з механізмом exec, може виникнути надмірне навантаження на використання центрального процесора вузла. У таких сценаріях розгляньте можливість використання альтернативних механізмів проб, щоб уникнути надмірного навантаження.{{< /caution >}} + +### Результат проби {#probe-outcome} + +Кожна проба має один із трьох результатів: + +`Success` +: Контейнер пройшов діагностику. + +`Failure` +: Контейнер не пройшов діагностику. + +`Unknown` +: Діагностика не пройшла (не потрібно вживати жодних заходів, і kubelet буде робити подальші перевірки). + +### Типи проб {#types-of-probe} + +Kubelet може опціонально виконувати та реагувати на три типи проб для робочих контейнерів: + +`livenessProbe` +: Вказує, чи контейнер працює. Якщо ця проба не проходить, kubelet припиняє роботу контейнера, і він підлягає перезапуску відповідно до своєї [політики перезапуску](#restart-policy). Якщо контейнер не надає пробу життєздатності, стандартний стан — `Success`. + +`readinessProbe` +: Вказує, чи готовий контейнер відповідати на запити. Якщо проба готовності завершиться невдачею, контролер endpoint видаляє IP-адресу Podʼа з endpoint усіх служб, які відповідають Podʼу. Стандартний стан готовності перед початковою затримкою — `Failure`. Якщо контейнер не надає пробу готовності, стандартний стан — `Success`. + +`startupProbe` +: Вказує, чи запущено застосунок всередині контейнера. Усі інші проби вимкнено, якщо надана проба запуску, поки вона не стане успішною. Якщо проба запуску завершиться невдачею, kubelet вбиває контейнер, і він підлягає перезапуску відповідно до [політики перезапуску](#restart-policy). Якщо контейнер не надає пробу запуску, стандартний стан — `Success`. + +Для отримання докладнішої інформації щодо налаштування проб життєздатності, готовності або запуску дивіться [Налаштування проб життєздатності, готовності та запуску](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). + +#### Коли слід використовувати пробу життєздатності? {#when-should-you-use-a-liveness-probe} + +Якщо процес у вашому контейнері може аварійно завершитися, коли виникає проблема або він стає нездоровим, вам можливо не потрібна проба життєздатності; kubelet автоматично виконає правильну дію згідно з політикою перезапуску Podʼа. + +Якщо ви хочете, щоб роботу вашого контейнера було припинено та він був перезапущений у разі невдачі проби, то вказуйте пробу життєздатності та встановлюйте `restartPolicy` на Always або OnFailure. + +#### Коли слід використовувати пробу готовності? {#when-should-you-use-a-readiness-probe} + +Якщо ви хочете розпочати надсилання трафіку до Podʼа лише після успішної проби, вказуйте пробу готовності. У цьому випадку проба готовності може бути такою самою, як і проба життєздатності, але наявність проби готовності в специфікації означає, що Pod розпочне роботу без отримання будь-якого трафіку і почне отримувати трафік лише після успішності проби. + +Якщо ви хочете, щоб ваш контейнер міг вимкнутися для обслуговування, ви можете вказати пробу готовності, яка перевіряє конкретний endpoint для готовності, відмінний від проби життєздатності. + +Якщо ваш застосунок залежить від бекенд сервісів, ви можете реалізувати як пробу життєздатності, так і пробу готовності. Проба життєздатності пройде, коли саме застосунок є справним, але проба готовності додатково перевірить, що кожна необхідна служба доступна. Це допомагає уникнути направлення трафіку до Podʼів, які можуть відповідати лише повідомленнями про помилки. + +Якщо вашому контейнеру потрібно працювати з великими даними, файлами конфігурації або міграціями під час запуску, ви можете використовувати [пробу запуску](#when-should-you-use-a-startup-probe). Однак, якщо ви хочете виявити різницю між застосунком, який зазнав невдачі, і щастосунком, який все ще обробляє дані запуску, вам може більше підійти проба готовності. + +{{< note >}} +Якщо вам потрібно мати можливість забрати запити при видаленні Podʼа, вам, можливо, не потрібна проба готовності; при видаленні Pod автоматично переводить себе в стан неготовності, незалежно від того, чи існує проба готовності. Pod залишається в стані неготовності, поки контейнери в Podʼі не зупиняться. +{{< /note >}} + +#### Коли слід використовувати пробу запуску? {#when-should-you-use-a-startup-probe} + +Проби запуску корисні для Podʼів, в яких контейнери потребують багато часу, щоб перейти в режим експлуатації. Замість встановлення довгого інтервалу життєздатності, ви можете налаштувати окрему конфігурацію для спостереження за контейнером при запуску, встановивши час, більший, ніж дозволяв би інтервал життєздатності. + +Якщо ваш контейнер зазвичай запускається довше, ніж +`initialDelaySeconds + failureThreshold × periodSeconds`, вам слід вказати пробу запуску, яка перевіряє той самий endpoint, що й проба життєздатності. Типово для `periodSeconds` — 10 секунд. Потім ви повинні встановити його `failureThreshold` настільки великим, щоб дозволити контейнеру запускатися, не змінюючи стандартних значень проби життєздатності. Це допомагає захистити від блокування роботи. + +### Завершення роботи Podʼів {#pod-termination} + +Оскільки Podʼи представляють процеси, які виконуються на вузлах кластера, важливо дозволити цим процесам завершувати роботу відповідним чином, коли вони більше не потрібні (замість раптового зупинення за допомогою сигналу `KILL` і відсутності можливості завершити роботу). + +Дизайн спрямований на можливість запитування видалення та знання про те, коли процеси завершують роботу, а також можливість забезпечення завершення видалень у настанні строки. Коли ви запитуєте видалення Podʼа, кластер реєструє та відстежує призначений строк належного припинення роботи перед тим, як дозволити примусове закінчення роботи Podʼа. З цим відстеженням примусового завершення, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} намагається виконати належне завершення роботи Podʼу. + +Зазвичай, з цим належним завершенням роботи, kubelet робить запити до середовища виконання контейнера з метою спроби зупинити контейнери у Podʼі, спочатку надсилаючи сигнал TERM (також відомий як SIGTERM) основному процесу в кожному контейнері з таймаутом для належного завершення. Запити на зупинку контейнерів обробляються середовищем виконання контейнера асинхронно. Немає гарантії щодо порядку обробки цих запитів. Багато середовищ виконання контейнерів враховують значення `STOPSIGNAL`, визначене в образі контейнера і, якщо воно відрізняється, надсилають значення STOPSIGNAL, визначене в образі контейнера, замість TERM. Після закінчення строку належного завершення роботи сигнал KILL надсилається до будь-яких залишкових процесів, а потім Pod видаляється з {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. Якщо kubelet або служба управління середовищем виконання перезапускається під час очікування завершення процесів, кластер повторює спробу спочатку, включаючи повний початковий строк належного завершення роботи. + +Приклад роботи: + +1. Ви використовуєте інструмент `kubectl`, щоб вручну видалити певний Pod, з типовим значення строку належного припинення роботи (30 секунд). + +2. В Podʼі в API-сервері оновлюється час, поза яким Pod вважається "мертвим", разом із строком належного припинення роботи. Якщо ви використовуєте `kubectl describe` для перевірки Podʼа, який ви видаляєте, цей Pod показується як "Terminating". На вузлі, на якому виконується Pod: як тільки kubelet бачить, що Pod був позначений як такий, що закінчує роботу (встановлений строк для належного вимкнення), kubelet розпочинає локальний процес вимкнення Podʼа. + + 1. Якщо один із контейнерів Podʼа визначає `preStop` [хук](/docs/concepts/containers/container-lifecycle-hooks), і `terminationGracePeriodSeconds` в специфікації Podʼа не встановлено на 0, kubelet виконує цей хук всередині контейнера. Стандартно `terminationGracePeriodSeconds` встановлено на 30 секунд. + + Якщо `preStop` хук все ще виконується після закінчення строку належного припинення роботи, kubelet запитує невелике подовження строку належного припинення роботи в розмірі 2 секунд. + + {{< note >}} + Якщо `preStop` хук потребує більше часу для завершення, ніж дозволяє стандартний строк належного припинення роботи, вам слід змінити `terminationGracePeriodSeconds` відповідно до цього. + {{< /note >}} + + 2. Kubelet робить виклик до середовища виконання контейнера для надсилання сигналу TERM процесу 1 всередині кожного контейнера. + {{< note >}} + Контейнери в Podʼі отримують сигнал TERM в різний час та в довільному порядку. Якщо порядок вимкнення має значення, розгляньте можливість використання `preStop` хука для синхронізації. + {{< /note >}} + +3. У той же час, коли kubelet розпочинає належне вимкнення Podʼа, панель управління оцінює, чи слід вилучити цей Pod з обʼєктів EndpointSlice (та Endpoints), де ці обʼєкти представляють {{< glossary_tooltip term_id="service" text="Service" >}} із налаштованим {{< glossary_tooltip text="selector" term_id="selector" >}}. {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} та інші ресурси робочого навантаження більше не розглядають такий Pod як дійсний. + + Podʼи, які повільно завершують роботу, не повинні продовжувати обслуговувати звичайний трафік і повинні почати завершення та завершення обробки відкритих зʼєднань. Деякі застосунки потребують більш часу для належного завершення роботи, наприклад, сесії піготовки до обслуговування та завершення. + + Будь-які endpoint, які представляють Podʼи, що закінчують свою роботу, не вилучаються негайно з EndpointSlices, а статус, який вказує на [стан завершення](/docs/concepts/services-networking/endpoint-slices/#conditions), викладається з EndpointSlice API (та застарілого API Endpoints). Endpointʼи, які завершуть роботу, завжди мають статус `ready` як `false` (для сумісності з версіями до 1.26), тому балансувальники навантаження не будуть використовувати його для звичайного трафіку. + + Якщо трафіку на завершуючомуся Podʼі ще потрібний, фактичну готовність можна перевірити як умову `serving`. Детальніше про те, як реалізувати очищення зʼєднань, можна знайти в розділі [Порядок завершення роботи Podʼів та Endpointʼів](/docs/tutorials/services/pods-and-endpoint-termination-flow/) + +{{}} +Якщо у вашому кластері відключено feature gate `EndpointSliceTerminatingCondition` (є типов увікненим з Kubernetes 1.22, і заблокована в 1.26), то панель управління Kubernetes вилучає Pod з будь-яких відповідних EndpointSlices, щойно належне завершеня роботи Podʼа _починається_. Описана вище поведінка стосується випадку, коли `EndpointSliceTerminatingCondition` увімкнено. +{{}} + +{{}} +Починаючи з Kubernetes 1.29, якщо ваш Pod включає один чи кілька контейнерів sidecar (контейнери ініціалізації з політикою постіного перезапуску), kubelet затримає надсилання сигналу TERM цим контейнерам sidecar до тих пір, поки останній основний контейнер повністю не завершить роботу. Контейнери sidecar будуть завершені в зворотньому порядку, в якому вони визначені в специфікації Podʼа. Це забезпечує, що контейнери sidecar продовжуватимуть обслуговувати інші контейнери в Podʼі до тих пір, поки вони не будуть більше потрібні. + +Слід зазначити, що повільне завершення основного контейнера також затримає завершення контейнерів sidecar. Якщо строк належного завершення роботи закінчується до завершення процесу, може відбутися екстрене завершення. У цьому випадку всі залишкові контейнери в Podʼі будуть завершені одночасно із коротким строком належного завершення роботи. + +Так само, якщо у Podʼа є хук preStop, який перевищує строк належного завершення роботи, екстрене завершення також може відбутися. Загалом, якщо ви використовували хуки preStop для управління порядком завершення без контейнерів sidecar, ви можете тепер видалити їх і дозволити kubelet автоматично керувати завершенням контейнерів sidecar. +{{}} + +1. Коли строк належного завершення роботи закінчується, kubelet виконує примусове вимкнення. Середовище виконання контейнера відсилає сигнал `SIGKILL` будь-яким процесам, які все ще працюють в будь-якому контейнері в Podʼі. Крім того, kubelet очищає прихований контейнер `pause`, якщо середовище виконання контейнера використовує його. +2. Kubelet переводить Pod у термінальну фазу (`Failed` або `Succeeded` залежно від кінцевого стану його контейнерів). Цей крок гарантується починаючи з версії 1.27. +3. Kubelet спричинює примусове видалення обʼєкта Pod з API-сервера, встановлюючи строк належного заверщення на 0 (безпосереднє видалення). +4. API-сервер видаляє обʼєкт API Pod, який потім більше не є видимим для жодного клієнта. + +### Примусове завершення Podʼів {#pod-termination-forced} + +{{< caution >}} +Примусове завершення може бути потенційно руйнівним для деяких завдань та їх Podʼів. +{{< /caution >}} + +Типово всі видалення є належними протягом 30 секунд. Команда `kubectl delete` підтримує опцію `--grace-period=`, яка дозволяє вам перевизначити типове значення своїм. + +Встановлення належного завершення роботи в `0` примусово та негайно видаляє Pod з API сервера. Якщо Pod все ще працює на вузлі, це примусове видалення спричинює початок негайного прибирання kubelet. +{{< note >}} +Ви повинні вказати додатковий прапорtwm `--force` разом із `--grace-period=0`, щоб виконати примусове видалення. +{{< /note >}} + +Під час примусового видалення API-сервер не чекає підтвердження від kubelet, що Pod завершено на вузлі, на якому він працював. Він +негайно видаляє Pod в API, щоб можна було створити новий pod з тим самим ім'ям. На вузлі Podʼи, які мають бути видалені негайно, все ще отримують невеликий строк для завершення роботи перед примусовим вимиканням. + +{{< caution >}} +Негайне видалення не чекає підтвердження того, що робочий ресурс було завершено. Ресурс може продовжувати працювати в кластері нескінченно. +{{< /caution >}} + +Якщо вам потрібно примусово видалити Podʼи, які є частиною StatefulSet, дивіться документацію для [видалення Podʼів з StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/). + +### Збір сміття Podʼів {#pod-garbage-collection} + +Для несправних Podʼів обʼєкти API залишаються в API кластера, поки людина чи {{< glossary_tooltip term_id="controller" text="контролер" >}} явно їх не видалять. + +Збірник сміття Podʼів (PodGC), який є контролером панелі управління, прибирає завершені Podʼів (із фазою `Succeeded` або `Failed`), коли кількість Podʼів перевищує налаштований поріг (визначений параметром `terminated-pod-gc-threshold` в kube-controller-manager). Це запобігає витоку ресурсів при створенні та завершенні Podʼів з часом. + +Крім того, PodGC очищує будь-які Podʼів, які відповідають одній з наступних умов: + +1. є осиротілими Podʼів — привʼязаними до вузла, якого вже не існує, +2. є незапланованими Podʼами у стані завершення, +3. є Podʼів у стані завершення, привʼязаними до непрацюючого вузла з позначкою [`node.kubernetes.io/out-of-service`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service), коли ввімкнено функціонал `NodeOutOfServiceVolumeDetach`. + +Коли ввімкнено функціонал `PodDisruptionConditions`, разом із прибиранням Podʼів, PodGC також позначає їх як несправнені, якщо вони перебувають в незавершеній фазі. Крім того, PodGC додає умову руйнування Podʼу під час очищення осиротілого Podʼу. Див. [умови руйнування Podʼів](/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions) +для отримання докладніших відомостей. + +## {{% heading "whatsnext" %}} + +* Отримайте практичний досвід [прикріплення обробників до подій життєвого циклу контейнера](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). + +* Отримайте практичний досвід [налаштування проб Liveness, Readiness та Startup](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). + +* Дізнайтеся більше про [обробники життєвого циклу контейнера](/docs/concepts/containers/container-lifecycle-hooks/). + +* Дізнайтеся більше про [контейнери sidecar](/docs/concepts/workloads/pods/sidecar-containers/). + +* Для докладної інформації про статус Podʼа та контейнера в API, перегляньте документацію API, яка охоплює [`status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) для Podʼа. diff --git a/content/uk/docs/concepts/workloads/pods/pod-qos.md b/content/uk/docs/concepts/workloads/pods/pod-qos.md new file mode 100644 index 0000000000000..35f68929c3bc0 --- /dev/null +++ b/content/uk/docs/concepts/workloads/pods/pod-qos.md @@ -0,0 +1,79 @@ +--- +title: Класи якості обслуговування (Quality of Service) Podʼів +content_type: concept +weight: 85 +--- + + + +Ця сторінка вводить _класи обслуговування (Quality of Service, QoS)_ в Kubernetes та пояснює, як Kubernetes присвоює кожному Podʼу клас QoS як наслідок обмежень ресурсів, які ви вказуєте для контейнерів у цьому Podʼі. Kubernetes покладається на цю класифікацію для прийняття рішень про те, які Podʼи виводити при відсутності достатньої кількості ресурсів на вузлі. + + + +## Класи обслуговування (QoS) {#quality-of-service-classes} + +Kubernetes класифікує Podʼи, які ви запускаєте, і розподіляє кожен Pod в певний _клас обслуговування (Quality of Service, QoS)_. Kubernetes використовує цю класифікацію для впливу на те, як різні Podʼи обробляються. Kubernetes робить цю класифікацію на основі [резервів ресурсів](/docs/concepts/configuration/manage-resources-containers/) контейнерів у цьому Podʼі, а також того, як ці резерви стосуються обмежень ресурсів. Це відомо як _клас обслуговування (Quality of Service, QoS)_. Kubernetes присвоює кожному Podʼу клас QoS на основі запитів та лімітів ресурсів його складових контейнерів. Класи QoS використовуються Kubernetes для вирішення того, які Podʼи виводити з вузла, який переживає [високий тиск на вузол](/docs/concepts/scheduling-eviction/node-pressure-eviction/). Можливі класи QoS: `Guaranteed`, `Burstable` та `BestEffort`. + +### Guaranteed + +Podʼи, які мають клас `Guaranteed`, мають найстрогіші обмеження ресурсів і найменше ймовірності бути виведеними. Гарантується, що їх не буде примусово завершено, доки вони не перевищать свої ліміти або доки не буде інших Podʼів з меншим пріоритетом, які можна витіснити з вузла. Вони можуть не отримувати ресурси поза вказаними лімітами. Ці Podʼи також можуть використовувати виключно власні CPU, використовуючи [політику управління CPU](/docs/tasks/administer-cluster/cpu-management-policies/#static-policy) типу `static`. + +#### Критерії {#criteria} + +Щоб Pod отримав клас QoS `Guaranteed`: + +* У кожному контейнері Podʼа повинен бути ліміт та запит на памʼять. +* Для кожного контейнера у Podʼі ліміт памʼяті повинен дорівнювати запиту памʼяті. +* У кожному контейнері Podʼа повинен бути ліміт та запит на CPU. +* Для кожного контейнера у Podʼі ліміт CPU повинен дорівнювати запиту CPU. + +### Burstable + +Podʼи, які мають клас `Burstable`, мають гарантії ресурсів на основі запиту, але не вимагають конкретного ліміту. Якщо ліміт не вказано, він типово встановлюється рівним потужності вузла, що дозволяє Podʼам гнучко збільшувати свої ресурси, якщо це можливо. У разі виведення Podʼа через високий тиск на вузол ці Podʼи виводяться лише після виведення всіх Podʼів з класом `BestEffort`. Оскільки `Burstable` Pod може містити контейнер, який не має лімітів чи запитів ресурсів, Pod з класом `Burstable` може намагатися використовувати будь-яку кількість ресурсів вузла. + +#### Критерії {#criteria-1} + +Pod отримує клас QoS `Burstable`, якщо: + +* Pod не відповідає критеріям класу QoS `Guaranteed`. +* Принаймні один контейнер у Podʼі має запит або ліміт пам\яті або CPU. + +### BestEffort + +Podʼи в класі `BestEffort` можуть використовувати ресурси вузла, які не призначені спеціально для Podʼів інших класів QoS. Наприклад, якщо у вузлі є 16 ядер CPU, і ви призначили 4 ядра CPU під Pod із класом `Guaranteed`, тоді Pod з класом `BestEffort` може намагатися використовувати будь-яку кількість решти з 12 ядер CPU. + +Kubelet віддає перевагу виведенню Podʼів з класом `BestEffort`, якщо вузол потрапляє в стан тиску на ресурси. + +#### Критерії {#criteria-2} + +Pod має клас QoS `BestEffort`, якщо він не відповідає критеріям ані `Guaranteed`, ані `Burstable`. Іншими словами, Pod має клас `BestEffort` лише в тому випадку, якщо жоден з контейнерів у Podʼі не має ліміту або запиту памʼяті, і жоден з контейнерів у Podʼі не має ліміту або запиту CPU. Контейнери в Podʼі можуть запитувати інші ресурси (не CPU чи памʼять) і все одно класифікуватися як `BestEffort`. + +## QoS памʼяті з cgroup v2 {#memory-qos-with-cgroup-v2} + +{{< feature-state feature-gate-name="MemoryQoS" >}} + +QoS памʼяті використовує контролер памʼяті cgroup v2 для гарантування ресурсів памʼяті в Kubernetes. Запити та ліміти памʼяті контейнерів у Podʼі використовуються для встановлення конкретних інтерфейсів `memory.min` та `memory.high`, які надає контролер памʼяті. Коли `memory.min` встановлено на запити памʼяті, ресурси памʼяті резервуються і ніколи не звільняються ядром; саме так QoS памʼяті забезпечує наявність памʼяті для Podʼів Kubernetes. Якщо в контейнері встановлено ліміти памʼяті, це означає, що системі потрібно обмежити використання памʼяті контейнера; QoS памʼяті використовує `memory.high` для обмеження роботи навантаження, що наближається до свого ліміту памʼяті, забезпечуючи, що систему не перевантажено миттєвим виділенням памʼяті. + +QoS памʼяті покладається на клас QoS для визначення того, які налаштування застосовувати; проте це різні механізми, які обидва надають контроль за якістю обслуговування. + +## Деяка поведінка незалежна від класу QoS {#class-independent-behavior} + +Деяка поведінка є незалежною від класу QoS, який визначає Kubernetes. Наприклад: + +* Будь-який контейнер, що перевищує ліміт ресурсів, буде завершено та перезапущено kubelet без впливу на інші контейнери в цьому Podʼі. + +* Якщо контейнер перевищує свій запит ресурсу і вузол, на якому він працює, стикається з нестачею ресурсів, Pod, в якому він перебуває, стає кандидатом для [виведення](/docs/concepts/scheduling-eviction/node-pressure-eviction/). Якщо це станеться, всі контейнери в цьому Podʼі будуть завершені. Kubernetes може створити новий Pod, зазвичай на іншому вузлі. + +* Запит ресурсів Podʼа дорівнює сумі запитів ресурсів його компонентних контейнерів, а ліміт Podʼа дорівнює сумі лімітів ресурсів його контейнерів. + +* Планувальник kube-scheduler не враховує клас QoS при виборі того, які Podʼи [витісняти](/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption). Витіснення може відбуватися, коли кластер не має достатньо ресурсів для запуску всіх визначених вами Podʼів. + +## {{% heading "whatsnext" %}} + +* Дізнайтеся про [управління ресурсами для Podʼів та контейнерів](/docs/concepts/configuration/manage-resources-containers/). +* Дізнайтеся про [виведення через тиск на вузол](/docs/concepts/scheduling-eviction/node-pressure-eviction/). +* Дізнайтеся про [пріоритет Podʼів та витіснення](/docs/concepts/scheduling-eviction/pod-priority-preemption/). +* Дізнайтеся про [виведення Podʼів](/docs/concepts/workloads/pods/disruptions/). +* Дізнайтеся, як [призначати ресурси памʼяті контейнерам та Podʼам](/docs/tasks/configure-pod-container/assign-memory-resource/). +* Дізнайтеся, як [призначати ресурси CPU контейнерам та Podʼам](/docs/tasks/configure-pod-container/assign-cpu-resource/). +* Дізнайтеся, як [налаштовувати клас обслуговування для Podʼів](/docs/tasks/configure-pod-container/quality-service-pod/). diff --git a/content/uk/docs/concepts/workloads/pods/sidecar-containers.md b/content/uk/docs/concepts/workloads/pods/sidecar-containers.md new file mode 100644 index 0000000000000..e51538bfeb2f4 --- /dev/null +++ b/content/uk/docs/concepts/workloads/pods/sidecar-containers.md @@ -0,0 +1,80 @@ +--- +title: Контейнери sidecar +content_type: concept +weight: 50 +--- + +{{< feature-state for_k8s_version="v1.29" state="beta" >}} + +Контейнери sidecar — це додаткові контейнери, які працюють разом із основним контейнером застосунку всередині одного {{< glossary_tooltip text="Podʼа" term_id="pod" >}}. Ці контейнери використовуються для розширення чи покращення функціональності основного контейнера застосунку, надаючи додаткові служби чи функціональність, такі як логування, моніторинг, безпеку або синхронізацію даних, не змінюючи безпосередньо код основного застосунку. + +## Увімкнення контейнерів sidecar {#enabling-sidecar-containers} + +У Kubernetes 1.29, стандартно увімкнено [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) з іменем +`SidecarContainers`, який дозволяє вам вказати `restartPolicy` для контейнерів, перерахованих в полі `initContainers` Podʼа. Ці контейнери _sidecar_, які можна перезапускати, незалежні від [контейнерів ініціалізації](/docs/concepts/workloads/pods/init-containers/) та основного контейнера застосунку всередині одного Podʼа. Їх можна запускати, зупиняти чи перезапускати +без впливу на основний контейнер застосунку та інші контейнери ініціалізації. + +## Контейнери sidecar та життєвий цикл Podʼа {#sidecar-containers-and-pod-lifecycle} + +Якщо контейнер ініціалізації створено з параметром `restartPolicy`, встановленим на `Always`, він розпочне роботу і залишиться запущеним протягом усього життя Podʼа. Це може бути корисно для запуску служб підтримки, відокремлених від основних контейнерів застосунку. + +Якщо для цього контейнера ініціалізації вказано `readinessProbe`, результат буде використовуватися для визначення стану `ready` Podʼа. + +Оскільки ці контейнери визначені як контейнери ініціалізації, вони користуються тими ж гарантіями порядку та послідовності, що й інші контейнери ініціалізації, що дозволяє їх змішувати з іншими контейнерами ініціалізації в складні потоки ініціалізації Podʼа. + +В порівнянні зі звичайними контейнерами ініціалізації, контейнери, визначені в `initContainers`, продовжують роботу після їх запуску. Це важливо, коли в `.spec.initContainers` для Podʼа є більше одного запису. Після запуску контейнера ініціалізації типу sidecar (kubelet встановлює статус `started` для цього контейнера в `true`), kubelet запускає наступний контейнер ініціалізації з упорядкованого списку `.spec.initContainers`. Цей статус стає true через те, що в контейнері працює процес і немає визначеного `startupProbe`, або внаслідок успішного виконання `startupProbe`. + +Ось приклад Deployment із двома контейнерами, один з яких — це контейнер sidecar: + +{{% code_sample language="yaml" file="application/deployment-sidecar.yaml" %}} + +Ця функція також корисна для запуску задач із контейнерами sidecar, оскільки контейнер sidecar не завадить задачі завершити роботу після завершення роботи основного контейнера. + +Ось приклад задачі із двома контейнерами, один з яких — це контейнер sidecar: + +{{% code_sample language="yaml" file="application/job/job-sidecar.yaml" %}} + +## Відмінності від звичайних контейнерів {#differences-from-regulr-containers} + +Контейнери sidecar працюють поруч зі звичайними контейнерами в одному Podʼі. Однак вони не виконують основну логіку застосунку; замість цього вони надають додатковий функціонал основному застосунку. + +Контейнери sidecar мають власні незалежні життєві цикли. Їх можна запускати, зупиняти та перезапускати незалежно від звичайних контейнерів. Це означає, що ви можете оновлювати, масштабувати чи обслуговувати контейнери sidecar, не впливаючи на основний застосунок. + +Контейнери sidecar ділять той самий простір імен мережі та сховища з основним контейнером. Це спільне розташування дозволяє їм тісно взаємодіяти та спільно використовувати ресурси. + +## Відмінності від контейнерів ініціалізації {#differences-from-init-containers} + +Контейнери sidecar працюють поруч із основним контейнером, розширюючи його функціональність та надаючи додаткові служби. + +Контейнери sidecar працюють паралельно з основним контейнером застосунку. Вони активні протягом усього життєвого циклу Podʼа та можуть бути запущені та зупинені незалежно від основного контейнера. На відміну від [контейнерів ініціалізації](/docs/concepts/workloads/pods/init-containers/), контейнери sidecar підтримують [проби](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe), щоб контролювати їхній життєвий цикл. + +Ці контейнери можуть взаємодіяти безпосередньо з основними контейнерами застосунків, спільно використовуючи той самий простір імен мережі, файлову систему та змінні оточення. Вони тісно співпрацюють, надаючи додатковий функціонал. + +## Спільне використання ресурсів всередині контейнерів {#resource-sharing-within-containers} + +{{< comment >}} +Цей розділ також присутній на сторінці [контейнерів ініціалізації](/docs/concepts/workloads/pods/init-containers/). +Якщо ви редагуєте цей розділ, змініть обидва місця. +{{< /comment >}} + +З урахуванням порядку виконання контейнерів ініціалізації, обслуговування та застосунків застосовуються наступні правила +використання ресурсів: + +* Найвищий запит чи обмеження будь-якого конкретного ресурсу, визначеного у всіх контейнерах ініціалізації, вважається _ефективним запитом/обмеженням ініціалізації_. Якщо для будь-якого ресурсу не вказано обмеження, це вважається найвищим обмеженням. +* _Ефективний запит/обмеження Pod\у_ для ресурсу — більше з: + * сума всіх запитів/обмежень контейнерів застосунків для ресурсу + * ефективний запит/обмеження для ініціалізації для ресурсу +* Планування виконується на основі ефективних запитів/обмежень, що означає, що контейнери ініціалізації можуть резервувати ресурси для ініціалізації, які не використовуються протягом життя Podʼа. +* Рівень якості обслуговування (QoS), _рівень QoS Podʼа_ — є рівнем QoS як для контейнерів ініціалізації, так і для контейнерів застосунків. + +Обмеження та ліміти застосовуються на основі ефективного запиту та +ліміту Podʼа. + +cgroups рівня Podʼа базуються на ефективному запиті та ліміті Podʼа, так само як і планувальник. + +## {{% heading "whatsnext" %}} + +* Прочитайте блог-пост про [нативні контейнери sidecar](/blog/2023/08/25/native-sidecar-containers/). +* Прочитайте про [створення Podʼа, який має контейнер ініціалізації](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container). +* Дізнайтеся про [види проб](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe): liveness, readiness, startup probe. +* Дізнайтеся про [накладні витрати роботи Podʼа](/docs/concepts/scheduling-eviction/pod-overhead/). diff --git a/content/uk/docs/concepts/workloads/pods/user-namespaces.md b/content/uk/docs/concepts/workloads/pods/user-namespaces.md new file mode 100644 index 0000000000000..c0128271cbf5e --- /dev/null +++ b/content/uk/docs/concepts/workloads/pods/user-namespaces.md @@ -0,0 +1,123 @@ +--- +title: Простори імен користувачів +aka: + - User Namespaces +reviewers: +content_type: concept +weight: 160 +min-kubernetes-server-version: v1.25 +--- + + +{{< feature-state for_k8s_version="v1.25" state="alpha" >}} + +Ця сторінка пояснює, як використовуються простори імен користувачів у Podʼах Kubernetes. Простір імен користувача ізолює користувача, який працює всередині контейнера, від користувача на хості. + +Процес, який працює як root в контейнері, може працювати як інший (не-root) користувач на хості; іншими словами, процес має повні привілеї для операцій всередині простору користувача, але не має привілеїв для операцій за його межами. + +Ви можете використовувати цю функцію, щоб зменшити можливий збиток, який може заподіяти скомпрометований контейнер хосту або іншим Podʼам на тому ж вузлі. Є [кілька вразливостей безпеки][KEP-vulns], які оцінено як **ВИСОКІ** або **КРИТИЧНІ**, і які не можна було б використати при активних просторах користувачів. Передбачається, що простір користувачів також буде запобігати деяким майбутнім вразливостям. + +[KEP-vulns]: https://github.com/kubernetes/enhancements/tree/217d790720c5aef09b8bd4d6ca96284a0affe6c2/keps/sig-node/127-user-namespaces#motivation + + +## {{% heading "prerequisites" %}} + +{{% thirdparty-content %}} + +Це функція, доступна лише для Linux, і потребує підтримки в Linux для монтування idmap на використовуваних файлових системах. Це означає: + +* На вузлі файлова система, яку ви використовуєте для `/var/lib/kubelet/pods/`, або спеціальна тека, яку ви конфігуруєте для цього, повинна підтримувати монтування idmap. +* Всі файлові системи, які використовуються в томах Podʼа, повинні підтримувати монтування idmap. + +На практиці це означає, що вам потрібне ядро Linux принаймні версії 6.3, оскільки tmpfs почав підтримувати монтування idmap у цій версії. Це зазвичай потрібно, оскільки кілька функцій Kubernetes використовують tmpfs (токен облікового запису служби, який монтується типово, використовує tmpfs, аналогічно Secrets використовують tmpfs та інше). + +Деякі популярні файлові системи, які підтримують монтування idmap в Linux 6.3, — це: btrfs, ext4, xfs, fat, tmpfs, overlayfs. + +Крім того, підтримка необхідна в {{< glossary_tooltip text="середовищі виконання контейнерів" term_id="container-runtime" >}} для використання цієї функції з Podʼами Kubernetes: + +* CRI-O: версія 1.25 (і пізніше) підтримує простори користувачів для контейнерів. + +containerd v1.7 несумісний із підтримкою userns в Kubernetes v1.27 по v{{< skew latestVersion >}}. Kubernetes v1.25 і v1.26 використовували попередню реалізацію, яка **є** сумісною з containerd v1.7 з точки зору підтримки userns. Якщо ви використовуєте версію Kubernetes, відмінну від {{< skew currentVersion >}}, перевірте документацію для цієї версії Kubernetes для найбільш актуальної інформації. Якщо є новіша версія containerd, ніж v1.7, яка доступна для використання, також перевірте документацію containerd щодо інформації про сумісність. + +Стан підтримки просторів користувачів в cri-dockerd відстежується у [тікеті][CRI-dockerd-issue] на GitHub. + +[CRI-dockerd-issue]: https://github.com/Mirantis/cri-dockerd/issues/74 + +## Вступ {#introduction} + +Простори користувачів — це функція Linux, яка дозволяє зіставляти користувачів у контейнері з користувачами на хості. Крім того, можливості, наданні Pod в просторі користувача, є дійсними лише в просторі та не виходять за його межі. + +Pod може обрати використовувати простори користувачів, встановивши поле `pod.spec.hostUsers` в `false`. + +Kubelet вибере host UID/GID, до якого зіставлено Pod, і зробить це так, щоб гарантувати, що жоден з Podʼів на одному вузлі не використовує те саме зіставлення. + +Поля `runAsUser`, `runAsGroup`, `fsGroup` тощо в `pod.spec` завжди звертаються до користувача всередині контейнера. + +Дійсні UID/GID, коли ця функція активована, є у діапазоні 0-65535. Це стосується файлів та процесів (`runAsUser`, `runAsGroup` і т. д.). + +Файли з UID/GID за межами цього діапазону будуть вважатися належними переповненню ID, яке зазвичай дорівнює 65534 (налаштовано в `/proc/sys/kernel/overflowuid` та `/proc/sys/kernel/overflowgid`). Однак їх неможливо змінити, навіть якщо запущено як user/group 65534. + +Більшість застосунків, які потребують запуску з правами root, але не мають доступу до інших просторів імен хоста чи ресурсів, повинні продовжувати працювати без змін, якщо простори користувачів активовано. + +## Розуміння просторів користувачів для Podʼів {#pods-and-userns} + +Кілька середовищ виконання контейнерів із їхньою типовою конфігурацією (таких як Docker Engine, containerd, CRI-O) використовують простори імен Linux для ізоляції. Існують інші технології, які також можна використовувати з цими середовищами (наприклад, Kata Containers використовує віртуальні машини замість просторів імен Linux). Ця стосується середовищ виконання контейнерів, які використовують простори імен Linux для ізоляції. + +При стандартному створенні Podʼа використовуються різні нові простори імен для ізоляції: мережевий простір імен для ізоляції мережі контейнера, простір імен PID для ізоляції виду процесів і т.д. Якщо використовується простір користувачів, це ізолює користувачів у контейнері від користувачів на вузлі. + +Це означає, що контейнери можуть працювати як root та зіставлятись з не-root користувачами на хості. Всередині контейнера процес буде вважати себе root (і, отже, інструменти типу `apt`, `yum`, ін. працюватимуть нормально), тоді як насправді процес не має привілеїв на хості. Ви можете перевірити це, наприклад, якщо ви перевірите, як користувач запущений у контейнері, виконавши `ps aux` з хосту. Користувач, якого показує `ps`, не той самий, що і користувач, якого ви бачите, якщо ви виконаєте команду `id` всередині контейнера. + +Ця абстракція обмежує те, що може трапитися, наприклад, якщо контейнер вдасться перетече на хост. Оскільки контейнер працює як не-привілейований користувач на хості, обмежено те, що він може зробити на хості. + +Крім того, оскільки користувачі в кожному Podʼі будуть зіставлені з різними користувачами на хості, обмежено те, що вони можуть зробити з іншими Podʼами. + +Можливості, надані Podʼу, також обмежуються простором користувача Podʼу і в основному є недійсними поза межами його простору, а деякі навіть абсолютно нечинні. Ось два приклади: + +* `CAP_SYS_MODULE` не має жодного ефекту, якщо зіставлено в Podʼі з використанням просторів користувачів, Pod не може завантажити модулі ядра. +* `CAP_SYS_ADMIN` обмежений простором користувача Podʼу та є недійсним поза його межами. + +Без використання просторів користувачів контейнер, який працює як root, у разі втечі контейнера, має привілеї root на вузлі. І якщо контейнеру надано деякі можливості, ці можливості є дійсними на хості. Цього не відбувається, коли ми використовуємо простори користувачів. + +Якщо ви хочете дізнатися більше подробиць про те, що змінюється при використанні просторів користувачів, дивіться `man 7 user_namespaces`. + +## Налаштування вузла для підтримки просторів користувачів {#set-up-a-node-to-support-user-namespaces} + +Рекомендується, щоб файли та процеси хосту використовували UID/GID в діапазоні від 0 до 65535. + +Kubelet призначить UID/GID вище цього для Podʼів. Таким чином, щоб +гарантувати максимальну ізоляцію, UID/GID, використовувані файлами +та процесами хосту, повинні бути в діапазоні від 0 до 65535. + +Зверніть увагу, що ця рекомендація є важливою для зменшення впливу CVE, такого як [CVE-2021-25741][CVE-2021-25741], де потенційно Pod може читати довільні файли на хостах. Якщо UID/GID Podʼу та хосту не перекриваються, обмежено те, що може зробити Pod: UID/GID Podʼа не збігається із власником/групою файлів хосту. + +[CVE-2021-25741]: https://github.com/kubernetes/kubernetes/issues/104980 + +## Інтеграція з перевірками безпеки доступу в Podʼи + +{{< feature-state state="alpha" for_k8s_version="v1.29" >}} + +Для Podʼів Linux, які увімкнули простори користувачів, Kubernetes послаблює застосування [Стандартів безпеки Podʼу](/docs/concepts/security/pod-security-standards) контрольованим способом. Цю поведінку можна контролювати за допомогою [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`UserNamespacesPodSecurityStandards`, що дозволяє раннє включення для кінцевих користувачів. Адміністраторам слід забезпечити увімкнення просторів користувачів на всіх вузлах в межах кластера при використанні feature gate. + +Якщо ви увімкнете відповідний feature gate та створите Pod, який використовує простори користувачів, yfcnegys поля не будуть обмежені навіть в контекстах, які застосовують _Baseline_ чи _Restricted_ Podʼа. Це не становить проблему безпеки, оскільки `root` всередині Podʼа з просторами користувачів фактично посилається на користувача всередині контейнера, який ніколи не зіставляється з привілейованим користувачем на хості. Ось список полів, які **не** перевіряються для Podʼів в цих обставинах: + +* `spec.securityContext.runAsNonRoot` +* `spec.containers[*].securityContext.runAsNonRoot` +* `spec.initContainers[*].securityContext.runAsNonRoot` +* `spec.ephemeralContainers[*].securityContext.runAsNonRoot` +* `spec.securityContext.runAsUser` +* `spec.containers[*].securityContext.runAsUser` +* `spec.initContainers[*].securityContext.runAsUser` +* `spec.ephemeralContainers[*].securityContext.runAsUser` + +## Обмеження {#limitations} + +При використанні просторів користувачів для Podʼа заборонено використовувати інші простори імен хосту. Зокрема, якщо ви встановите `hostUsers: false`, ви не маєте права встановлювати будь-яке з наступного: + +* `hostNetwork: true` +* `hostIPC: true` +* `hostPID: true` + +## {{% heading "whatsnext" %}} + +* Подивіться [Використання простору користувача в Podʼах](/docs/tasks/configure-pod-container/user-namespaces/) diff --git a/content/uk/docs/contribute/_index.md b/content/uk/docs/contribute/_index.md new file mode 100644 index 0000000000000..81b2af543dad1 --- /dev/null +++ b/content/uk/docs/contribute/_index.md @@ -0,0 +1,22 @@ +--- +content_type: concept +title: Беріть участь в розвитку Kubernetes +linkTitle: Участь +main_menu: true +no_list: true +weight: 80 +card: + name: contribute + weight: 10 + title: Беріть участь в розвитку Kubernetes +--- + + + +Існує багато способів як ви можете зробити власний внесок у розвиток Kubernetes. Ви можете працювати над створенням нових функцій, ви можете документувати код, який вже є, ви можете писати для нашого [блогу](/blog). А ще, ви можете реалізувати нові функції або виправляти помилки. Ви можете допомагати людям приєднатися до нашої спільноти або підтримувати учасників, які приєднались раніше. + +З усіма цими різними способами, що дозволяють зробити внесок у проєкт, ми в Kubernetes маємо спеціальний вебсайт: https://k8s.dev/. Ви можете перейти туди, щоб дізнатися більше про участь в розвитку Kubernetes. + +Якщо ви конкретно хочете дізнатися про покращення _цієї_ документації, прочитайте [Як покращити документацію Kubernetes](/docs/contribute/docs/). + +Ви також можете відвідати [сторінку](https://contribute.cncf.io/contributors/projects/#kubernetes) {{< glossary_tooltip text="CNCF" term_id="cncf" >}}, присвячену участі в проєкті Kubernetes. diff --git a/content/uk/docs/contribute/docs.md b/content/uk/docs/contribute/docs.md new file mode 100644 index 0000000000000..604676bb26136 --- /dev/null +++ b/content/uk/docs/contribute/docs.md @@ -0,0 +1,158 @@ +--- +content_type: concept +title: Покращення документації Kubernetes +weight: 09 +card: + name: contribute + weight: 11 + title: Розбудова документації +--- + +Цей вебсайт обслуговується [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs). Проєкт Kubernetes вітає допомогу від усіх учасників, незалежно від їхнього досвіду! + +Учасники, які мають намір працювати з документацією Kubernetes можуть: + +- Вдосконалювати наявний вміст +- Створювати новий вміст +- Перекладати документацію +- Керувати та публікувати документацію під час релізного циклу Kubernetes + +--- + +{{< note >}} +Щоб дізнатися більше про те, як зробити свій внесок в Kubernetes загалом, перегляньте загальний сайт [Документація учасника](https://www.kubernetes.dev/docs/). +{{< /note >}} + + + +## Початок роботи {#getting-started} + +Будь-хто може відкрити тікет щодо документації або внести зміни через запит на злиття (PR) в [репозиторій GitHub `kubernetes/website`](https://github.com/kubernetes/website). Для ефективної роботи в спільноті Kubernetes вам слід вміти працювати з +[git](https://git-scm.com/) та [GitHub](https://skills.github.com/). + +Для того, щоб долучитись до роботи з документацією: + +1. Ознайомтесь та підпишіть CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md). +2. Ознайомтесь з [репозиторієм документації](https://github.com/kubernetes/website) та вебсайтом-генераторм [статичних вебсайтів](https://gohugo.io). +3. Переконайтесь, що ви розумієте базові вимоги щодо [відкриття запиту на злиття](/docs/contribute/new-content/open-a-pr/) та [перегляду змін](/docs/contribute/review/reviewing-prs/). + + + + +{{< mermaid >}} +flowchart TB +subgraph third[Створення PR] +direction TB +U[ ] -.- +Q[Зробіть покращення] --- N[Створіть новий
вміст] +N --- O[Перекладіть
документацію] +O --- P[Керуйте/Публікуйте документацію
релізного циклу K8s] + +end + +subgraph second[Огляд] +direction TB + T[ ] -.- + D[Огляньте репозиторій
kubernetes/website] --- E[Ознайомтесь з
генератором статичних
сайтів Hugo] + E --- F[Онвіть відомості про
основні команди GitHub] + F --- G[Робіть огляд
відкритих PR
та змін] +end + +subgraph first[Реєстрація] + direction TB + S[ ] -.- + B[Підпишіть CNCF
Contributor
License Agreement] --- C[Приєднайтесь до
каналу sig-docs
в Slack] + C --- V[Приєднайтесь до
списку розсилки
kubernetes-sig-docs] + V --- M[Відвідуйте тижневі
заходи sig-docs
чи зустрічі в slack] +end + +A([fa:fa-user Новий
учасник]) --> first +A --> second +A --> third +A --> H[Ставте питання!!!] + + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey +class S,T,U spacewhite +class first,second,third white +{{}} +Схема 1. Початок роботи для нового учасника. + +На схемі 1 зображено шлях для нового учасника. Ви можете виконати деякі або всі етапи для `Реєстрації` та `Огляду`. Тепер ви готові відкривати PR (запити на злиття), щоб досягти своїх цілей, деякі з яких перелічені в `Створення PR`. Знову ж таки, не соромтесь ставити питання, питання завжди вітаються! + +Деякі завдання вимагають більшого рівня довіри та більшого доступу в організації Kubernetes. Докладнішу інформацію щодо ролей та дозволів дивіться в розділі [Участь в SIG Docs](/docs/contribute/participate/). + +## Ваш перший внесок {#your-first-contribution} + +Ви можете підготуватися до свого першого внеску, розглянувши кілька кроків перед тим. Схема 2 описує кроки, а опис міститься далі. + + + + +{{< mermaid >}} +flowchart LR + subgraph second[Перший внесок] + direction TB + S[ ] -.- + G[Зробіть огляд PR
від інших учасників K8s] --> + A[Ознайомтесь з переліком тікетів
на kubernetes/website
щоб знайти відповідний перший PR] --> B[Створіть PR!!] + end + subgraph first[Підготовчі кроки] + direction TB + T[ ] -.- + D[Ознайомтесь з описом внеску] -->E[Ознайомтесь з настановами
щодо вмісту та стилю K8s] + E --> F[Дізнайтесь про типи вмісту
сторінок Hugo та
їх скорочення] + end + + + first ----> second + + +classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; +classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class A,B,D,E,F,G grey +class S,T spacewhite +class first,second white +{{}} +Схема 2. Підготовка до перших пропозицій. + +- Прочитайте [Як робити внесок](/docs/contribute/new-content/), щоб дізнатися про різні способи, якими ви можете зробити свій внесок. +- Ознайомтесь зі списком тікетів на [`kubernetes/website`](https://github.com/kubernetes/website/issues/) на предмет наявності питань, які можуть бути гарними точками входу. +- [Відкрийте запит на злиття на GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github) до навної документації та дізнайтеся більше про створення тікетів на GitHub. +- [Рецензуйте запити на злиття](/docs/contribute/review/reviewing-prs/) від інших учасників спільноти Kubernetes на предмет точності та мови. +- Прочитайте поради щодо [вмісту](/docs/contribute/style/content-guide/) та [стилю](/docs/contribute/style/style-guide/) Kubernetes, щоб залишати обґрунтовані коментарі. +- Дізнайтеся про [типи вмісту сторінок](/docs/contribute/style/page-content-types/) та [скорочення Hugo](/docs/contribute/style/hugo-shortcodes/). + +## Отримання допомоги щодо участі {#getting-help-with-contributing} + +Ваш перший внесок може бути приголомшливим. [Помічники для нових учасників](https://github.com/kubernetes/website#new-contributor-ambassadors) (New Contributor Ambassador) готові провести вас через створення вашого першого внеску. Ви можете звертатися до них в [Slack Kubernetes](https://slack.k8s.io/), переважно в каналі `#sig-docs`. Також є [Зустріч та привітання нових учасників](https://www.kubernetes.dev/resources/calendar/), яка відбувається першого вівторка кожного місяця. Ви можете спілкуватися з помічниками для нових учасників та отримати відповіді на свої запитання там. + +## Наступні кроки {#next-steps} + +- Навчіться [працювати з локальним клоном](/docs/contribute/new-content/open-a-pr/#fork-the-repo) репозиторію. +- Документуйте [функції у випуску](/docs/contribute/new-content/new-features/). +- Беріть участь в [SIG Docs](/docs/contribute/participate/) і станьте [учасником або рецензентом](/docs/contribute/participate/roles-and-responsibilities/). +- Розпочинайте або допомагайте з [локалізацією](/docs/contribute/localization/). + +## Приєднуйтеся до SIG Docs {#get-involved-with-sig-docs} + +[SIG Docs](/docs/contribute/participate/) — це група учасників, які +публікують та підтримують документацію Kubernetes та цей вебсайт. Участь в SIG Docs – це гарний спосіб для учасників Kubernetes (розробка функцій чи інша) зробити значний внесок у проєкт Kubernetes. + +SIG Docs спілкується за допомогою різних інструментів: + +- [Приєднуйтесь до `#sig-docs` в Kubernetes Slack](https://slack.k8s.io/). Обовʼязково представте себе! +- [Приєднуйтесь до списку розсилки `kubernetes-sig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), де відбуваються ширші обговорення та записуються офіційні рішення. +- Приєднуйтесь до [відеозустрічей SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) щотижня. Зустрічі завжди оголошуються в `#sig-docs` та додаються до [календаря зустрічей спільноти Kubernetes](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). Вам слід завантажити [клієнт Zoom](https://zoom.us/download) або долучитися за допомоги телефону. +- Приєднуйтесь до асинхронних зустрічуей в Slack SIG Docs в ті тижні, коли відбувається відеозустріч віч-на-віч. Зустрічі завжди оголошуються в `#sig-docs`. Ви можете зробити внесок до будь-якого з тредів протягом 24 годин після оголошення зустрічі. + +## Інші способи зробити внесок {#other-ways-to-contribute} + +- Відвідайте [сайт спільноти Kubernetes](/community/). Беріть участь в Twitter або Stack Overflow, дізнайтеся про місцеві зустрічі та події Kubernetes та інше. +- Прочитайте [шпаргалку для учасників](https://www.kubernetes.dev/docs/contributor-cheatsheet/) для участі у розробці функцій Kubernetes. +- Відвідайте сайт учасника, щоб дізнатися більше про [учасників Kubernetes](https://www.kubernetes.dev/) та [додаткові ресурси для учасників](https://www.kubernetes.dev/resources/). +- Пишіть [пости в блог або в приклади використання](/docs/contribute/new-content/blogs-case-studies/). diff --git a/content/uk/docs/contribute/localization.md b/content/uk/docs/contribute/localization.md new file mode 100644 index 0000000000000..7e2a0dfb58ef6 --- /dev/null +++ b/content/uk/docs/contribute/localization.md @@ -0,0 +1,386 @@ +--- +title: Локалізація документації Kubernetes +content_type: concept +approvers: +- remyleone +- rlenferink +weight: 50 +card: + name: contribute + weight: 50 + title: Локазізація документації +--- + + + +Ця сторінка містить приклади [локалізації](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) документації Kubernetes різними мовами. + + + +## Покращення наявної локалізації {#contribute-to-an-existing-localization} + +Ви можете допомогти додати або покращити вміст наявної локалізації. У [Slack Kubernetes](https://slack.k8s.io/), ви можете знайти канал для кожної локалізації. Також є загальний [канал SIG Docs Localizations](https://kubernetes.slack.com/messages/sig-docs-localizations), де ви можете привітатись. + +{{< note >}} +За додатковою інформацією про те, як допомогти з певною локалізацією, шукайте локалізовану версію цієї сторінки. +{{< /note >}} + +### Визначте дволітерний код вашої мови {#find-your-two-letter-language-code} + +Звіртесь зі [стандартом ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php), щоб знайти дволітерний код вашої мови. Наприклад, дволітерний код для української мови — `uk`. + +Деякі мови використовують версію коду країни у нижньому регістрі, як визначено стандартом ISO-3166, разом з їх мовними кодами. Наприклад, код бразильської португальської мови — `pt-br`. + +### Зробіть форк та клонуйте репозиторій {#fork-and-clone-the-repo} + +Спочатку, [зробіть форк](/docs/contribute/new-content/open-a-pr/#fork-the-repo) репозиторію [kubernetes/website](https://github.com/kubernetes/website). + +Потім клонуйте його собі на компʼютер та перейдіть в локальну теку: + +```shell +git clone https://github.com//website +cd website +``` + +Вміст сайту включає підтеки для кожної мови. Для локалізації, вам потрібно змінювати вміст в підтеках `content/`. + +### Пропонуйте зміни {#suggest-changes} + +Створіть або оновіть вибрану локалізовану сторінку на основі англійського оригіналу. Дивіться розділ [Локалізація вмісту](#localize-content) для отримання додаткових вказівок. + +Якщо ви помітили якійсь технічні неточності або інші проблеми з англійською документацією, ви повинні спочатку виправити англійську документацію, а потім повторити відповідні зміни, оновивши локалізацію, над якою ви працюєте. + +Обмежте зміни в пул-реквесті однією локалізацією. Розгляд змін, які змінюють вміст у кількох локалізаціях, є проблематичним. + +Слідуйте рекомендаціям [Пропонування покращення вімісту](/docs/contribute/suggesting-improvements/) для пропозиції змін у вмісті локалізації. Це процес подібний до пропозиції змін в оригінальний вміст (англійською мовою). + +## Створення нової локалізації {#start-a-new-localization} + +Якщо ви хочете мати документацію Kubernetes вашою мовою, ось що вам потрібно зробити. + +Оскільки учасники не можуть схвалювати свої власні пул-реквести, вам потрібно *принаймні два учасники* для початку локалізації. + +Всі команди локалізації повинні бути самостійними. Вебсайт Kubernetes радий опублікувати вашу роботу, але вам потрібно перекладати вміст і підтримувати наявний локалізований вміст. + +Вам потрібно зʼясувати дволітерний код вашої мови. Зверніться до [стандарту ISO 639-1](https://www.loc.gov/standards/iso639-2/php/code_list.php), щоб знайти дволітерний код вашої мови. Наприклад, дволітерний код для української мови — `uk`. + +Якщо мова, для якої ви починаєте локалізацію, використовується в різних місцях зі значними відмінностями між варіантами, можливо, має сенс поєднати дволітерний код країни з дволітерним кодом мови. Наприклад, бразильська португальська позначається як `pt-br`. + +Коли ви починаєте нову локалізацію, вам потрібно локалізувати [мінімально необхідний вміст](#minimum-required-content) перед тим, як проєкт Kubernetes зможе опублікувати ваші зміни на сайті. + +SIG Docs може допомогти вам з роботою в окремій гілці, щоб ви могли поступово працювати для досягнення цієї мети. + +### Пошук спільноти {#find-community} + +Дайте знати команді документації Kubernetes, що ви зацікавлені в створенні локалізації! Приєднуйтесь до [каналу Slack SIG Docs](https://kubernetes.slack.com/messages/sig-docs) та [каналу Slack SIG Docs Localizations](https://kubernetes.slack.com/messages/sig-docs-localizations). Інші команди локалізації будуть раді допомогти вам почати та відповісти на ваші питання. + +Розгляньте, будь ласка, можливість участі в [зустрічі підгрупи локалізації SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs). Місією підгрупи локалізації SIG Docs є співпраця з командами локалізації SIG Docs з метою спільного визначення та документування процесів створення локалізованих посібників. Крім того, підгрупа локалізації SIG Docs розглядає можливості створення та обміну загальними інструментами серед команд локалізації та визначення нових вимог для команди керівників SIG Docs. Якщо у вас є питання щодо цього засідання, будь ласка, запитуйте на +[каналі Slack SIG Docs Localizations](https://kubernetes.slack.com/messages/sig-docs-localizations). + +Ви також можете створити канал Slack для своєї локалізації в +репозиторії `kubernetes/community`. Для прикладу, як додавати канал в Slack, див. PR для +[додавання каналу для перської мови](https://github.com/kubernetes/community/pull/4980). + +### Приєднуйтесь до організації Kubernetes на GitHub {#join-the-kubernetes-github-organization} + +Коли ви відкрили PR для локалізації, ви можете стати учасниками організації Kubernetes. Кожна особа в команді повинна створити свій власний [Запит на членство в організації](https://github.com/kubernetes/org/issues/new/choose) у репозиторії `kubernetes/org`. + +### Додайте свою команду локалізації на GitHub {#add-your-localization-team-in-github} + +Далі, додайте свою команду локалізації Kubernetes в +[`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/main/config/kubernetes/sig-docs/teams.yaml). Для прикладу додавання команди локалізації, див. PR для додавання +[іспанської команди локалізації](https://github.com/kubernetes/org/pull/685). + +Члени `@kubernetes/sig-docs-**-owners` можуть схвалювати PR, які змінюють вміст в межах (і лише в межах) вашої теки локалізації: `/content/**/`. Для кожної локалізації команда `@kubernetes/sig-docs-**-reviews` автоматизує додавання рецензій для нових PR. Члени `@kubernetes/website-maintainers` можуть створювати нові гілки локалізації для координації зусиль з перекладу. Члени `@kubernetes/website-milestone-maintainers` можуть використовувати команду [Prow](https://prow.k8s.io/command-help) `/milestone` для призначення віхи завдання чи PR. + +### Налаштування робочого процесу {#configure-the-workflow} + +Далі, додайте мітку GitHub для вашої локалізації в репозиторії `kubernetes/test-infra`. Мітка дозволяє вам фільтрувати завдання та пул-реквести для вашої мови. + +Приклад додавання мітки для [італійської мови](https://github.com/kubernetes/test-infra/pull/11316). + +### Зміна конфігурації сайту {#modify-the-site-configuration} + +Вебсайт Kubernetes використовує Hugo для обслуговування вмісту. Конфігурація вебсайту знаходиться в файлі [`hugo.toml`](https://github.com/kubernetes/website/tree/main/hugo.toml). Вам потрібно внести зміни у `hugo.toml` для увімкнення підтримки нової локалізації. + +Додайте блок конфігурації для нової мови до `hugo.toml` в блок `[languages]`. Наприклад, блок для німецької мови виглядає так: + +```toml +[languages.de] +title = "Kubernetes" +description = "Produktionsreife Container-Verwaltung" +languageName = "Deutsch (German)" +languageNameLatinScript = "Deutsch" +contentDir = "content/de" +weight = 8 +``` + +Змінна `languageName` містить назву мови, яка показується в панелі вибору мови. Вкажіть у `languageName` назву в форматі "назва мови вашою мовою (назва мови англійською мовою)". Наприклад, `languageName = "한국어 (Korean)"` або `languageName = "Deutsch (German)"`. + +`languageNameLatinScript` може використовуватись для доступу до мови латиницею та використовувати в темах. Вкажіть "назва мови латиною" у `languageNameLatinScript`. Наприклад, `languageNameLatinScript = "Korean"` або `languageNameLatinScript = "Deutsch"`. + +Параметр `weight` визначає порядок мов у панелі вибору мови. Менше значення `weight` має пріоритет, що призводить до того, що мова показується першою. Призначаючи параметр `weight`, важливо ретельно ознайомитись з наявними блоками мов та змінити їх вагу, щоб вони були впорядковані відносно всіх мов, включаючи будь-які нові мови. + +Для отримання додаткової інформації щодо багатомовної підтримки Hugo дивіться "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)". + +### Додавання нової теки локалізації {#add-a-new-localization-directory} + +Додайте теку для вашої мови в теку +[`content`](https://github.com/kubernetes/website/tree/main/content) в репозиторії. Наприклад, дволітерний код для німецької мови — `de`: + +```shell +mkdir content/de +``` + +Також потрібно створити теку всередині `data/i18n` для +[локалізованих рядків](#site-strings-in-i18n); перегляньте наявні локалізації для прикладу. Для використання цих нових рядків, вам також потрібно створити символічне посилання +з `i18n/<локалізація>.toml` на фактичну конфігурацію рядків у +`data/i18n/<локалізація>/<локалізація>.toml` (не забудьте додати символічне посилання в коміт). + +Наприклад, для німецької мови рядки знаходяться в `data/i18n/de/de.toml`, і `i18n/de.toml` — це символічне посилання на `data/i18n/de/de.toml`. + +### Локалізуйте community code of conduct {#localize-community-code-of-conduct} + +Створіть пул-реквест в репозиторії [`cncf/foundation`](https://github.com/cncf/foundation/tree/main/code-of-conduct-languages) для додавання правил спільноти вашою мовою. + +### Створіть файли OWNERS {#set-up-the-owners-files} + +Для призначення ролей кожному учаснику, який вносить внесок у локалізацію, створіть файл `OWNERS` всередині підтеки, яка відповідає вашій мові, з таким вмістом + +- **reviewers**: Перелік команд kubernetes з роллю рецензентів + - команду `sig-docs-**-reviews` створену на кроці [Додайте свою команду локалізації на GitHub](#add-your-localization-team-in-github). +- **approvers**: Перелік команд kubernetes з роллю, що може затверджувати зміни, в цьому випадку + - команду `sig-docs-**-owners` створену на кроці [Додайте свою команду локалізації на GitHub](#add-your-localization-team-in-github). +- **labels**: Перелік міток, які автоматично додаються до пул-реквестів, в цьому випадку, мітки створені на етапі [Налаштування робочого процесу](#configure-the-workflow). + +Докладніше про файл `OWNERS` дивіться — +[go.k8s.io/owners](https://go.k8s.io/owners). + +Для прикладу [файл Spanish OWNERS](https://git.k8s.io/website/content/es/OWNERS), з кодом мови `es`, виглядає так: + +```yaml +# See the OWNERS docs at https://go.k8s.io/owners + +# This is the localization project for Spanish. +# Teams and members are visible at https://github.com/orgs/kubernetes/teams. + +reviewers: +- sig-docs-es-reviews + +approvers: +- sig-docs-es-owners + +labels: +- language/es +``` + +Після додавання файлу `OWNERS` для вашої мови, оновіть [кореневий файл `OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES) новою командою Kubernetes для локалізації, `sig-docs-**-owners` та `sig-docs-**-reviews`. + +Для кожної команди додайте список користувачів GitHub, які потрібні на етапі [Додайте свою команду локалізації на GitHub](#add-your-localization-team-in-github), в алфавітному порядку. + +```diff +--- a/OWNERS_ALIASES ++++ b/OWNERS_ALIASES +@@ -48,6 +48,14 @@ aliases: + - stewart-yu + - xiangpengzhao + - zhangxiaoyu-zidif ++ sig-docs-es-owners: # Admins for Spanish content ++ - alexbrand ++ - raelga ++ sig-docs-es-reviews: # PR reviews for Spanish content ++ - alexbrand ++ - electrocucaracha ++ - glo-pena ++ - raelga + sig-docs-fr-owners: # Admins for French content + - perriea + - remyleone +``` + +### Створіть пул-реквест {#open-a-pull-request} + +Далі, [створіть пул-реквест](/docs/contribute/new-content/open-a-pr/#open-a-pr) (PR) для додавання локалізації в репозиторій `kubernetes/website`. PR повинен містити [мінімально необхідний вміст](#minimum-required-content) перед тим, як він може бути схваленим. + +Наприклад додавання нової локалізації для [французької мови](https://github.com/kubernetes/website/pull/12548). + +### Додайте локалізований файл README {#add-a-localized-readme-file} + +Щоб керувати іншими учасниками локалізації, додайте новий +[`README-**.md`](https://help.github.com/articles/about-readmes/) в корінь репозиторію [kubernetes/website](https://github.com/kubernetes/website/), де `**` — дволітерний код мови. Наприклад, файл README для української мови буде `README-uk.md`. + +Скеровуйте учасників локалізації до локалізованого файлу `README-**.md`. Додайте туди ту ж інформацію, що міститься в `README.md`, а також: + +- Контактну інформацію проєкту локалізації +- Будь-яку інформацію, специфічну для локалізації + +Після створення локалізованого README, додайте посилання на файл у головний англійський `README.md`, а також включіть контактну інформацію англійською мовою. Ви можете надати ідентифікатор GitHub, адресу електронної пошти, [канал Slack](https://slack.com/) або інший метод звʼязку. Ви також повинні надати посилання на локалізований Кодекс поведінки спільноти. + +### Запуск вашої нової локалізації {#launch-your-new-localization} + +Коли локалізація відповідає вимогам для робочого процесу та мінімальним вимогам щодо вмісту, SIG Docs робить наступне: + +- Вмикає на вебсайті відповідний мовний розділ. +- Сповіщає про наявність локалізованого вмісту через канали [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF), включаючи [блог Kubernetes](/blog/). + +## Локалізація вмісту {#localize-content} + +Локалізація вмісту *всього* вмісту Kubernetes є неосяжним завданням. Необхідно починати з мінімально необхідного вмісту та поступово розширювати його. + +### Мінімально необхідний вміст {#minimum-required-content} + +Як мінімум, всі локалізації мають містити: + +Опис | Посилання +-----|---------- +Документація | [Всі заголовки та підзаголовки](/docs/home/) +Початок роботи | [Всі заголовки та підзаголовки](/docs/setup/) +Посібники | [Основи Kubernetes](/docs/tutorials/kubernetes-basics/), [Привіт Minikube](/docs/tutorials/hello-minikube/) +Локалізація сайту | [Всі рядки](#site-strings-in-i18n) в новому TOML файлі локалізації +Випуски | [Всі заголовки та підзаголовки](/releases) + +Перекладена документація має знаходитись у власній підтеці `content/**/` та мати ту ж URL-структуру, що й англійська версія. Наприклад, щоб підготувати [Основи Kubernetes](/docs/tutorials/kubernetes-basics/) для перекладу німецькою мовою, створіть підтеку у `content/de` та скопіюйте в неї сирці англійської версії: + +```shell +mkdir -p content/de/docs/tutorials +cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md +``` + +Інструменти для роботи з перекладами значно прискорюють процес перекладу. Наприклад, деякі редактори пропонують втулки для швидкого перекладу тексту. + +{{< caution >}} +Машино-генерований переклад недостатній сам по собі. Локалізація вимагає ретельного перегляду людиною, щоб вміст відповідав мінімальним стандартам якості. +{{< /caution >}} + +Щоб переконатись в точності та відповідності перекладу, члени вашої команди локалізації повинні ретельно переглянути всі машинно-генеровані переклади перед публікацією. + +### Локалізація зображень SVG {#localize-svg-images} + +Проєкт Kubernetes рекомендує використовувати векторні (SVG) зображення, де це можливо, оскільки їх набагато легше редагувати командам локалізації. Якщо ви знаходите растрове зображення, яке потрібно локалізувати, розгляньте можливість спочатку перетворення англійської версії у векторне зображення, а потім локалізуйте його. + +При перекладі тексту всередині векторних зображень (SVG — Scalable Vector Graphics) важливо дотримуватися певних рекомендацій, щоб забезпечити точність і підтримувати однорідність між різними мовними версіями. Зображення SVG часто використовуються в документації Kubernetes для ілюстрації концепцій, робочих процесів та схем. + +1. **Визначення тексту для перекладу**: + Почніть з ідентифікації текстових елементів всередині SVG-зображення, які потрібно перекласти. Зазвичай до цих елементів входять мітки, підписи, анотації чи будь-який текст, що передає інформацію. + +2. **Редагування файлів SVG**: + Файли SVG базуються на XML, що означає, що їх можна редагувати за допомогою текстового редактора. Проте важливо враховувати, що більшість зображень в документації Kubernetes вже конвертують текст в криві, щоб уникнути проблем сумісності шрифтів. У таких випадках рекомендується використовувати спеціалізоване програмне забезпечення для редагування SVG, таке як Inkscape. Відкрийте файл SVG у програмі Inkscape та знайдіть елементи тексту, які потребують перекладу. + +3. **Переклад текстів**: + Замініть оригінальний текст перекладеною версією бажаною мовою. Переконайтеся, що перекладений текст точно виражає задумане значення і вміщується у вільне простір у зображенні. При роботі з мовами, які використовують латинський алфавіт, слід використовувати сімʼю шрифтів Open Sans. Ви можете завантажити шрифт Open Sans за цим посиланням: [Open Sans Typeface](https://fonts.google.com/specimen/Open+Sans). + +4. **Перетворення тексту в криві**: + Як вже зазначалося, для розв'язання проблеми сумісності шрифтів рекомендується конвертувати перекладений текст в криві. Конвертація тексту в криві гарантує правильне відображення перекладеного тексту у кінцевому зображенні, навіть якщо система користувача не має шрифту, використаного в оригінальному SVG. + +5. **Перегляд та тестування**: + Після перекладу і конвертації тексту в криві, збережіть та перегляньте оновлене SVG-зображення, щоб переконатися, що текст правильно показується та відповідно вирівняний. Виконайте [Попередній перегляд ваших змін локально](/docs/contribute/new-content/open-a-pr/#preview-locally). + +### Файли сирців {#source-files} + +Локалізація має базуватись на файлах англійською мовою з конкретного релізу, на який спрямовані зусилля команди локалізації. Кожна команда локалізації може визначити, на який реліз спрямовані її зусилля, що позначено нижче як _цільова версія_. + +Для пошуку файлів сирців для цільової версії: + +1. Перейдіть до репозиторію вебсайту Kubernetes + https://github.com/kubernetes/website. + +1. Оберіть гілку з вашою цільовою версією користуючись таблицею: + +Цільова версія | Гілка +-----|----- +Остання версія | [`main`](https://github.com/kubernetes/website/tree/main) +Попередня версія | [`release-{{< skew prevMinorVersion >}}`](https://github.com/kubernetes/website/tree/release-{{< skew prevMinorVersion >}}) +Наступна версія | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}}) + +Гілка `main` містить вміст для поточного релізу `{{< latest-version >}}`. Команда релізу створює гілку `{{< release-branch >}}` перед наступним релізом: v{{< skew nextMinorVersion >}}. + +### Рядки сайту в i18n {#site-strings-in-i18n} + +Локалізація має включати вміст [`data/i18n/en/en.toml`](https://github.com/kubernetes/website/blob/main/data/i18n/en/en.toml) у новому файлі для відповідної мови. Наприклад, для німецької мови: `data/i18n/de/de.toml`. + +Додайте нову теуку для локалізації та файл до `data/i18n/`. Наприклад, для німецької мови (`de`): + +```bash +mkdir -p data/i18n/de +cp data/i18n/en/en.toml data/i18n/de/de.toml +``` + +Ознайомтесь з коментарями вгорі файлу, щоб зрозуміти, які рядки потрібно локалізувати. Наприклад, це німецькомовний текст-заповнювач для поля пошуку: + +```toml +[ui_search_placeholder] +other = "Suchen" +``` + +Локалізовані рядки сайту дозволяють вам налаштувати текстові рядки, які використовуються в багатьох місцях на сайті. Наприклад, текст копірайту в підвалі на кожній сторінці. + +### Настанови щодо локалізації певною мовою {#language-specific-localization-guide} + +Як команда локалізації, ви можете формалізувати найкращі практики, які використовує ваша команда, створивши мовно-специфічний посібник з локалізації. + +Наприклад, див. [Корейський посібник з локалізації](/ko/docs/contribute/localization_ko/), який включає опис таких тем, як: + +- Частота спринтів та релізи +- Стратегія створення гілок +- Робота з pull request +- Посібник зі стилю +- Глосарій локалізованих та нелокалізованих термінів +- Конвенції Markdown +- Термінологія обʼєктів Kubernetes API + +### Зустрічі в Zoom для обговорення локалізації відповідною мовою {#language-specific-zoom-meetings} + +Якщо проєкту з локалізації потрібен окремий час на зустрічі, звʼяжіться з одним з координаторів SIG Docs або Tech Lead, щоб створити нову регулярну зустріч в Zoom та запрошення в календар. Це потрібно тільки тоді, коли команда достатньо велика та вимагає окремих зустрічей. + +Відповідно до правил CNCF, команди локалізації повинні завантажувати свої зустрічі в плейлист YouTube SIG Docs. Координатор SIG Docs або Tech Lead може допомогти з цим процесом до тих пір, поки SIG Docs не автоматизує його. + +## Стратегія створення гілок {#branch-strategy} + +Оскільки проєкти локалізації є зусиллями кількох осіб, ми закликаємо команди працювати в спільних гілках локалізації, особливо на початковому етапі, коли локалізація ще не є оприлюдненою. + +Щоб співпрацювати в гілці локалізації: + +1. Член команди [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) створює гілку локалізації з гілки основного проєкту + . + + Особи з вашої команди, які затверджують зміни, приєднуються до команди `@kubernetes/website-maintainers`, коли ви [створюєте свою команду локалізації](#add-your-localization-team-in-github) до репозиторію [`kubernetes/org`](https://github.com/kubernetes/org). + + Ми радимо наступну схему найменування гілок: + + `dev--.` + + Наприклад, затверджувач зміни німецької команди створює гілку для локалізації `dev-1.12-de.1` безпосередньо в репозиторії `kubernetes/website`, яка базується на гілці для Kubernetes v1.12. + +2. Індивідуальні учасники створюють гілки-теми на основі гілки локалізації. + + Наприклад, учасник німецькою команди створює пул-реквест зі змінами у `kubernetes:dev-1.12-de.1` з `username:local-branch-name`. + +3. Затверджувач переглядає зміни та зливає гілку-тему в гілку локалізації. + +4. Періодично затверджувач обʼєднує гілку локалізації зі своєю вихідною гілкою, відкриваючи та затверджуючи новий pull request. Обовʼязково обʼєднуйте (squash) коміти перед затвердженням pull request. + +Повторюйте кроки 1-4 за потреби, поки локалізація не буде завершена. Наприклад, наступні гілки локалізації німецькою мовою будуть: `dev-1.12-de.2`, `dev-1.12-de.3` і т.д. + +Команди повинні обʼєднувати локалізований вміст у ту гілку, з якої вміст було отримано. Наприклад: + +- Гілку локалізації створену з гілки `main` потрібно заливати у гілку `main`. +- Гілку локалізації створену з `release-{{% skew "prevMinorVersion" %}}` потрібно заливати у `release-{{% skew "prevMinorVersion" %}}`. + +{{< note >}} +Якщо ваша гілка локалізації була створена з гілки `main`, але її не обʼєднано з `main` до створення нової гілки релізу `{{< release-branch >}}`, обʼєднайте її як з `main`, так і з новою гілкою релізу `{{< release-branch >}}`. Для обʼєднання гілки локалізації з новою гілкою релізу `{{< release-branch >}}` потрібно змінити вищезазначену гілку вашої локалізації на гілку `{{< release-branch >}}`. +{{< /note >}} + +На початку кожного етапу команді корисно відкрити тікет для порівняння змін вверх між попередньою гілкою локалізації та поточною гілкою. Є два скрипти для порівняння змін. + +- [`upstream_changes.py`](https://github.com/kubernetes/website/tree/main/scripts#upstream_changespy) + є корисним для перевірки змін, що були зроблені у відповідному файлі, та +- [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/main/scripts#diff_l10n_branchespy) + є корисним для створення переліку застарілих файлів для відповідної гілки локалізації. + +Хоча тільки затверджувачі можуть створювати нові гілки локалізації та обʼєднувати пул-реквести, будь-хто може відкрити пул-реквести для нової гілки локалізації. Для цього спеціальні дозволи не потрібні. + +Для отримання додаткової інформації про роботу з форками або безпосередньо з репозиторієм, див. ["розгалуження та клонування репозиторію"](#fork-and-clone-the-repo). + +## Внесення змін до оригінальної документації {#upstream-contributions} + +Команда SIG Docs вітає внески та виправлення до англійської версії документації. diff --git a/content/uk/docs/contribute/localization_uk.md b/content/uk/docs/contribute/localization_uk.md index 5675a61391773..2bd0d87aa950a 100644 --- a/content/uk/docs/contribute/localization_uk.md +++ b/content/uk/docs/contribute/localization_uk.md @@ -1,6 +1,11 @@ --- -title: Рекомендації з перекладу українською мовою content_type: concept +title: Рекомендації з перекладу українською мовою +weight: 130 +card: + name: contribute + weight: 100 + title: Рекомендації з перекладу українською мовою anchors: - anchor: "#правила-перекладу" title: Правила перекладу @@ -10,52 +15,48 @@ anchors: -Дорогі друзі! Раді вітати вас у спільноті українських контриб'юторів проекту Kubernetes. Ця сторінка створена з метою полегшити вашу роботу при перекладі документації. Вона містить правила, якими ми керувалися під час перекладу, і базовий словник, який ми почали укладати. Перелічені у ньому терміни ви знайдете в українській версії документації Kubernetes. Будемо дуже вдячні, якщо ви допоможете нам доповнити цей словник і розширити правила перекладу. +Дорогі друзі! Раді вітати вас у спільноті українських учасників проєкту Kubernetes. Ця сторінка створена з метою полегшити вашу роботу в роботі з перекладу документації. Вона містить правила, якими ми керувалися під час перекладу, і базовий словник, який ми почали укладати. Перелічені у ньому терміни ви знайдете в українській версії документації Kubernetes. Будемо дуже вдячні, якщо ви допоможете нам доповнити цей словник і розширити правила перекладу. Сподіваємось, наші рекомендації стануть вам у пригоді. - - ## Загальний процес -1. Виберіть одне з [найбільш витребуваних ішьюзів](https://github.com/kubernetes-i18n-ukrainian/website/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+no%3Aassignee+label%3A%22most+wanted%22) або [будь-яке ішью](https://github.com/kubernetes-i18n-ukrainian/website/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+no%3Aassignee) і залиште в ньому коментар на кшталт "Працюю над цим". Ми надішлемо вам запрошення до організації та закріпимо цей ішьюз за вами. -2. Зробіть форк [k/website](https://github.com/kubernetes/website). -3. Прочитайте цей документ. -4. Перекладіть -5. Створіть пул-реквест в [k/website](https://github.com/kubernetes/website). - -Якщо вам знадобиться допомога, зареєструйтеся в [Slack Kubernetes](https://slack.k8s.io/), приєднайтеся до каналу [`#kubernetes-docs-uk`](https://kubernetes.slack.com/archives/CSKCYN138) і спитайте там. - -### Отримання допомоги -Якщо ви виявили проблеми з перекладеним вмістом, [створіть проблему на k/website](https://github.com/kubernetes/website/issues/new/choose) за допомогою `/language uk`. - -[kubernetes-i18n-ukrainian/website](https://github.com/kubernetes-i18n-ukrainian/website) слід використовувати лише для спрощення процесу локалізації. +1. Виберіть одне з [найбільш нагальних завдань](https://github.com/kubernetes-i18n-ukrainian/website/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+no%3Aassignee+label%3A%22most+wanted%22) або [будь-яке інше](https://github.com/kubernetes-i18n-ukrainian/website/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+no%3Aassignee) і залиште в ньому коментар на кшталт "Працюю над цим". Ми надішлемо вам запрошення до організації та закріпимо його за вами. +2. Клонуйте (зробіть форк) репозиторію [kubernetes/website](https://github.com/kubernetes/website). +3. Ознайомтесь з цим документом. +4. Зробіть переклад +5. Створіть пул-реквест в [kubernetes/website](https://github.com/kubernetes/website). -### Існуючі проблеми/оновлення локалізації +Якщо вам знадобиться допомога, зареєструйтеся в [Slack Kubernetes](https://slack.k8s.io/), приєднайтеся до каналу[`#kubernetes-docs-uk`](https://kubernetes.slack.com/archives/CSKCYN138) та спитайте там. -Якщо ви виявили проблеми з перекладеним вмістом і не можете негайно їх виправити, [створіть ішью у k/website](https://github.com/kubernetes/website/issues/new/choose) з описом що не так, на якій сторінці (посилання) і додайте в опис ішью з нового рядка `/language uk`. +### Отримання допомоги -[kubernetes-i18n-ukrainian/website](https://github.com/kubernetes-i18n-ukrainian/website) слід використовувати лише для спрощення процесу локалізації. +Якщо ви виявили вади в перекладеному вмісті, [створіть тікет на kubernetes/website](https://github.com/kubernetes/website/issues/new/choose) за позначкою `/language uk`. -## Правила перекладу {#правила-перекладу} +Репозиторієм [kubernetes-i18n-ukrainian/website](https://github.com/kubernetes-i18n-ukrainian/website) слід користуватись лише для спрощення процесу локалізації.[^1] -* Скопіюйте оригінал і додайте його перед перекладом у якості коментаря. Це потрібно для спрощення відслідковування змін і процесу ревью. Приклади: [для Markdown](https://github.com/kubernetes/website/blob/7774cc9f3582c5f94e40245cdd5855e3c206177e/content/uk/docs/tutorials/hello-minikube.md#L23-L35), [для YAML](https://github.com/kubernetes/website/blob/7774cc9f3582c5f94e40245cdd5855e3c206177e/content/uk/docs/tutorials/hello-minikube.md#L8-L14). +[^1]: На превеликий жаль, поточний репозиторій перебуває в підвішеному стані, якихось активностей в ньому немає з 2020 року. 😢 -* У випадку, якщо у перекладі термін набуває неоднозначності і розуміння тексту ускладнюється, надайте у дужках англійський варіант, наприклад: кінцеві точки (endpoints). Якщо при перекладі термін втрачає своє значення, краще не перекладати його, наприклад: характеристики affinity. +### Наявні проблеми/оновлення локалізації -* Назви об'єктів Kubernetes залишаємо без перекладу і пишемо з великої літери: Service, Pod, Deployment, Volume, Namespace, за винятком терміна node (вузол). Назви об'єктів Kubernetes вважаємо за іменники ч.р. і відмінюємо за допомогою апострофа: Pod'ів, Deployment'ами. - Для слів, що закінчуються на приголосний, у родовому відмінку однини використовуємо закінчення -а: Pod'а, Deployment'а. - Слова, що закінчуються на голосний, не відмінюємо: доступ до Service, за допомогою Namespace. У множині використовуємо англійську форму: користуватися Services, спільні Volumes. +Якщо ви виявили проблеми з перекладеним вмістом і не можете їх негайно виправити, [створіть тікет у kubernetes/website](https://github.com/kubernetes/website/issues/new/choose) з описом що не так, на якій сторінці (посилання) і додайте в опис тікета, з нового рядка, команду [Prow](https://prow.k8s.io/command-help) — `/language uk`. -* Частовживані і усталені за межами Kubernetes слова перекладаємо українською і пишемо з малої літери (label -> мітка). У випадку, якщо термін для означення об'єкта Kubernetes вживається у своєму загальному значенні поза контекстом Kubernetes (service як службова програма, deployment як розгортання), перекладаємо його і пишемо з малої літери, наприклад: service discovery -> виявлення сервісу, continuous deployment -> безперервне розгортання. +## Правила перекладу -* Складені слова вважаємо за власні назви і не перекладаємо (LabelSelector, kube-apiserver). +* У випадку, якщо у перекладі термін набуває неоднозначності та розуміння тексту ускладнюється, надайте у дужках англійський варіант, наприклад: кінцеві точки (endpoints). Якщо при перекладі термін втрачає своє значення, краще не перекладати його, наприклад: характеристики affinity. +* Назви обʼєктів Kubernetes залишаємо без перекладу і пишемо з великої літери: Service, Pod, Deployment, Volume, Namespace, за винятком терміна node (вузол). Назви обʼєктів Kubernetes вважаємо за іменники ч.р. і відмінюємо за допомогою апострофа: Podʼів, Deploymentʼами. +* Для слів, що закінчуються на приголосний, у родовому відмінку однини використовуємо закінчення `-а`: Podʼа, Deploymentʼа. Слова, що закінчуються на голосний, не відмінюємо: доступ до `Service`, за допомогою `Namespace`. У множині використовуємо англійську форму: користуватися `Services`, спільні `Volumes`. +* Частовживані та усталені за межами Kubernetes слова перекладаємо українською і пишемо з малої літери (`label` → `мітка`). У випадку, якщо термін для означення обʼєкта Kubernetes вживається у своєму загальному значенні поза контекстом Kubernetes (`service` як службова програма, `deployment` як розгортання), перекладаємо його і пишемо з малої літери, наприклад: `service discovery` → `виявлення сервісу`, `continuous deployment` → `безперервне розгортання`. +* Складені слова вважаємо за власні назви та не перекладаємо (`LabelSelector`, `kube-apiserver`). +* Для перевірки закінчень слів у родовому відмінку однини (`-а/-я`, `-у/-ю`) використовуйте [онлайн словник](https://slovnyk.ua/). Якщо слова немає у словнику, визначте його відмінювання і далі відмінюйте за правилами. Докладніше [дивіться тут](https://pidruchniki.com/1948041951499/dokumentoznavstvo/vidminyuvannya_imennikiv). +* Для символу тире `―` використовуйте символ mdash «—» (`—`, U+2014) замість двох звичайних тире «–» (`–`, U+2013), чи дефісу «-» (U+002D) +* Апостроф: використовуйте літеру-апостроф `ʼ` (U+02BC) замість звичайного апострофа `'` (U+0027), чи правої одинарної лапки `’` (U+2019). -* Для перевірки закінчень слів у родовому відмінку однини (-а/-я, -у/-ю) використовуйте [онлайн словник](https://slovnyk.ua/). Якщо слова немає у словнику, визначте його відміну і далі відмінюйте за правилами. Докладніше [дивіться тут](https://pidruchniki.com/1948041951499/dokumentoznavstvo/vidminyuvannya_imennikiv). +## Словник -## Словник {#словник} +💡 Наступний словник є лише рекомендаціями English | Українська | --- | --- | @@ -71,12 +72,12 @@ containerized | контейнеризований | continuous deployment | безперервне розгортання | continuous development | безперервна розробка | continuous integration | безперервна інтеграція | -contribute | робити внесок (до проекту), допомагати (проекту) | -contributor | контриб'ютор, учасник проекту | +contribute | робити внесок (до проєкту), допомагати (проєкту) | +contributor | контриб'ютор, учасник проєкту | control plane | площина управління | controller | контролер | CPU | ЦП | -dashboard | дашборд | +dashboard | дашборд, інфопанель, інформаційна панель | data plane | площина даних | default (by) | за умовчанням | default settings | типові налаштування | @@ -84,7 +85,7 @@ Deployment | Deployment | deprecated | застарілий | desired state | бажаний стан | downtime | недоступність, простій | -ecosystem | сімейство проектів (екосистема) | +ecosystem | сімейство проєктів (екосистема) | endpoint | кінцева точка | expose (a service) | відкрити доступ (до сервісу) | fail | відмовити | @@ -93,16 +94,16 @@ framework | фреймворк | frontend | фронтенд | image | образ | Ingress | Ingress | -instance | інстанс | +instance | інстанс, екземпляр | issue | запит | kube-proxy | kube-proxy | kubelet | kubelet | -Kubernetes features | функціональні можливості Kubernetes | +Kubernetes features | (функціональні) можливості Kubernetes | label | мітка | lifecycle | життєвий цикл | logging | логування | maintenance | обслуговування | -map | спроектувати, зіставити, встановити відповідність | +map | спроєктувати, зіставити, встановити відповідність | master | master | monitor | моніторити | monitoring | моніторинг | @@ -142,4 +143,6 @@ Volume | Volume | workload | робоче навантаження | YAML | YAML | +---- +## Примітки diff --git a/content/uk/docs/home/_index.md b/content/uk/docs/home/_index.md index d534d5f3ceeea..b7a53896b5a14 100644 --- a/content/uk/docs/home/_index.md +++ b/content/uk/docs/home/_index.md @@ -1,4 +1,6 @@ --- +approvers: +- chenopis title: Документація Kubernetes noedit: true cid: docsHome @@ -13,44 +15,53 @@ menu: title: "Документація" weight: 20 post: > -

Дізнайтеся про основи роботи з Kubernetes, використовуючи схеми, навчальну та довідкову документацію. Ви можете навіть зробити свій внесок у документацію!

+

Дізнайтеся про основи роботи з Kubernetes, за допомогою концептуальної, навчальної та довідкової документації. Ви можете навіть зробити свій внесок в покращення документації!

+description: > + Kubernetes — рушій оркестрування контейнерів, створений для автоматичного розгортання, масштабування і управління контейнеризованими застосунками, є проєктом з відкритим вихідним кодом. Цей проєкт знаходиться під егідою Cloud Native Computing Foundation. overview: > - Kubernetes - рушій оркестрації контейнерів з відкритим вихідним кодом для автоматичного розгортання, масштабування і управління контейнеризованими застосунками. Цей проект розробляється під егідою Cloud Native Computing Foundation (CNCF). + Kubernetes — рушій оркестрування контейнерів, створений для автоматичного розгортання, масштабування і управління контейнеризованими застосунками, є проєктом з відкритим вихідним кодом. Цей проєкт знаходиться під егідою Cloud Native Computing Foundation (CNCF). cards: - name: concepts - title: "Розуміння основ" + title: "Що таке Kubernetes" description: "Дізнайтеся про Kubernetes і його фундаментальні концепції." - button: "Дізнатися про концепції" + button: "Концепції" button_path: "/docs/concepts" - name: tutorials title: "Спробуйте Kubernetes" - description: "Дізнайтеся із навчальних матеріалів, як розгортати застосунки в Kubernetes." - button: "Переглянути навчальні матеріали" + description: "Наступні посібники допоможуть вам дізнатись, як розгортати застосунки в Kubernetes." + button: "Посібники" button_path: "/docs/tutorials" - name: setup - title: "Налаштування кластера" - description: "Розгорніть Kubernetes з урахуванням власних ресурсів і потреб." - button: "Налаштувати Kubernetes" + title: "Встановлення кластера K8s" + description: "Розгорніть Kubernetes з урахуванням власних ресурсів та потреб." + button: "Встановлення" button_path: "/docs/setup" - name: tasks - title: "Дізнайтеся, як користуватись Kubernetes" - description: "Ознайомтеся з типовими задачами і способами їх виконання за допомогою короткого алгоритму дій." - button: "Переглянути задачі" + title: "Застосування Kubernetes" + description: "Знайдіть типові завдання та способи їх виконання за допомогою послідовних кроків." + button: "Переглянути завдання" button_path: "/docs/tasks" - name: reference - title: Переглянути довідкову інформацію + title: Довідкова інформація description: Ознайомтеся з термінологією, синтаксисом командного рядка, типами ресурсів API і документацією з налаштування інструментів. - button: Переглянути довідкову інформацію + button: Довідкова інформація button_path: /docs/reference - name: contribute - title: Зробити внесок у документацію - description: Будь-хто може зробити свій внесок, незалежно від того, чи ви нещодавно долучилися до проекту, чи працюєте над ним вже довгий час. - button: Зробити внесок у документацію + title: Сопособи участі + description: Дізнайтесь як допомогти зробити Kubernetes кращим. + button: Дізнайтесь як допомогти button_path: /docs/contribute +- name: training + title: Навчання та сертифікація + description: "Отримайте сертифікат Kubernetes і зробіть свої хмарні проєкти успішними!" + button: "Навчання" + button_path: "/training" - name: download - title: Завантажити Kubernetes - description: Якщо ви встановлюєте Kubernetes чи оновлюєтесь до останньої версії, звіряйтеся з актуальною інформацією по релізу. + title: Отримання Kubernetes + description: Встановіть чи оновіть Kubernetes до останньої версії. + button: Завантажити + button_path: /releases/download - name: about - title: Про документацію - description: Цей вебсайт містить документацію по актуальній і чотирьох попередніх версіях Kubernetes. + title: Про цю документацію + description: Цей вебсайт містить документацію для поточної та чоторьої попередніх версій Kubernetes. --- diff --git a/content/uk/docs/home/supported-doc-versions.md b/content/uk/docs/home/supported-doc-versions.md new file mode 100644 index 0000000000000..e9df2dc421d2e --- /dev/null +++ b/content/uk/docs/home/supported-doc-versions.md @@ -0,0 +1,13 @@ +--- +title: Доступні версії документації +content_type: custom +layout: supported-versions +card: + name: about + weight: 10 + title: Доступні версії документації +--- + +Цей вебсайт містить документацію для поточної версії Kubernetes та чотирьох попередніх версій Kubernetes. + +Доступність документації для версії Kubernetes не повʼязана з тим, чи підтримується ця версія. Дізнайтеся більше про [період підтримки](/releases/patch-releases/#період-підтримки), щоб дізнатися, які версії Kubernetes офіційно підтримуються і як довго. diff --git a/content/uk/docs/reference/_index.md b/content/uk/docs/reference/_index.md new file mode 100644 index 0000000000000..e959a910ac91d --- /dev/null +++ b/content/uk/docs/reference/_index.md @@ -0,0 +1,103 @@ +--- +title: Довідник +approvers: +- chenopis +linkTitle: "Довідник" +main_menu: true +weight: 70 +content_type: concept +no_list: true +--- + + + +Цей розділ документації Kubernetes містить довідники. + + + +## Довідники API {#api-reference} + +* [Глосарій](/docs/reference/glossary/) — докладний, стандартизований перелік термінології Kubernetes + +* [Довідник API Kubernetes](/docs/reference/kubernetes-api/) +* [Односторінковий довідник API Kubernetes {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) +* [Використання API Kubernetes](/docs/reference/using-api/) — огляд API для Kubernetes. +* [API керування доступом](/docs/reference/access-authn-authz/) — докладно про те, як Kubernetes контролює доступи API +* [Добре відомі мітки (labels), анотації (annotations) та пристосування (taints).](/docs/reference/labels-annotations-taints/) + +## Офіційно підтримувані клієнтські бібліотеки {#officially-supported-client-libraries} + +Для надсилання викликів до API Kubernetes з мов програмування ви можете використовувати +[клієнтські бібліотеки](/docs/reference/using-api/client-libraries/). Офіційно підтримуються наступні: + +* [Kubernetes Go client library](https://github.com/kubernetes/client-go/) +* [Kubernetes Python client library](https://github.com/kubernetes-client/python) +* [Kubernetes Java client library](https://github.com/kubernetes-client/java) +* [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript) +* [Kubernetes C# client library](https://github.com/kubernetes-client/csharp) +* [Kubernetes Haskell client library](https://github.com/kubernetes-client/haskell) + +## CLI + +* [kubectl](/docs/reference/kubectl/) — Основний інструмент командного рядка для виконання команд та управління кластерами Kubernetes. + * [JSONPath](/docs/reference/kubectl/jsonpath/) — Посібник з синтаксису використання виразів [JSONPath](https://goessner.net/articles/JsonPath/) з kubectl. +* [kubeadm](/docs/reference/setup-tools/kubeadm/) — Інструмент командного рядка для легкого впровадження роботи з захищеним кластером Kubernetes. + +## Компоненти {#components} + +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) — Основний агент, який працює на кожному вузлі. Kubelet отримує набір PodSpecs і переконується, що описані контейнери працюють і є функціональними. +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) — REST API, що перевіряє та налаштовує дані для обʼєктів API, таких як Podʼи, Serviceʼи, контролери реплікацій. +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) — Демон, який вбудовує основні процеси управління, які постачаються з Kubernetes. +* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) — Може виконувати просте перенаправлення потоку TCP/UDP або перенаправляти потік TCP/UDP методом "round-robin" через набір backend-ів. +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) — Планувальник, який керує доступністю, продуктивністю та місткістю. + + * [Політики планування](/docs/reference/scheduling/policies) + * [Профілі планування](/docs/reference/scheduling/config#profiles) + +* Список [портів та протоколів](/docs/reference/networking/ports-and-protocols/), які повинні бути відкриті на вузлах панелі управління та робочих вузлах. + +## Конфігураційні API {#config-apis} + +Цей розділ містить документацію для "неопублікованих" API, які використовуються для налаштування компонентів або інструментів Kubernetes. Більшість з цих API не експонуються через API-сервер у стилі REST, хоча вони є важливими для користувача чи оператора для використання або управління кластером. + +* [kubeconfig (v1)](/docs/reference/config-api/kubeconfig.v1/) +* [kube-apiserver admission (v1)](/docs/reference/config-api/apiserver-admission.v1/) +* [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) та +* [kube-apiserver configuration (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/) та + [kube-apiserver configuration (v1)](/docs/reference/config-api/apiserver-config.v1/) +* [kube-apiserver encryption (v1)](/docs/reference/config-api/apiserver-encryption.v1/) +* [kube-apiserver event rate limit (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/) +* [kubelet configuration (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) та + [kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) + [kubelet configuration (v1)](/docs/reference/config-api/kubelet-config.v1/) +* [kubelet credential providers (v1)](/docs/reference/config-api/kubelet-credentialprovider.v1/) +* [kube-scheduler configuration (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) та + [kube-scheduler configuration (v1)](/docs/reference/config-api/kube-scheduler-config.v1/) +* [kube-controller-manager configuration (v1alpha1)](/docs/reference/config-api/kube-controller-manager-config.v1alpha1/) +* [kube-proxy configuration (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/) +* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/) +* [Client authentication API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) та + [Client authentication API (v1)](/docs/reference/config-api/client-authentication.v1/) +* [WebhookAdmission configuration (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/) +* [ImagePolicy API (v1alpha1)](/docs/reference/config-api/imagepolicy.v1alpha1/) + +## Конфігураційні API kubeadm {#config-apis-for-kubeadm} + +* [v1beta3](/docs/reference/config-api/kubeadm-config.v1beta3/) +* [v1beta4](/docs/reference/config-api/kubeadm-config.v1beta4/) + +## Зовнішні API {#external-apis} + +Ці API, визначені проєктом Kubernetes, але не реалізовані в межах +основного проєкту: + +* [API метрик (v1beta1)](/docs/reference/external-api/metrics.v1beta1/) +* [API власних метрик (v1beta2)](/docs/reference/external-api/custom-metrics.v1beta2) +* [API зовнішніх метрик (v1beta1)](/docs/reference/external-api/external-metrics.v1beta1) + +## Документи проєктування {#design-docs} + +Архів документів проєктування для функціонала Kubernetes. Ви можете розпочати з + +* [Архітектура Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) та +* [Огляд дизайну Kubernetes](https://git.k8s.io/design-proposals-archive). diff --git a/content/uk/docs/reference/access-authn-authz/_index.md b/content/uk/docs/reference/access-authn-authz/_index.md new file mode 100644 index 0000000000000..33ba3ca8d57c6 --- /dev/null +++ b/content/uk/docs/reference/access-authn-authz/_index.md @@ -0,0 +1,27 @@ +--- +title: Керування доступом до API Kubernetes +weight: 30 +no_list: true +--- + +Для ознайомлення з тим, як Kubernetes реалізує та контролює доступ до API, прочитайте [Керування доступом до API Kubernetes](/docs/concepts/security/controlling-access/). + +Документація з посиланнями: + +- [Автентифікація](/docs/reference/access-authn-authz/authentication/) + - [Автентифікація за допомогою Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) +- [Контролери допуску](/docs/reference/access-authn-authz/admission-controllers/) + - [Динамічний контроль допуску](/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [Авторизація](/docs/reference/access-authn-authz/authorization/) + - [Контроль доступу на основі ролей](/docs/reference/access-authn-authz/rbac/) + - [Контроль доступу на основі атрибутів](/docs/reference/access-authn-authz/abac/) + - [Авторизація вузла](/docs/reference/access-authn-authz/node/) + - [Авторизація за допомогою вебхуків](/docs/reference/access-authn-authz/webhook/) +- [Запити на підпис сертифікатів](/docs/reference/access-authn-authz/certificate-signing-requests/) + - включаючи [Схвалення запиту на підпис сертифіката](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) + та [підпис сертифіката](/docs/reference/access-authn-authz/certificate-signing-requests/#signing) +- Облікові записи служб + - [Посібник розробника](/docs/tasks/configure-pod-container/configure-service-account/) + - [Адміністрування](/docs/reference/access-authn-authz/service-accounts-admin/) +- [Автентифікація та авторизація Kubelet](/docs/reference/access-authn-authz/kubelet-authn-authz/) + - включаючи [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) diff --git a/content/uk/docs/reference/command-line-tools-reference/_index.md b/content/uk/docs/reference/command-line-tools-reference/_index.md new file mode 100644 index 0000000000000..1d970a8290bb2 --- /dev/null +++ b/content/uk/docs/reference/command-line-tools-reference/_index.md @@ -0,0 +1,4 @@ +--- +title: Компонентні інструменти +weight: 120 +--- diff --git a/content/uk/docs/reference/command-line-tools-reference/feature-gates/in-place-pod-vertical-scaling.md b/content/uk/docs/reference/command-line-tools-reference/feature-gates/in-place-pod-vertical-scaling.md new file mode 100644 index 0000000000000..418ac351690e8 --- /dev/null +++ b/content/uk/docs/reference/command-line-tools-reference/feature-gates/in-place-pod-vertical-scaling.md @@ -0,0 +1,13 @@ +--- +title: InPlacePodVerticalScaling +content_type: feature_gate +_build: + list: never + render: false + +stages: + - stage: alpha + defaultValue: false + fromVersion: "1.27" +--- +Дозволяє вертикальне масштабування Podʼів на місці. diff --git a/content/uk/docs/reference/config-api/_index.md b/content/uk/docs/reference/config-api/_index.md new file mode 100644 index 0000000000000..fb13ba49f611f --- /dev/null +++ b/content/uk/docs/reference/config-api/_index.md @@ -0,0 +1,4 @@ +--- +title: Конфігураційні API +weight: 130 +--- diff --git a/content/uk/docs/reference/debug-cluster/_index.md b/content/uk/docs/reference/debug-cluster/_index.md new file mode 100644 index 0000000000000..35070f99baa78 --- /dev/null +++ b/content/uk/docs/reference/debug-cluster/_index.md @@ -0,0 +1,5 @@ +--- +title: Відлагодження кластера +weight: 120 +no_list: false +--- diff --git a/content/uk/docs/reference/external-api/_index.md b/content/uk/docs/reference/external-api/_index.md new file mode 100644 index 0000000000000..90f84eeeeda12 --- /dev/null +++ b/content/uk/docs/reference/external-api/_index.md @@ -0,0 +1,4 @@ +--- +title: Зовнішні API +weight: 135 +--- diff --git a/content/uk/docs/reference/glossary/addons.md b/content/uk/docs/reference/glossary/addons.md new file mode 100644 index 0000000000000..975ede2c6851d --- /dev/null +++ b/content/uk/docs/reference/glossary/addons.md @@ -0,0 +1,17 @@ +--- +title: Надбудови +id: addons +date: 2019-12-15 +full_link: /docs/concepts/cluster-administration/addons/ +short_description: > + Ресурси, які розширюють функціональність Kubernetes. + +aka: +tags: +- tool +--- +Ресурси, які розширюють функціональність Kubernetes. + + + +[Інструкції щодо встановлення надбудов](/docs/concepts/cluster-administration/addons/) надають більше інформації щодо використання надбудов у вашому кластері та перераховують деякі популярні надбудови. diff --git a/content/uk/docs/reference/glossary/admission-controller.md b/content/uk/docs/reference/glossary/admission-controller.md new file mode 100644 index 0000000000000..db6d5716d6af5 --- /dev/null +++ b/content/uk/docs/reference/glossary/admission-controller.md @@ -0,0 +1,20 @@ +--- +title: Контролер допуску +id: admission-controller +date: 2019-06-28 +full_link: /docs/reference/access-authn-authz/admission-controllers/ +short_description: > + Фрагмент коду, який перехоплює запити до сервера API Kubernetes перед збереженням обʼєкта. + +aka: +tags: +- extension +- security +--- +Фрагмент коду, який перехоплює запити до сервера API Kubernetes перед збереженням обʼєкта. + + + +Контролери допуску налаштовуються для API сервера Kubernetes і можуть бути "перевіряючими", "мутаційними" або обома. Будь-який контролер допуску може відхилити запит. Мутаційні контролери можуть модифікувати обʼєкти, які вони пропускають; перевіряючі контролери цього робити не можуть. + +* [Контролери допуску в документації Kubernetes](/docs/reference/access-authn-authz/admission-controllers/) \ No newline at end of file diff --git a/content/uk/docs/reference/glossary/affinity.md b/content/uk/docs/reference/glossary/affinity.md new file mode 100644 index 0000000000000..422acfccd23c9 --- /dev/null +++ b/content/uk/docs/reference/glossary/affinity.md @@ -0,0 +1,22 @@ +--- +title: Спорідненість +id: affinity +date: 2019-01-11 +full_link: /docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity +short_description: > + Правила, що використовуються планувальником для визначення місця розташування Podʼів. + +aka: +tags: +- fundamental +--- + +У Kubernetes _Affinity_ — це набір правил, які дають підказки планувальнику, де розміщувати поди. + + +Є два види спорідненості: + +* [спорідненість вузла](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) +* [спорідненість між Podʼами](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) + +Правила визначаються за допомогою {{< glossary_tooltip term_id="label" text="міток">}}, та {{< glossary_tooltip term_id="selector" text="селекторів">}}, вказаних в {{< glossary_tooltip term_id="pod" text="Podʼах" >}}, і вони можуть бути обовʼязковими або бажаними, залежно від того, наскільки суворо ви хочете, щоб планувальник їх дотримувався. diff --git a/content/uk/docs/reference/glossary/aggregation-layer.md b/content/uk/docs/reference/glossary/aggregation-layer.md new file mode 100644 index 0000000000000..2ae52cfae9627 --- /dev/null +++ b/content/uk/docs/reference/glossary/aggregation-layer.md @@ -0,0 +1,19 @@ +--- +title: Шар агрегації +id: aggregation-layer +date: 2018-10-08 +full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ +short_description: > + Шар агрегації дозволяє встановлювати додаткові API в стилі Kubernetes у вашому кластері. + +aka: +tags: +- architecture +- extension +- operation +--- +Шар агрегації дозволяє встановлювати додаткові API в стилі Kubernetes у вашому кластері. + + + +Коли ви налаштували {{< glossary_tooltip text="Сервер API Kubernetes" term_id="kube-apiserver" >}} для [підтримки додаткових API](/docs/tasks/extend-kubernetes/configure-aggregation-layer/), ви можете додавати обʼєкти `APIService` які "затребують" URL-адреси в API Kubernetes. diff --git a/content/uk/docs/reference/glossary/annotation.md b/content/uk/docs/reference/glossary/annotation.md new file mode 100644 index 0000000000000..933e4887efe67 --- /dev/null +++ b/content/uk/docs/reference/glossary/annotation.md @@ -0,0 +1,17 @@ +--- +title: Анотація +id: annotation +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/annotations +short_description: > + Ключ-значення, які використовуються для додавання довільних невизначених метаданих до обʼєктів. + +aka: +tags: +- fundamental +--- +Ключ-значення, які використовуються для додавання довільних невизначених метаданих до обʼєктів. + + + +Метадані в анотації можуть бути невеликими чи великими, структурованими чи неструктурованими, і можуть містити символи, які не дозволяються у {{< glossary_tooltip text="мітках" term_id="label" >}}. Клієнти, такі як інструменти та бібліотеки, можуть отримувати ці метадані. diff --git a/content/uk/docs/reference/glossary/api-eviction.md b/content/uk/docs/reference/glossary/api-eviction.md new file mode 100644 index 0000000000000..41e5dd7346c37 --- /dev/null +++ b/content/uk/docs/reference/glossary/api-eviction.md @@ -0,0 +1,24 @@ +--- +title: Ініційоване API вивільнення ресурсів +id: api-eviction +date: 2021-04-27 +full_link: /docs/concepts/scheduling-eviction/api-eviction/ +short_description: > + Ініційоване API вивільнення ресурсів — процес, під час якого використовується Eviction API для створення обʼєкта Eviction, який викликає гармонійне завершення роботи Podʼу. +aka: +tags: +- operation +--- +Ініційоване API вивільнення ресурсів — процес, під час якого використовується [Eviction API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core) +для створення обʼєкта `Eviction`, який викликає гармонійне завершення роботи Podʼу. + + + +Ви можете зробити запит на вивільнення, якщо ви напряму звертаєтесь до Eviction API з використанням клієнта kube-apiserver, такого як команда `kubectl drain`. Коли створюється обʼєкт `Eviction`, сервер API завершує роботу Podʼу. + +Ініційоване API вивільнення ресурсів дотримуються параметрів з [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) +та [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination). + +Ініційоване API вивільнення ресурсів не є тим самим, що й [вивільнення через тиск на вузол](/docs/concepts/scheduling-eviction/node-pressure-eviction/). + +* Дивіться [Ініційоване API вивільнення ресурсів](/docs/concepts/scheduling-eviction/api-eviction/) для отримання додаткової інформації. diff --git a/content/uk/docs/reference/glossary/api-group.md b/content/uk/docs/reference/glossary/api-group.md new file mode 100644 index 0000000000000..bdcae7ceecfb3 --- /dev/null +++ b/content/uk/docs/reference/glossary/api-group.md @@ -0,0 +1,20 @@ +--- +title: API-група +id: api-group +date: 2019-09-02 +full_link: /docs/concepts/overview/kubernetes-api/#api-groups-and-versioning +short_description: > + Набір повʼязаних шляхів в API Kubernetes. + +aka: +- API Group +tags: +- fundamental +- architecture +--- +Набір повʼязаних шляхів в API Kubernetes. + + +Ви можете увімкнути або вимкнути кожну API-групу, змінивши конфігурацію свого API-сервера. Ви також можете вимкнути або увімкнути шляхи до конкретних ресурсів. API-група полегшує розширення API Kubernetes. API-група вказується в REST-шляху та в полі `apiVersion` серіалізованого обʼєкта. + +* Дивіться [API-група](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) для отримання додаткової інформації. diff --git a/content/uk/docs/reference/glossary/app-container.md b/content/uk/docs/reference/glossary/app-container.md new file mode 100644 index 0000000000000..547ef0ef2fd90 --- /dev/null +++ b/content/uk/docs/reference/glossary/app-container.md @@ -0,0 +1,18 @@ +--- +title: Контейнер застосунку +id: app-container +date: 2019-02-12 +full_link: +short_description: > + Контейнер, що використовується для запуску частини робочого навантаження. Порівняйте з контейнером ініціалізації. + +aka: +tags: +- workload +--- +Контейнери застосунків — це {{< glossary_tooltip text="контейнери" term_id="container" >}} в {{< glossary_tooltip text="Podʼі" term_id="pod" >}}, які запускаються після завершення роботи будь-яких {{< glossary_tooltip text="контейнерів ініціалізації" term_id="init-container" >}}. + + + +Контейнер ініціалізації дозволяє відокремити деталі ініціалізації, які важливі для загального {{< glossary_tooltip text="робочого навантаження" term_id="workload" >}}, і які не потрібно тримати в роботі після того, як контейнер застосунку вже запущено. +Якщо у Podʼа немає налаштованих контейнерів ініціалізації, всі контейнери в цьому Podʼі є контейнерами застосунку. diff --git a/content/uk/docs/reference/glossary/application-architect.md b/content/uk/docs/reference/glossary/application-architect.md new file mode 100644 index 0000000000000..d23d8c30dac75 --- /dev/null +++ b/content/uk/docs/reference/glossary/application-architect.md @@ -0,0 +1,17 @@ +--- +title: Архітектор застосунків +id: application-architect +date: 2018-04-12 +full_link: +short_description: > + Особа, відповідальна за високорівневий дизайн застосунку. + +aka: +tags: +- user-type +--- +Особа, відповідальна за високорівневий дизайн застосунку. + + + +Архітектор забезпечує, що реалізація застосунку дозволяє взаємодіяти з навколишніми компонентами таким чином, щоб це було масштабовано та зручно для обслуговування. До навколишніх компонентів входять бази даних, інфраструктура логування та інші мікросервіси. diff --git a/content/uk/docs/reference/glossary/application-developer.md b/content/uk/docs/reference/glossary/application-developer.md new file mode 100644 index 0000000000000..d33aa8d1e7d85 --- /dev/null +++ b/content/uk/docs/reference/glossary/application-developer.md @@ -0,0 +1,17 @@ +--- +title: Розробник застосунків +id: application-developer +date: 2018-04-12 +full_link: +short_description: > + Особа, яка створює застосунок, який працює в кластері Kubernetes. + +aka: +tags: +- user-type +--- +Особа, яка створює застосунок, який працює в кластері Kubernetes. + + + +Розробник застосунків фокусується на одній частині застосунку. Масштаб їх уваги може значно варіюватися. diff --git a/content/uk/docs/reference/glossary/applications.md b/content/uk/docs/reference/glossary/applications.md index c42c6ec34339c..dc4200fedba9b 100644 --- a/content/uk/docs/reference/glossary/applications.md +++ b/content/uk/docs/reference/glossary/applications.md @@ -1,16 +1,14 @@ --- -# title: Applications title: Застосунки id: applications date: 2019-05-12 full_link: -# short_description: > -# The layer where various containerized applications run. short_description: > - Шар, в якому запущено контейнерізовані застосунки. + Шар, в якому виконуються різноманітні контейнеризовані застосунки. aka: tags: - fundamental --- - -Шар, в якому запущено контейнерізовані застосунки. +Шар, в якому виконуються різноманітні контейнеризовані застосунки. + + diff --git a/content/uk/docs/reference/glossary/approver.md b/content/uk/docs/reference/glossary/approver.md new file mode 100644 index 0000000000000..c3441c3d86405 --- /dev/null +++ b/content/uk/docs/reference/glossary/approver.md @@ -0,0 +1,17 @@ +--- +title: Затверджувач +id: approver +date: 2018-04-12 +full_link: +short_description: > + Особа, яка може переглядати та схвалювати внесок до коду Kubernetes. + +aka: +tags: +- community +--- +Особа, яка може переглядати та схвалювати внесок до коду Kubernetes. + + + +Тоді як перевірка коду зосереджена на якості та правильності коду, схвалення зосереджено на цілісному прийнятті внеску. Цілісне прийняття включає зворотну/пряму сумісність, дотримання умов API та прапорів, неявні проблеми з продуктивністю та правильністю, взаємодію з іншими частинами системи та інші. Статус затверджувача поширюється на частину кодової бази. Затверджувачі раніше називалися супроводжувачами. diff --git a/content/uk/docs/reference/glossary/cadvisor.md b/content/uk/docs/reference/glossary/cadvisor.md new file mode 100644 index 0000000000000..2fbdd6f5dc1f8 --- /dev/null +++ b/content/uk/docs/reference/glossary/cadvisor.md @@ -0,0 +1,16 @@ +--- +назва: cAdvisor +id: cadvisor +Дата: 2021-12-09 +повне_посилання: https://github.com/google/cadvisor/ +короткий_опис: > + Інструмент, який забезпечує розуміння використання ресурсів і характеристики продуктивності для контейнерів +aka: +tags: +- tool +--- +cAdvisor (Container Advisor) надає користувачам контейнерів розуміння використання ресурсів і характеристик продуктивності роботи {{< glossary_tooltip text="контейнерів" term_id="container" >}}. + + + +Це працююча фонова служба, що збирає, агрегує, обробляє та експортує інформацію про запущені контейнери. Зокрема, для кожного контейнера зберігаються параметри ізоляції ресурсів, історичне використання ресурсів, гістограми повного історичного використання ресурсів і мережева статистика. Ці дані експортуються в контейнер і на всю машину. diff --git a/content/uk/docs/reference/glossary/certificate.md b/content/uk/docs/reference/glossary/certificate.md new file mode 100644 index 0000000000000..8a142e884477a --- /dev/null +++ b/content/uk/docs/reference/glossary/certificate.md @@ -0,0 +1,17 @@ +--- +title: Сертифікат +id: certificate +date: 2018-04-12 +full_link: /docs/tasks/tls/managing-tls-in-a-cluster/ +short_description: > + Криптографічно захищений файл, який використовується для підтвердження доступу до кластера Kubernetes. + +aka: +tags: +- security +--- +Криптографічно захищений файл, який використовується для підтвердження доступу до кластера Kubernetes. + + + +Сертифікати дозволяють застосункам у межах кластера Kubernetes отримувати захищений доступ до API Kubernetes. Сертифікати перевіряють, чи клієнти мають дозвіл на доступ до API. diff --git a/content/uk/docs/reference/glossary/cgroup.md b/content/uk/docs/reference/glossary/cgroup.md new file mode 100644 index 0000000000000..b059c0a90d6cc --- /dev/null +++ b/content/uk/docs/reference/glossary/cgroup.md @@ -0,0 +1,17 @@ +--- +title: cgroup (control group) +id: cgroup +date: 2019-06-25 +full_link: +short_description: > + Група процесів в середовищі Linux із можливістю ізоляції, обліку та встановлення обмежень ресурсів. + +aka: +tags: +- fundamental +--- +Група процесів в середовищі Linux із можливістю ізоляції, обліку та встановлення обмежень ресурсів. + + + +cgroup є функцією ядра Linux, яка обмежує, обліковує та ізолює використання ресурсів (центральний процесор, памʼять, введення/виведення даних на диск, мережа) для колекції процесів. diff --git a/content/uk/docs/reference/glossary/cidr.md b/content/uk/docs/reference/glossary/cidr.md new file mode 100644 index 0000000000000..b8a43f2ed4360 --- /dev/null +++ b/content/uk/docs/reference/glossary/cidr.md @@ -0,0 +1,17 @@ +--- +title: CIDR +id: cidr +date: 2019-11-12 +full_link: +short_description: > + CIDR — це нотація для опису блоків IP-адрес широко використовується в налаштуваннях конфігурації мережі. + +aka: +tags: +- networking +--- +CIDR (Classless Inter-Domain Routing) — це нотація для опису блоків IP-адрес широко використовується в налаштуваннях конфігурації мережі. + + + +У контексті Kubernetes кожному {{< glossary_tooltip text="вузлу" term_id="node" >}} призначається діапазон IP-адрес за допомогою початкової адреси та маски підмережі за допомогою CIDR. Це дозволяє вузлам призначати кожному {{< glossary_tooltip text="Podʼу" term_id="pod" >}} унікальну IP-адресу. Попри те, що спочатку це була концепція для IPv4, CIDR також розширили на IPv6. diff --git a/content/uk/docs/reference/glossary/cla.md b/content/uk/docs/reference/glossary/cla.md new file mode 100644 index 0000000000000..610b39e02da11 --- /dev/null +++ b/content/uk/docs/reference/glossary/cla.md @@ -0,0 +1,17 @@ +--- +title: CLA (Ліцензійна угода учасника) +id: cla +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/CLA.md +short_description: > + Умови, за якими учасник ліцензує свій внесок до проєкту з відкритими сирцями. + +aka: +tags: +- community +--- + Умови, за якими {{< glossary_tooltip text="учасник" term_id="contributor" >}} ліцензує свій внесок до проєкту з відкритими сирцями. + + + +CLA допомагає вирішувати юридичні спори, повʼязані із наданим матеріалом та правами на інтелектуальну власність (IP, intellectual property). diff --git a/content/uk/docs/reference/glossary/cloud-controller-manager.md b/content/uk/docs/reference/glossary/cloud-controller-manager.md new file mode 100644 index 0000000000000..4d3dd3ee9d8a5 --- /dev/null +++ b/content/uk/docs/reference/glossary/cloud-controller-manager.md @@ -0,0 +1,18 @@ +--- +title: Cloud Controller Manager +id: cloud-controller-manager +date: 2018-04-12 +full_link: /docs/concepts/architecture/cloud-controller/ +short_description: > + Компонент панелі управління, що інтегрує Kubernetes з хмарними провайдерами. +aka: +tags: +- core-object +- architecture +- operation +--- +Компонент {{< glossary_tooltip text="панелі управління" term_id="control-plane" >}} Kubernetes, що інтегрує управління логікою певної хмари. [Cloud controller manager](/docs/concepts/architecture/cloud-controller/) дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері. + + + +Відокремлюючи логіку сумісності між Kubernetes і базовою хмарною інфраструктурою, компонент cloud-controller-manager дає змогу хмарним провайдерам випускати функції з іншою швидкістю порівняно з основним проєктом Kubernetes. diff --git a/content/uk/docs/reference/glossary/cloud-provider.md b/content/uk/docs/reference/glossary/cloud-provider.md new file mode 100644 index 0000000000000..af94274e7845c --- /dev/null +++ b/content/uk/docs/reference/glossary/cloud-provider.md @@ -0,0 +1,22 @@ +--- +title: Постачальник хмарних послуг +id: cloud-provider +date: 2018-04-12 +short_description: > + Організація, що надає платформу для хмарних обчислень. + +aka: +- Cloud Service Provider +tags: +- community +--- +Бізнес або інша організація, яка пропонує платформу для хмарних обчислень. + + + +Постачальники хмарних послуг (CSP, Cloud Service Providers), пропонують платформи або послуги хмарних обчислень. + +Багато хмарних постачальників пропонують керовану інфраструктуру (також називається Інфраструктура як Сервіс або IaaS). З керованою інфраструктурою хмарний постачальник відповідає за +сервери, зберігання та мережу, тоді як ви керуєте рівнями поверх цього, такими як запуск кластера Kubernetes. + +Вони також можуть пропонувати Kubernetes як керований сервіс; іноді його називають Платформою як Сервіс, або PaaS. З управлінням Kubernetes ваш хмарний постачальник відповідає за панель управління Kubernetes, а також за {{< glossary_tooltip term_id="node" text="вузли" >}} та інфраструктуру, на яку вони покладаються: мережа, зберігання, і, можливо, інші елементи, такі як балансувальники навантаження. diff --git a/content/uk/docs/reference/glossary/cluster-architect.md b/content/uk/docs/reference/glossary/cluster-architect.md new file mode 100644 index 0000000000000..b2fccacee7530 --- /dev/null +++ b/content/uk/docs/reference/glossary/cluster-architect.md @@ -0,0 +1,17 @@ +--- +title: Архітектор кластера +id: cluster-architect +date: 2018-04-12 +full_link: +short_description: > + Особа, яка проєктує інфраструктуру, що включає один чи кілька кластерів Kubernetes. + +aka: +tags: +- user-type +--- +Особа, яка проєктує інфраструктуру, що включає один чи кілька кластерів Kubernetes. + + + +Архітектори кластера цікавляться найкращими практиками розподілених систем, такими як: висока доступність та безпека. diff --git a/content/uk/docs/reference/glossary/cluster-infrastructure.md b/content/uk/docs/reference/glossary/cluster-infrastructure.md index 557180912abc0..f9f5f427c87cd 100644 --- a/content/uk/docs/reference/glossary/cluster-infrastructure.md +++ b/content/uk/docs/reference/glossary/cluster-infrastructure.md @@ -1,17 +1,14 @@ --- -# title: Cluster Infrastructure title: Інфраструктура кластера id: cluster-infrastructure date: 2019-05-12 full_link: -# short_description: > -# The infrastructure layer provides and maintains VMs, networking, security groups and others. short_description: > - Шар інфраструктури забезпечує і підтримує роботу ВМ, мережі, груп безпеки тощо. - + Шар інфраструктури, що надає та забезпечує віртуальні машини, мережі, групи безпеки та інші елементи. aka: tags: -- operations +- operation --- - -Шар інфраструктури забезпечує і підтримує роботу ВМ, мережі, груп безпеки тощо. +Шар інфраструктури, що надає та забезпечує віртуальні машини, мережі, групи безпеки та інші елементи. + + diff --git a/content/uk/docs/reference/glossary/cluster-operations.md b/content/uk/docs/reference/glossary/cluster-operations.md index 0b8ec9f510f29..17c29c5d2f147 100644 --- a/content/uk/docs/reference/glossary/cluster-operations.md +++ b/content/uk/docs/reference/glossary/cluster-operations.md @@ -1,16 +1,16 @@ --- -# title: Cluster Operations -title: Операції з кластером +title: Операційна діяльність id: cluster-operations date: 2019-05-12 full_link: -# short_description: > -# Activities such as upgrading the clusters, implementing security, storage, ingress, networking, logging and monitoring, and other operations involved in managing a Kubernetes cluster. short_description: > - Дії і операції, такі як оновлення кластерів, впровадження і використання засобів безпеки, сховища даних, Ingress'а, мережі, логування, моніторингу та інших операцій, пов'язаних з управлінням Kubernetes кластером. + Робота, повʼязана з управлінням кластером Kubernetes: керування щоденними операціями та координація оновлень. aka: tags: -- operations +- operation --- - -Дії і операції, такі як оновлення кластерів, впровадження і використання засобів безпеки, сховища даних, Ingress'а, мережі, логування, моніторингу та інших операцій, пов'язаних з управлінням Kubernetes кластером. +Робота, повʼязана з управлінням кластером Kubernetes: керування щоденними операціями та координація оновлень. + + + +Приклади операційних робіт включають: розгортання нових вузлів для масштабування кластера; виконання оновлень програмного забезпечення; впровадження заходів забезпечення безпеки; додавання чи видалення сховища; налаштування мережі кластера; управління загальнокластерною спостережуваністю та реагування на події. diff --git a/content/uk/docs/reference/glossary/cluster-operator.md b/content/uk/docs/reference/glossary/cluster-operator.md new file mode 100644 index 0000000000000..f4ca33d091985 --- /dev/null +++ b/content/uk/docs/reference/glossary/cluster-operator.md @@ -0,0 +1,21 @@ +--- +title: Оператор кластера +id: cluster-operator +date: 2018-04-12 +full_link: +short_description: > + Особа, яка налаштовує, керує та стежить за роботою кластера. + +aka: +tags: +- user-type +--- +Особа, яка налаштовує, керує та стежить за роботою кластера. + + + +Їхня основна відповідальність — забезпечення стабільної роботи кластера, що може включати в себе періодичні роботи з обслуговування чи оновлення.
+ +{{< note >}} +Оператори кластера та [шаблон "Оператор"](https://www.openshift.com/learn/topics/operators) це різні речі. Шаблон "Оператор" розширює Kubernetes API. +{{< /note >}} \ No newline at end of file diff --git a/content/uk/docs/reference/glossary/cluster.md b/content/uk/docs/reference/glossary/cluster.md index 4748e61236ac7..bf554f502259b 100644 --- a/content/uk/docs/reference/glossary/cluster.md +++ b/content/uk/docs/reference/glossary/cluster.md @@ -1,22 +1,20 @@ --- -# title: Cluster title: Кластер id: cluster date: 2019-06-15 full_link: -# short_description: > -# A set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node. short_description: > - Група робочих машин (їх називають вузлами), на яких запущені контейнерізовані застосунки. Кожен кластер має щонайменше один вузол. + Набір робочих машин, що називаються вузлами, які виконують контейнеризовані застосунки. Кожен кластер має принаймні один робочий вузол. aka: tags: - fundamental - operation --- - -Група робочих машин (їх називають вузлами), на яких запущені контейнерізовані застосунки. Кожен кластер має щонайменше один вузол. +Набір робочих машин, що називаються {{< glossary_tooltip text="вузлами" term_id="node" >}}, які виконують контейнеризовані застосунки. Кожен кластер має принаймні один робочий вузол. - -На робочих вузлах розміщуються Pod'и, які є складовими застосунку. Площина управління керує робочими вузлами і Pod'ами кластера. У прод оточеннях площина управління зазвичай розповсюджується на багато комп'ютерів, а кластер складається з багатьох вузлів для забезпечення відмовостійкості і високої доступності. + +Робочі вузли містять {{< glossary_tooltip text="Podʼи" term_id="pod" >}}, які є компонентами навантаження застосунку. +{{< glossary_tooltip text="Панель управління" term_id="control-plane" >}} керує робочими вузлами та Podʼами в кластері. В операційних середовищах панель управління, зазвичай, +працює на кількох компʼютерах, і кластер, як правило, має кілька вузлів, забезпечуючи стійкість до відмов та високу доступність. diff --git a/content/uk/docs/reference/glossary/cncf.md b/content/uk/docs/reference/glossary/cncf.md new file mode 100644 index 0000000000000..d0e27aeb3d63f --- /dev/null +++ b/content/uk/docs/reference/glossary/cncf.md @@ -0,0 +1,19 @@ +--- +title: Cloud Native Computing Foundation (CNCF) +id: cncf +date: 2019-05-26 +full_link: https://cncf.io/ +short_description: > + Cloud Native Computing Foundation + +aka: +tags: +- community +--- +Cloud Native Computing Foundation (CNCF) створює стійку екосистему та сприяє розвитку спільноти навколо [проєктів](https://www.cncf.io/projects/), які оркеструють контейнери як частину архітектури мікросервісів. + +Kubernetes є проєктом CNCF. + + + +Фундація CNCF є частиною [Linux Foundation](https://www.linuxfoundation.org/). Її місія — зробити хмарні обчислення повсюдними. diff --git a/content/uk/docs/reference/glossary/cni.md b/content/uk/docs/reference/glossary/cni.md new file mode 100644 index 0000000000000..213937b712e65 --- /dev/null +++ b/content/uk/docs/reference/glossary/cni.md @@ -0,0 +1,17 @@ +--- +title: Мережевий інтерфейс контейнера (Container Network Interface, CNI) +id: cni +date: 2018-05-25 +full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ +short_description: > + Втулки мережевого інтерфейсу контейнера (CNI) є типом мережевих втулків, які відповідають специфікації appc/CNI. + +aka: +tags: +- networking +--- +Втулки мережевого інтерфейсу контейнера (CNI) є типом мережевих втулків, які відповідають специфікації appc/CNI. + + + +* Для отримання інформації про Kubernetes та CNI дивіться [**Мережеві втулки**](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). diff --git a/content/uk/docs/reference/glossary/code-contributor.md b/content/uk/docs/reference/glossary/code-contributor.md new file mode 100644 index 0000000000000..d856bba2c1e37 --- /dev/null +++ b/content/uk/docs/reference/glossary/code-contributor.md @@ -0,0 +1,18 @@ +--- +title: Учасник, який робіть внесок до коду +id: code-contributor +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/tree/master/contributors/devel +short_description: > + Особа, яка розробляє та вносить внески до відкритого коду Kubernetes. + +aka: +tags: +- community +- user-type +--- +Особа, яка розробляє та вносить внески до відкритого коду Kubernetes. + + + +Вони також є активним {{< glossary_tooltip text="членами спільноти" term_id="member" >}}, які беруть участь в одній чи кількох групах {{< glossary_tooltip text="Special Interest Groups (SIGs)" term_id="sig" >}}. diff --git a/content/uk/docs/reference/glossary/configmap.md b/content/uk/docs/reference/glossary/configmap.md new file mode 100644 index 0000000000000..591482ec24c17 --- /dev/null +++ b/content/uk/docs/reference/glossary/configmap.md @@ -0,0 +1,18 @@ +--- +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="Podʼи" term_id="pod" >}} можуть використовувати ConfigMap як змінні середовища, аргументи командного рядка чи файли конфігурації у +{{< glossary_tooltip text="томі" term_id="volume" >}}. + + + +ConfigMap дозволяє відділити конфігурацію, специфічну для середовища, від {{< glossary_tooltip text="образів контейнерів" term_id="image" >}}, щоб ваші застосунки були легко переносимими. diff --git a/content/uk/docs/reference/glossary/container-env-variables.md b/content/uk/docs/reference/glossary/container-env-variables.md new file mode 100644 index 0000000000000..3d30ddc07708a --- /dev/null +++ b/content/uk/docs/reference/glossary/container-env-variables.md @@ -0,0 +1,17 @@ +--- +title: Змінні середовища контейнера +id: container-env-variables +date: 2018-04-12 +full_link: /docs/concepts/containers/container-environment/ +short_description: > + Змінні середовища контейнера — це пари name=value, які надають корисну інформацію контейнерам, які працюють у Podʼі. + +aka: +tags: +- fundamental +--- +Змінні середовища контейнера — це пари name=value, які надають корисну інформацію контейнерам, які працюють у {{< glossary_tooltip text="Podʼі" term_id="pod" >}}. + + + +Змінні середовища контейнера надають інформацію, необхідну для роботи контейнеризованих застосунків, разом із важливою інформацією про ресурси для {{< glossary_tooltip text="контейнерів" term_id="container" >}}. Наприклад, деталі файлової системи, інформація про сам контейнер та інші ресурси кластера, такі як кінцеві точки сервісів. diff --git a/content/uk/docs/reference/glossary/container-lifecycle-hooks.md b/content/uk/docs/reference/glossary/container-lifecycle-hooks.md new file mode 100644 index 0000000000000..ab9cc1a709e33 --- /dev/null +++ b/content/uk/docs/reference/glossary/container-lifecycle-hooks.md @@ -0,0 +1,17 @@ +--- +title: Хуки життєвого циклу контейнера +id: container-lifecycle-hooks +date: 2018-10-08 +full_link: /docs/concepts/containers/container-lifecycle-hooks/ +short_description: > + Хуки життєвого циклу надають події в життєвому циклі управління контейнером і дозволяють користувачеві виконувати код при настанні подій. + +aka: +tags: +- extension +--- +Хуки життєвого циклу надають події в {{< glossary_tooltip text="контейнері" term_id="container" >}} управління життєвим циклом і дозволяють користувачеві виконувати код при настанні подій. + + + +Для контейнерів доступні два хуки: PostStart, який виконується негайно після створення контейнера, і PreStop, який є блокуючим і викликається негайно перед завершенням контейнера. diff --git a/content/uk/docs/reference/glossary/container-runtime-interface.md b/content/uk/docs/reference/glossary/container-runtime-interface.md new file mode 100644 index 0000000000000..12f438e2d65b5 --- /dev/null +++ b/content/uk/docs/reference/glossary/container-runtime-interface.md @@ -0,0 +1,20 @@ +--- +title: Інтерфейс середовища виконання контейнерів +id: container-runtime-interface +date: 2021-11-24 +full_link: /docs/concepts/architecture/cri +short_description: > + Основний протокол для взаємодії між kubelet та середовищем виконання контейнерів. + +aka: + - Container Runtime Interface + - CRI +tags: + - cri +--- + +Основний протокол для взаємодії між {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} та середовищем виконання контейнерів. + + + +Інтерфейс середовища виконання контейнерів Kubernetes (CRI) визначає основний протокол [gRPC](https://grpc.io) для взаємодії між [компонентами вузла](/docs/concepts/overview/components/#node-components) {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} та {{< glossary_tooltip text="середовищем виконання контейнерів" term_id="container-runtime" >}}. diff --git a/content/uk/docs/reference/glossary/container-runtime.md b/content/uk/docs/reference/glossary/container-runtime.md new file mode 100644 index 0000000000000..f77c4d176062d --- /dev/null +++ b/content/uk/docs/reference/glossary/container-runtime.md @@ -0,0 +1,20 @@ +--- +title: Container Runtime +id: container-runtime +date: 2019-06-05 +full_link: /docs/setup/production-environment/container-runtimes +short_description: > + Середовище виконання контейнера — це програмне забезпечення, яке відповідає за запуск та виконання контейнерів. + +aka: +tags: +- fundamental +- workload +--- +Основний компонент, який дозволяє Kubernetes ефективно запускати контейнери. Він відповідає за керування виконанням і життєвим циклом контейнерів у середовищі Kubernetes. + + + +Kubernetes підтримує середовища виконання контейнерів, такі як +{{< glossary_tooltip term_id="containerd" >}}, {{< glossary_tooltip term_id="cri-o" >}}, та будь-яку іншу реалізацію [Kubernetes CRI (інтерфейс виконання контейнерів)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). + diff --git a/content/uk/docs/reference/glossary/container.md b/content/uk/docs/reference/glossary/container.md new file mode 100644 index 0000000000000..a8fa218e96e9e --- /dev/null +++ b/content/uk/docs/reference/glossary/container.md @@ -0,0 +1,18 @@ +--- +title: Контейнер +id: container +date: 2018-04-12 +full_link: /docs/concepts/containers/ +short_description: > + Легкий та переносний виконуваний образ, який містить програмне забезпечення та всі його залежності. + +aka: +tags: +- fundamental +- workload +--- +Легкий та переносний виконуваний образ, який містить програмне забезпечення та всі його залежності. + + + +Контейнери відокремлюють застосунки від базової інфраструктури хосту, щоб полегшити їх розгортання в різних хмарних середовищах або операційних системах та полегшити масштабування. Застосунки, які працюють в межах контейнерів, називають контейнеризованими застосунками. Процес упаковування цих застосунків та їх залежностей в образ контейнера називається контейнеризацією. diff --git a/content/uk/docs/reference/glossary/containerd.md b/content/uk/docs/reference/glossary/containerd.md new file mode 100644 index 0000000000000..5973c2cabe7ac --- /dev/null +++ b/content/uk/docs/reference/glossary/containerd.md @@ -0,0 +1,17 @@ +--- +title: containerd +id: containerd +date: 2019-05-14 +full_link: https://containerd.io/docs/ +short_description: > + Середовище виконання контейнера з акцентом на простоту, надійність та переносимість. + +aka: +tags: +- tool +--- + Середовище виконання контейнера з акцентом на простоту, надійність та переносимість. + + + +containerd — це середовище виконання {{< glossary_tooltip text="контейнера" term_id="container" >}}, яке працює як служба Linux або Windows. containerd відповідає за отримання та зберігання образів контейнерів, виконання контейнерів, забезпечення мережевого доступу та інше. diff --git a/content/uk/docs/reference/glossary/contributor.md b/content/uk/docs/reference/glossary/contributor.md new file mode 100644 index 0000000000000..433ba1e32b354 --- /dev/null +++ b/content/uk/docs/reference/glossary/contributor.md @@ -0,0 +1,18 @@ +--- +title: Учасник +id: contributor +date: 2018-04-12 +full_link: +short_description: > + Особа, яка надає код, документацію або свій час для допомоги у проєкті чи спільноті Kubernetes. + +aka: +- Сontributor +tags: +- community +--- +Особа, яка надає код, документацію або свій час для допомоги у проєкті чи спільноті Kubernetes. + + + +Внесками можуть бути запити на втягування змін (PR, pull request), виправлення помилок, відгуки, участь в {{< glossary_tooltip text="Special interest groups (SIG)" term_id="sig" >}}, організація заходів спільноти та інше. diff --git a/content/uk/docs/reference/glossary/control-plane.md b/content/uk/docs/reference/glossary/control-plane.md index 1fb28e40a4df7..5b1e94385c7d8 100644 --- a/content/uk/docs/reference/glossary/control-plane.md +++ b/content/uk/docs/reference/glossary/control-plane.md @@ -1,17 +1,25 @@ --- -# title: Control Plane -title: Площина управління +title: Панель управління id: control-plane date: 2019-05-12 full_link: -# short_description: > -# The container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. short_description: > - Шар оркестрації контейнерів, який надає API та інтерфейси для визначення, розгортання і управління життєвим циклом контейнерів. + Шар оркестрування контейнерів, який надає API та інтерфейси для виявлення, розгортання та управління життєвим циклом контейнерів. aka: tags: - fundamental --- - -Шар оркестрації контейнерів, який надає API та інтерфейси для визначення, розгортання і управління життєвим циклом контейнерів. +Шар оркестрування контейнерів, який надає 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="master" term_id="master" >}}. diff --git a/content/uk/docs/reference/glossary/controller.md b/content/uk/docs/reference/glossary/controller.md new file mode 100644 index 0000000000000..a2fc1d9fd23b4 --- /dev/null +++ b/content/uk/docs/reference/glossary/controller.md @@ -0,0 +1,21 @@ +--- +title: Контролер +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + Контролер — цикл управління, що спостерігає за загальним станом кластера через apiserver і вносить зміни в намаганні наблизити поточний стан до бажаного. + +aka: +tags: +- architecture +- fundamental +--- + +У Kubernetes контролери — це цикли управління, які спостерігають за станом вашого {{< glossary_tooltip term_id="cluster" text="кластера">}}, а потім вносять або запитують зміни там, де це необхідно. Кожен контролер намагається наблизити поточний стан кластера до бажаного. + + + +Контролери спостерігають за загальним станом вашого кластера через {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} (частина {{< glossary_tooltip term_id="control-plane" text="Панелі управління" >}}). + +Деякі контролери також працюють всередині панелі управління, забезпечуючи цикли управління, які є ключовими для операцій Kubernetes. Наприклад, контролер розгортання, контролер демонів, контролер просторів імен та контролер постійних томів (і інші) всі працюють всередині {{< glossary_tooltip term_id="kube-controller-manager" >}}. diff --git a/content/uk/docs/reference/glossary/cri-o.md b/content/uk/docs/reference/glossary/cri-o.md new file mode 100644 index 0000000000000..04b47aa8aa4c7 --- /dev/null +++ b/content/uk/docs/reference/glossary/cri-o.md @@ -0,0 +1,20 @@ +--- +title: CRI-O +id: cri-o +date: 2019-05-14 +full_link: https://cri-o.io/#what-is-cri-o +short_description: > + CRI-O — це легке середовище виконання контейнера, спеціально розроблений для Kubernetes. + +aka: +tags: +- tool +--- + +Інструмент, який дозволяє використовувати середовище виконання контейнера OCI з Kubernetes CRI. + + + +CRI-O — це реалізація {{< glossary_tooltip term_id="cri" >}}, яка дозволяє використовувати середовище виконання контейнера, сумісне зі специфікацією Open Container Initiative (OCI) [runtime spec](https://www.github.com/opencontainers/runtime-spec). + +Використання CRI-O дозволяє Kubernetes використовувати будь-яке середовище виконання контейнерів, сумісе з OCI, як середовище виконання контейнерів для запуску {{< glossary_tooltip text="Podʼів" term_id="pod" >}}, а також завантажувати OCI образи контейнерів з віддалених реєстрів. diff --git a/content/uk/docs/reference/glossary/cri.md b/content/uk/docs/reference/glossary/cri.md new file mode 100644 index 0000000000000..0a66dfc71c62f --- /dev/null +++ b/content/uk/docs/reference/glossary/cri.md @@ -0,0 +1,19 @@ +--- +title: Інтерфейс середовища виконання контейнера (CRI) +id: cri +date: 2019-03-07 +full_link: /docs/concepts/overview/components/#container-runtime +short_description: > + API для інтеграції середовища виконання контейнерів з kubelet + + +aka: +tags: +- fundamental +--- + +Інтерфейс середовища виконання контейнера (CRI) — це API для інтеграції середовища виконання контейнерів з {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} на вузлі. + + + +Для отримання додаткової інформації дивіться [CRI](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) API та специфікації. diff --git a/content/uk/docs/reference/glossary/cronjob.md b/content/uk/docs/reference/glossary/cronjob.md new file mode 100644 index 0000000000000..45ad4a2ee3efb --- /dev/null +++ b/content/uk/docs/reference/glossary/cronjob.md @@ -0,0 +1,19 @@ +--- +title: CronJob +id: cronjob +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/cron-jobs/ +short_description: > + Повторювана задача (Job), яка виконується за встановленим розкладом. + +aka: +tags: +- core-object +- workload +--- + +Керує [Job](/docs/concepts/workloads/controllers/job/), який виконується за встановленим розкладом. + + + +Подібно до рядка у файлі *crontab*, обʼєкт CronJob вказує розклад за допомогою формату [cron](https://en.wikipedia.org/wiki/Cron). diff --git a/content/uk/docs/reference/glossary/csi.md b/content/uk/docs/reference/glossary/csi.md new file mode 100644 index 0000000000000..ffe623ab4f525 --- /dev/null +++ b/content/uk/docs/reference/glossary/csi.md @@ -0,0 +1,21 @@ +--- +title: Інтерфейс зберігання контейнерів (CSI) +id: csi +date: 2018-06-25 +full_link: /docs/concepts/storage/volumes/#csi +short_description: > + Інтерфейс зберігання контейнерів (CSI) визначає стандартний інтерфейс для взаємодії з системами зберігання з контейнерами. + +aka: +tags: +- storage +--- + +Інтерфейс зберігання контейнерів (CSI) визначає стандартний інтерфейс для взаємодії з системами зберігання з контейнерами. + + + +CSI дозволяє вендорам створювати спеціальні втулки зберігання для Kubernetes, не включаючи їх до репозиторію Kubernetes (зовнішні втулки). Щоб використовувати драйвер CSI від постачальника зберігання, спочатку потрібно [розгорнути його у вашому кластері](https://kubernetes-csi.github.io/docs/deploying.html). Після цього ви зможете створити [клас зберігання](/docs/concepts/storage/storage-classes/) (Storage Class), який використовує цей драйвер CSI. + +* [CSI в документації Kubernetes](/docs/concepts/storage/volumes/#csi) +* [Список доступних драйверів CSI](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/uk/docs/reference/glossary/customresourcedefinition.md b/content/uk/docs/reference/glossary/customresourcedefinition.md new file mode 100644 index 0000000000000..6c28c8052ab25 --- /dev/null +++ b/content/uk/docs/reference/glossary/customresourcedefinition.md @@ -0,0 +1,20 @@ +--- +title: CustomResourceDefinition +id: CustomResourceDefinition +date: 2018-04-12 +full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ +short_description: > + Власний код, який визначає ресурс для додавання до сервера API вашого кластера Kubernetes без створення власного сервера. + +aka: +tags: +- fundamental +- operation +- extension +--- + +Власний код, який визначає ресурс для додавання до сервера API вашого кластера Kubernetes без створення власного сервера. + + + +Визначення власного ресурсу (Custom Resource Definitions) дозволяють розширювати API Kubernetes для вашого середовища, якщо публічно підтримувані ресурси API не можуть задовольнити ваші потреби. diff --git a/content/uk/docs/reference/glossary/daemonset.md b/content/uk/docs/reference/glossary/daemonset.md new file mode 100644 index 0000000000000..93e49813176c7 --- /dev/null +++ b/content/uk/docs/reference/glossary/daemonset.md @@ -0,0 +1,20 @@ +--- +title: DaemonSet +id: daemonset +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/daemonset +short_description: > + Забезпечує запуск копії обʼєкта Pod на певному наборі вузлів у кластері. + +aka: +tags: +- fundamental +- core-object +- workload +--- + +Забезпечує запуск копії обʼєкта {{< glossary_tooltip text="Pod" term_id="pod" >}} на певному наборі вузлів у {{< glossary_tooltip text="кластері." term_id="cluster" >}} + + + +Використовується для розгортання системних служб, таких як збирачі логів та агенти моніторингу, які, як правило, повинні працювати на кожному {{< glossary_tooltip term_id="node" text="вузлі" >}}. diff --git a/content/uk/docs/reference/glossary/data-plane.md b/content/uk/docs/reference/glossary/data-plane.md index 263a544010700..3b208300b2fa0 100644 --- a/content/uk/docs/reference/glossary/data-plane.md +++ b/content/uk/docs/reference/glossary/data-plane.md @@ -1,17 +1,15 @@ --- -# title: Data Plane -title: Площина даних +title: Data Plane id: data-plane date: 2019-05-12 full_link: -# short_description: > -# The layer that provides capacity such as CPU, memory, network, and storage so that the containers can run and connect to a network. short_description: > - Шар, який надає контейнерам ресурси, такі як ЦПУ, пам'ять, мережа і сховище даних для того, щоб контейнери могли працювати і підключатися до мережі. + Шар, який надає контейнерам ресурси, такі як ЦПУ, памʼять, мережа і сховище даних для того, щоб контейнери могли працювати та підʼєднуватись до мережі. aka: tags: - fundamental --- - -Шар, який надає контейнерам ресурси, такі як ЦПУ, пам'ять, мережа і сховище даних для того, щоб контейнери могли працювати і підключатися до мережі. +Шар, який надає контейнерам ресурси, такі як ЦПУ, пам'ять, мережа і сховище даних для того, щоб контейнери могли працювати та підʼєднуватись до мережі. + + diff --git a/content/uk/docs/reference/glossary/deployment.md b/content/uk/docs/reference/glossary/deployment.md index 4c9c5ba3b90bc..0adc03edf7377 100644 --- a/content/uk/docs/reference/glossary/deployment.md +++ b/content/uk/docs/reference/glossary/deployment.md @@ -3,21 +3,17 @@ title: Deployment id: deployment date: 2018-04-12 full_link: /docs/concepts/workloads/controllers/deployment/ -# short_description: > -# An API object that manages a replicated application. short_description: > - Об'єкт API, що керує реплікованим застосунком. + Керує реплікованим застосунком у вашому кластері. -aka: +aka: tags: - fundamental - core-object - workload --- - -Об'єкт API, що керує реплікованим застосунком. +Обʼєкт API, який керує реплікованим застосунком, зазвичай, запускаючи Podʼи без збереження стану. - + - -Кожна репліка являє собою {{< glossary_tooltip term_id="pod" text="Pod" >}}; Pod'и розподіляються між вузлами кластера. +Кожна репліка представлена {{< glossary_tooltip term_id="pod" text="Podʼом" >}}; Podʼи розподіляються серед {{< glossary_tooltip text="вузлів" term_id="node" >}} кластера. Для робочих навантажень, які дійсно вимагають збереження стану, розгляньте використання {{< glossary_tooltip term_id="StatefulSet" >}}. \ No newline at end of file diff --git a/content/uk/docs/reference/glossary/developer.md b/content/uk/docs/reference/glossary/developer.md new file mode 100644 index 0000000000000..9f782b1194644 --- /dev/null +++ b/content/uk/docs/reference/glossary/developer.md @@ -0,0 +1,19 @@ +--- +title: Розробник (розʼяснення) +id: developer +date: 2018-04-12 +full_link: +short_description: > + Може вказувати на: Розробника застосунків, Учасника що робіть внесок до коду Kubernetes або Розробника платформи. + +aka: +tags: +- community +- user-type +--- + +Може вказувати на: {{< glossary_tooltip text="Розробника застосунків" term_id="application-developer" >}}, {{< glossary_tooltip text="Учасника, який робіть внесок до коду Kubernetes" term_id="code-contributor" >}}, або {{< glossary_tooltip text="Розробника платформ" term_id="platform-developer" >}}. + + + +Цей перевантажений термін може мати різні значення залежно від контексту. diff --git a/content/uk/docs/reference/glossary/device-plugin.md b/content/uk/docs/reference/glossary/device-plugin.md new file mode 100644 index 0000000000000..123144f7ca479 --- /dev/null +++ b/content/uk/docs/reference/glossary/device-plugin.md @@ -0,0 +1,19 @@ +--- +title: Втулок пристрою +id: device-plugin +date: 2019-02-02 +full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ +short_description: > + Програмні розширення для надання Podʼам доступу до пристроїв, які потребують вендор-специфічної ініціалізації чи налаштувань. +aka: +tags: +- fundamental +- extension +--- +Втулки пристроїв працюють на вузлах кластера ({{< glossary_tooltip term_id="node" text="Nodes" >}}) та забезпечують {{< glossary_tooltip term_id="pod" text="Podʼам" >}} доступ до ресурсів, таких як локальне обладнання, яке вимагає вендор-специфічної ініціалізації чи налаштувань. + + + +Втулки пристроїв оголошують ресурси для {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}, щоб робочі {{< glossary_tooltip term_id="pod" text="Podʼи" >}} мали доступ до апаратних можливостей, повʼязаних з вузлом, на якому запущений цей Pod. Ви можете розгортати втулок пристрою як {{< glossary_tooltip term_id="daemonset" >}}, або встановлювати програмне забезпечення втулка пристрою безпосередньо на кожний відповідний вузол. + +Докладніше дивіться в розділі [Втулки пристроїв](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). diff --git a/content/uk/docs/reference/glossary/disruption.md b/content/uk/docs/reference/glossary/disruption.md new file mode 100644 index 0000000000000..61644b7f45891 --- /dev/null +++ b/content/uk/docs/reference/glossary/disruption.md @@ -0,0 +1,19 @@ +--- +title: Розлад +id: розлад +date: 2019-09-10 +full_link: /docs/concepts/workloads/pods/disruptions/ +short_description: > + Подія, що призводить до виходу з ладу Pod(ів) +aka: +- Disruption +tags: +- fundamental +--- +Розлади — це події, які призводять до виходу з ладу одного чи кількох {{< glossary_tooltip term_id="pod" text="Podʼів" >}}. Розлад має наслідки для ресурсів робочого навантаження, таких як {{< glossary_tooltip term_id="deployment" >}}, які покладаються постраждалі Podʼі. + + + +Якщо ви, як оператор кластера, знищуєте Pod, який належить застосунку, Kubernetes називає це _добровільним розладом_. Якщо Pod виходить з ладу через відмову вузла або відмову, яка впливає на широку зону відмов, Kubernetes називає це _невільним розладом_. + +Докладніше дивіться в розділі [Розлади](/docs/concepts/workloads/pods/disruptions/). diff --git a/content/uk/docs/reference/glossary/docker.md b/content/uk/docs/reference/glossary/docker.md new file mode 100644 index 0000000000000..8c1e6c02fe8dd --- /dev/null +++ b/content/uk/docs/reference/glossary/docker.md @@ -0,0 +1,17 @@ +--- +title: Docker +id: docker +date: 2018-04-12 +full_link: https://docs.docker.com/engine/ +short_description: > + Docker — програмне забезпеяення, що впроваджує віртуалізацію на рівні операційної системи, також відому як контейнери. + +aka: +tags: +- fundamental +--- +Docker (зокрема, Docker Engine) — це програмна технологія, яка забезпечує віртуалізацію на рівні операційної системи, також відому як {{< glossary_tooltip text="контейнери" term_id="container" >}}. + + + +Docker використовує функції ізоляції ресурсів ядра Linux, такі як cgroups та простори імен ядра, а також файлову систему, здатну до обʼєднання, таку як OverlayFS та інші, щоб дозволити незалежним контейнерам працювати в одному екземплярі Linux, уникаючи накладних витрат на запуск та підтримку віртуальних машин (ВМ). diff --git a/content/uk/docs/reference/glossary/dockershim.md b/content/uk/docs/reference/glossary/dockershim.md new file mode 100644 index 0000000000000..7e601bbc9bcc4 --- /dev/null +++ b/content/uk/docs/reference/glossary/dockershim.md @@ -0,0 +1,17 @@ +--- +title: Dockershim +id: dockershim +date: 2022-04-15 +full_link: /dockershim +short_description: > + Компонент Kubernetes версії 1.23 та раніше, який дозволяє системним компонентам Kubernetes взаємодіяти з Docker Engine. + +aka: +tags: +- fundamental +--- +Dockershim є компонентом Kubernetes версії 1.23 та раніше. Він дозволяє {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} взаємодіяти з {{< glossary_tooltip text="Docker Engine" term_id="docker" >}}. + + + +Починаючи з версії 1.24, dockershim був вилучений з Kubernetes. Докладніше дивіться в [Dockershim FAQ](/dockershim). diff --git a/content/uk/docs/reference/glossary/downstream.md b/content/uk/docs/reference/glossary/downstream.md new file mode 100644 index 0000000000000..9b7f40c35b05e --- /dev/null +++ b/content/uk/docs/reference/glossary/downstream.md @@ -0,0 +1,19 @@ +--- +title: Downstream (розʼяснення) +id: downstream +date: 2018-04-12 +full_link: +short_description: > + Може вказувати на: код в екосистемі Kubernetes, який залежить від основної кодової бази Kubernetes або відгалуженого репозиторію. + +aka: +tags: +- community +--- + +Може вказувати на: код в екосистемі Kubernetes, який залежить від основної кодової бази Kubernetes або відгалуженого репозиторію. + + + +* У **Спільноті Kubernetes**: в розмові часто використовують термін *downstream*, щоб вказати на екосистему, код або інструменти сторонніх розробників, які залежать від основної кодової бази Kubernetes. Наприклад, нову функцію в Kubernetes можуть використовувати додатки *downstream* для поліпшення їхньої функціональності. +* У **GitHub** чи **git**: зазвичай відгалужений репозиторій називається *downstream*, тоді як висхідний репозитарій вважається *upstream*. diff --git a/content/uk/docs/reference/glossary/downward-api.md b/content/uk/docs/reference/glossary/downward-api.md new file mode 100644 index 0000000000000..ad186087298f0 --- /dev/null +++ b/content/uk/docs/reference/glossary/downward-api.md @@ -0,0 +1,27 @@ +--- +title: Downward API +id: downward-api +date: 2022-03-21 +short_description: > + Механізм використання Kubernetes для надання значень полів Podʼу та контейнера коду, що працює в контейнері. + +aka: +full_link: /docs/concepts/workloads/pods/downward-api/ +tags: +- architecture +--- + +Механізм Kubernetes для надання значень полів Podʼу та контейнера коду, що працює в контейнері + + + +Іноді контейнеру корисно мати інформацію про себе, без необхідності вносити зміни до коду контейнера, який безпосередньо зʼєднує його з Kubernetes. + +Механізм downward API Kubernetes дозволяє контейнерам використовувати інформацію про себе або їхній контекст в кластері Kubernetes. Застосунки в контейнерах можуть мати доступ до цієї інформації, без потреби для них діяти як клієнт Kubernetes API. + +Є два способи надання доступу до полів Podʼу та контейнера для робочого контейнера: + +* використання [змінних оточення](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) +* використання [томів `downwardAPI`](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) + +Разом ці два способи надання доступу до полів Podʼів та контейнера називаються _downward API_. diff --git a/content/uk/docs/reference/glossary/dynamic-volume-provisioning.md b/content/uk/docs/reference/glossary/dynamic-volume-provisioning.md new file mode 100644 index 0000000000000..8f6fea1ad92fa --- /dev/null +++ b/content/uk/docs/reference/glossary/dynamic-volume-provisioning.md @@ -0,0 +1,18 @@ +--- +title: Динамічне створення томів сховища +id: dynamicvolumeprovisioning +date: 2018-04-12 +full_link: /docs/concepts/storage/dynamic-provisioning +short_description: > + Дозволяє користувачам автоматично створювати томи сховища за запитом. + +aka: +tags: +- core-object +- storage +--- +Дозволяє користувачам автоматично створювати томи сховища за запитом. + + + +Динамічне створення томів усуває потребу в адміністраторів кластерів у попередньому їх створені. Замість цього сховища автоматично створюються за запитом користувача. Динамічне створення томів ґрунтується на обʼєкті API, {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}, який посилається на {{< glossary_tooltip text="Volume Plugin" term_id="volume-plugin" >}}, що створює {{< glossary_tooltip text="Volume" term_id="volume" >}}, та набір параметрів для передачі до Volume Plugin. diff --git a/content/uk/docs/reference/glossary/endpoint-slice.md b/content/uk/docs/reference/glossary/endpoint-slice.md new file mode 100644 index 0000000000000..d23285a4d602e --- /dev/null +++ b/content/uk/docs/reference/glossary/endpoint-slice.md @@ -0,0 +1,18 @@ +--- +title: EndpointSlice +id: endpoint-slice +date: 2018-04-12 +full_link: /docs/concepts/services-networking/endpoint-slices/ +short_description: > + Спосіб групування мережевих точок доступу разом із ресурсами Kubernetes. + +aka: +- EndpointSlice +tags: +- networking +--- +Спосіб групування мережевих точок доступу разом із ресурсами Kubernetes. + + + +Масштабований та розширюваний спосіб групування мережевих точок доступу. Ці дані можуть використовуватися {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} для встановлення мережевих маршрутів на кожному {{< glossary_tooltip text="вузлі" term_id="node" >}}. diff --git a/content/uk/docs/reference/glossary/endpoint.md b/content/uk/docs/reference/glossary/endpoint.md new file mode 100644 index 0000000000000..5f6d7410cb2b8 --- /dev/null +++ b/content/uk/docs/reference/glossary/endpoint.md @@ -0,0 +1,16 @@ +--- +title: Endpoints +id: endpoints +date: 2020-04-23 +full_link: +short_description: > + Endpoints відстежують IP-адреси Podʼів з відповідними селекторами Serviceʼу. + +aka: +tags: +- networking +--- +Endpoints відстежують IP-адреси Podʼів з відповідними {{< glossary_tooltip text="селекторами" term_id="selector" >}} Serviceʼу. + + +Endpoints можуть бути налаштовані вручну для {{< glossary_tooltip text="Serviceʼів" term_id="service" >}}, які не мають визначених селекторів. Ресурс {{< glossary_tooltip text="EndpointSlice" term_id="endpoint-slice" >}} надає масштабовану та розширювану альтернативу Endpoints. diff --git a/content/uk/docs/reference/glossary/ephemeral-container.md b/content/uk/docs/reference/glossary/ephemeral-container.md new file mode 100644 index 0000000000000..48052016c23b0 --- /dev/null +++ b/content/uk/docs/reference/glossary/ephemeral-container.md @@ -0,0 +1,19 @@ +--- +title: Ефемерний Контейнер +id: ephemeral-container +date: 2019-08-26 +full_link: /docs/concepts/workloads/pods/ephemeral-containers/ +short_description: > + Тип контейнера, який можна тимчасово запустити всередині Podʼа. + +aka: +tags: +- fundamental +--- +{{< glossary_tooltip term_id="container" >}} тип, який можна тимчасово запустити всередині {{< glossary_tooltip term_id="pod" text="Podʼа">}}. + + + +Якщо вам потрібно дослідити Pod, який працює з проблемами, ви можете додати ефемерний контейнер до цього Podʼа і провести діагностику. У ефемерних контейнерів немає гарантій ресурсів чи планування, і ви не повинні використовувати їх для запуску будь-якої частини навантаження самого Podʼа. + +Ефемерні контейнери не підтримуються {{< glossary_tooltip text="статичними Podʼами" term_id="static-pod" >}}. diff --git a/content/uk/docs/reference/glossary/etcd.md b/content/uk/docs/reference/glossary/etcd.md new file mode 100644 index 0000000000000..cea839bf866c8 --- /dev/null +++ b/content/uk/docs/reference/glossary/etcd.md @@ -0,0 +1,20 @@ +--- +title: etcd +id: etcd +date: 2018-04-12 +full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ +short_description: > + Сумісне та високодоступне сховище ключ-значення, яке використовується як сховище Kubernetes для резервування всіх даних кластера. + +aka: +tags: +- architecture +- storage +--- +Сумісне та високодоступне сховище ключ-значення, яке використовується як сховище Kubernetes для резервування всіх даних кластера. + + + +Якщо ваш кластер Kubernetes використовує etcd як сховище для резервування, переконайтеся, що у вас є [план резервного копіювання](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) даних. + +Ви можете знайти докладну інформацію про etcd в офіційній [документації](https://etcd.io/docs/). diff --git a/content/uk/docs/reference/glossary/event.md b/content/uk/docs/reference/glossary/event.md new file mode 100644 index 0000000000000..37002652a73f5 --- /dev/null +++ b/content/uk/docs/reference/glossary/event.md @@ -0,0 +1,21 @@ +--- +title: Подія +id: event +date: 2022-01-16 +full_link: /docs/reference/kubernetes-api/cluster-resources/event-v1/ +short_description: > + Події — це обʼєкти Kubernetes, які описують зміну стану в системі. + +aka: +tags: +- core-object +- fundamental +--- +Подія – це обʼєкт Kubernetes, який описує зміну стану або помітні події в системі. + + +Події мають обмежений час зберігання, а причини та повідомлення можуть змінюватися з часом. Споживачі подій не повинні покладатися на терміни події із зазначеною причиною, що відображає стан основної причини, або продовження існування подій з цієї причини. + +Події слід розглядати як інформаційні дані, що надаються як найкраще, та які є додатковими даними. + +У Kubernetes [аудит](/docs/tasks/debug/debug-cluster/audit/) генерує інший вид Події (API-група `audit.k8s.io`). diff --git a/content/uk/docs/reference/glossary/eviction.md b/content/uk/docs/reference/glossary/eviction.md new file mode 100644 index 0000000000000..adbad7ca87f87 --- /dev/null +++ b/content/uk/docs/reference/glossary/eviction.md @@ -0,0 +1,21 @@ +--- +title: Вивільнення +id: eviction +date: 2021-05-08 +full_link: /docs/concepts/scheduling-eviction/ +short_description: > + Процес завершення роботи одного чи декількох Podʼів на Вузлах. + +aka: +tags: +- operation +--- + +Вивільнення — це процес завершення роботи одного чи декількох Podʼів на Вузлах. + + + +Існують два види вивільнення: + +* [Вивільнення внаслідок тиску на вузол](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [Вивільнення, ініційоване API](/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/uk/docs/reference/glossary/extensions.md b/content/uk/docs/reference/glossary/extensions.md new file mode 100644 index 0000000000000..a31fd3ba0f1fe --- /dev/null +++ b/content/uk/docs/reference/glossary/extensions.md @@ -0,0 +1,20 @@ +--- +title: Розширення +id: Extensions +date: 2019-02-01 +full_link: /docs/concepts/extend-kubernetes/#extensions +short_description: > + Розширення — це компоненти програмного забезпечення, які розширюють і глибоко інтегруються з Kubernetes для підтримки + нових типів обладнання. + +aka: +tags: +- fundamental +- extension +--- +Розширення — це компоненти програмного забезпечення, які розширюють і глибоко інтегруються з Kubernetes для підтримки нових типів обладнання. + + + +Багато адміністраторів кластерів використовують екземпляри Kubernetes, дистрибутиви встановлені самостійно чи надані постачальниками послуг. Ці кластери вже мають попередньо встановлені розширення. В результаті більшість користувачів Kubernetes можуть не потребувати встановлення +[розширень](/docs/concepts/extend-kubernetes/), і ще менше користувачів можуть потребувати створення нових. diff --git a/content/uk/docs/reference/glossary/feature-gates.md b/content/uk/docs/reference/glossary/feature-gates.md new file mode 100644 index 0000000000000..d74fbf29aefd9 --- /dev/null +++ b/content/uk/docs/reference/glossary/feature-gates.md @@ -0,0 +1,20 @@ +--- +title: Функціональні можливості +id: feature-gate +date: 2023-01-12 +full_link: /docs/reference/command-line-tools-reference/feature-gates/ +short_description: > + Спосіб перевірки увімкення тих чи інших функцій Kubernetes у вашому кластері. + +aka: +- Feature gate +tags: +- fundamental +- operation +--- + +Функціональні можливості містять набір ключів (прихованих значень), які ви можете використовувати для контролю того, які функції Kubernetes увімкнені у вашому кластері. + + + +Ви можете вмикати або вимикати функції, використовуючи прапорець командного рядка `--feature-gates` для кожного компонента Kubernetes. Кожен компонент Kubernetes дозволяє вам увімкнути чи вимкнути набори функціональних можливостей, які є відповідними для цього компонента. У документації Kubernetes перелічено всі поточні [набори функціональних можливостей](/docs/reference/command-line-tools-reference/feature-gates/) та те, що вони контролюють. diff --git a/content/uk/docs/reference/glossary/finalizer.md b/content/uk/docs/reference/glossary/finalizer.md new file mode 100644 index 0000000000000..8713cc629c3d1 --- /dev/null +++ b/content/uk/docs/reference/glossary/finalizer.md @@ -0,0 +1,21 @@ +--- +title: Завершувач +id: finalizer +date: 2021-07-07 +full_link: /docs/concepts/overview/working-with-objects/finalizers/ +short_description: > + Ключ простору імен, який наказує Kubernetes чекати до виконання певних умов перед тим, як повністю видалити обʼєкт, позначений для видалення. + +aka: +- Finalizer +tags: +- fundamental +- operation +--- +Завершувачі — це ключі простору імен, які наказують Kubernetes чекати до виконання певних умов перед тим, як повністю видаляти ресурси, позначені для видалення. Завершувачі попереджають {{}} про очищення ресурсів, які належать обʼєкту, що вилучається. + + + +Коли ви наказуєте Kubernetes видалити обʼєкт, для якого є завершувачі, API Kubernetes позначає обʼєкт для видалення, заповнюючи поле `.metadata.deletionTimestamp`, і повертає статус-код `202` (HTTP "Accepted"). Цільовий обʼєкт залишається в стані завершення, поки панель управління чи інші компоненти виконують дії, визначені завершувачами. Після завершення цих дій контролер видаляє відповідні завершувачі з цільового обʼєкта. Коли поле `metadata.finalizers` порожнє, Kubernetes вважає видалення завершеним і видаляє обʼєкт. + +Ви можете використовувати завершувачі для управління {{}} ресурсів. Наприклад, ви можете визначити завершувач для очищення повʼязаних ресурсів чи інфраструктури перед тим, як контролер видалить цільовий ресурс. diff --git a/content/uk/docs/reference/glossary/flexvolume.md b/content/uk/docs/reference/glossary/flexvolume.md new file mode 100644 index 0000000000000..6f6fbdb694a4b --- /dev/null +++ b/content/uk/docs/reference/glossary/flexvolume.md @@ -0,0 +1,21 @@ +--- +title: FlexVolume +id: flexvolume +date: 2018-06-25 +full_link: /docs/concepts/storage/volumes/#flexvolume +short_description: > + FlexVolume — інтерфейс, зараз визнаний застарілим, для створення втулків зовнішніх томів. {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} – це новіший інтерфейс, який вирішує кілька проблем з FlexVolume. + +aka: +tags: +- storage +--- +FlexVolume — інтерфейс, зараз визнаний застарілим, для створення втулків зовнішніх томів. {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} — це новіший інтерфейс, який вирішує кілька проблем з FlexVolume. + + + +FlexVolumes дозволяють користувачам писати свої власні драйвери та додавати підтримку своїх томів в Kubernetes. Бінарні файли та залежності драйверів FlexVolume повинні бути встановлені на хостових машинах. Це вимагає прав адміністратора. Група Storage SIG рекомендує використовувати {{< glossary_tooltip text="CSI" term_id="csi" >}} драйвер, якщо це можливо, оскільки він вирішує обмеження, повʼязані з FlexVolumes. + +* [FlexVolume в документації Kubernetes](/docs/concepts/storage/volumes/#flexvolume) +* [Додаткова інформація про FlexVolumes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) +* [ЧаПи про втулки роботи з томами в Kubernetes для постачальників рішень](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) \ No newline at end of file diff --git a/content/uk/docs/reference/glossary/garbage-collection.md b/content/uk/docs/reference/glossary/garbage-collection.md new file mode 100644 index 0000000000000..21c957bb283f4 --- /dev/null +++ b/content/uk/docs/reference/glossary/garbage-collection.md @@ -0,0 +1,19 @@ +--- +title: Збирання сміття +id: garbage-collection +date: 2021-07-07 +full_link: /docs/concepts/architecture/garbage-collection/ +short_description: > + Загальний термін для різних механізмів, які Kubernetes використовує для очищення ресурсів кластера. + +aka: +tags: +- fundamental +- operation +--- + +Збирання сміття — це загальний термін для різних механізмів, які Kubernetes використовує для очищення ресурсів кластера. + + + +Kubernetes використовує збирання сміття для очищення ресурсів, таких як [невикористані контейнери та образи](/docs/concepts/architecture/garbage-collection/#containers-images), [збійні Podʼи](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection), [обʼєкти, які належать цільовому ресурсу](/docs/concepts/overview/working-with-objects/owners-dependents/), [завершені завдання](/docs/concepts/workloads/controllers/ttlafterfinished/) та ресурси, строк існування яких сплив або які зазнали збою. diff --git a/content/uk/docs/reference/glossary/gateway.md b/content/uk/docs/reference/glossary/gateway.md new file mode 100644 index 0000000000000..53f24ba07ac9d --- /dev/null +++ b/content/uk/docs/reference/glossary/gateway.md @@ -0,0 +1,20 @@ +--- +title: API Шлюзу +id: gateway-api +date: 2023-10-19 +full_link: /docs/concepts/services-networking/gateway/ +short_description: > + API для створення сервісної мережі в Kubernetes. + +aka: +- Gateway API +tags: +- networking +- architecture +- extension +--- +Різновид API для створення сервісної мережі в Kubernetes. + + + +API Шлюзу надає сімейство розширюваних, орієнтованих на ролі та орієнтованих на протоколи різновидів API для моделювання сервісної мережі в Kubernetes. diff --git a/content/uk/docs/reference/glossary/group-version-resource.md b/content/uk/docs/reference/glossary/group-version-resource.md new file mode 100644 index 0000000000000..a9b74d38b246a --- /dev/null +++ b/content/uk/docs/reference/glossary/group-version-resource.md @@ -0,0 +1,18 @@ +--- +title: Групова Версія Ресурсу +id: gvr +date: 2023-07-24 +short_description: > + API-група, версія API та імʼя обʼєкта Kubernetes API. + +aka: +- GVR +- Group Version Resource +tags: +- architecture +--- +Спосіб представлення унікального ресурсу API Kubernetes. + + + +Групова Версія Ресурсу (GVR) вказує API-групу, версію API та ресурс (імʼя для виду обʼєкта, як воно вказане в URI), повʼязана з доступом до певного ідентифікатора обʼєкта в Kubernetes. GVR дозволяють вам визначати та відрізняти різні обʼєкти Kubernetes та вказувати спосіб доступу до обʼєктів, який є стабільним навіть при зміні API. diff --git a/content/uk/docs/reference/glossary/helm-chart.md b/content/uk/docs/reference/glossary/helm-chart.md new file mode 100644 index 0000000000000..447988fb151df --- /dev/null +++ b/content/uk/docs/reference/glossary/helm-chart.md @@ -0,0 +1,17 @@ +--- +title: Helm Chart +id: helm-chart +date: 2018-04-12 +full_link: https://helm.sh/docs/topics/charts/ +short_description: > + Набір попередньо налаштованих ресурсів Kubernetes, якими можна керувати за допомогою Helm. + +aka: +tags: +- tool +--- +Набір попередньо налаштованих ресурсів Kubernetes, якими можна керувати за допомогою Helm. + + + +Чарти надають відтворюваний спосіб створення та обміну застосунками Kubernetes. Один чарт може бути використаний для розгортання чогось простого, наприклад, контейнера Memcached, або щось складного, наприклад, повного стека вебзастосунків з серверами HTTP, базами даних, кешем та іншими складовими. diff --git a/content/uk/docs/reference/glossary/horizontal-pod-autoscaler.md b/content/uk/docs/reference/glossary/horizontal-pod-autoscaler.md new file mode 100644 index 0000000000000..e720295dc9355 --- /dev/null +++ b/content/uk/docs/reference/glossary/horizontal-pod-autoscaler.md @@ -0,0 +1,19 @@ +--- +title: Горизонтальне автомасштабування Podʼа +id: horizontal-pod-autoscaler +date: 2018-04-12 +full_link: /docs/tasks/run-application/horizontal-pod-autoscale/ +short_description: > + Ресурс API, який автоматично масштабує кількість реплік {{< glossary_tooltip term_id="pod" text="Podʼу" >}} на основі вказаних параметрів використання ЦП або власних метрик. + +aka: +- HPA +- Horizontal Pod Autoscaler +tags: +- operation +--- +Ресурс API, який автоматично масштабує кількість реплік {{< glossary_tooltip term_id="pod" text="Podʼу" >}} на основі вказаних параметрів використання ЦП або власних метрик. + + + +Горизонтальне автомасштабування Podʼа (HPA) зазвичай використовується з {{< glossary_tooltip text="ReplicationControllers" term_id="replication-controller" >}}, {{< glossary_tooltip text="Deployments" term_id="deployment" >}} або {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}. Його неможливо застосувати до обʼєктів, які не можна масштабувати, наприклад, {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}. diff --git a/content/uk/docs/reference/glossary/host-aliases.md b/content/uk/docs/reference/glossary/host-aliases.md new file mode 100644 index 0000000000000..de7f258bff3c2 --- /dev/null +++ b/content/uk/docs/reference/glossary/host-aliases.md @@ -0,0 +1,17 @@ +--- +title: HostAliases +id: HostAliases +date: 2019-01-31 +full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core +short_description: > + HostAliases — це зіставлення між IP-адресою та імʼям хосту, яке додається у файл hosts {{< glossary_tooltip text="Podʼа" term_id="pod" >}}. + +aka: +tags: +- operation +--- +HostAliases — це зіставлення між IP-адресою та імʼям хосту, яке додається у файл hosts {{< glossary_tooltip text="Podʼа" term_id="pod" >}}. + + + +[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) — це опціональний список імен хостів та IP-адрес, які будуть вставлені в файл hosts {{< glossary_tooltip text="Podʼу" term_id="pod" >}}, якщо вказано. Це є дійсним лише для Podʼів non-hostNetwork. diff --git a/content/uk/docs/reference/glossary/image.md b/content/uk/docs/reference/glossary/image.md new file mode 100644 index 0000000000000..845489c78a563 --- /dev/null +++ b/content/uk/docs/reference/glossary/image.md @@ -0,0 +1,18 @@ +--- +title: Образ +id: image +date: 2018-04-12 +full_link: +short_description: > + Збережений екземпляр {{< glossary_tooltip term_id="container" >}}, що містить набір програмного забезпечення, необхідного для запуску додатка. + +aka: +- Image +tags: +- fundamental +--- +Збережений екземпляр {{< glossary_tooltip term_id="container" text="контейнера" >}}, що містить набір програмного забезпечення, необхідного для запуску застосунку. + + + +Спосіб упаковування програмного забезпечення, який дозволяє йому бути збереженим у реєстрі контейнерів, перенесеним на локальну систему та запущеним як застосунок. Образ містить метадані, які можуть вказувати, який виконавчий файл запускати, хто його зібрав та іншу інформацію. diff --git a/content/uk/docs/reference/glossary/index.md b/content/uk/docs/reference/glossary/index.md index fd57553ef82cd..2fdb28aa45ba2 100644 --- a/content/uk/docs/reference/glossary/index.md +++ b/content/uk/docs/reference/glossary/index.md @@ -1,8 +1,7 @@ --- approvers: -- maxymvlasov -- anastyakulyk -# title: Standardized Glossary +- chenopis +- abiogenesis-now title: Глосарій layout: glossary noedit: true @@ -11,7 +10,5 @@ weight: 5 card: name: reference weight: 10 -# title: Glossary title: Глосарій --- - diff --git a/content/uk/docs/reference/glossary/ingress.md b/content/uk/docs/reference/glossary/ingress.md new file mode 100644 index 0000000000000..97e31f9996973 --- /dev/null +++ b/content/uk/docs/reference/glossary/ingress.md @@ -0,0 +1,20 @@ +--- +title: Ingress +id: ingress +date: 2018-04-12 +full_link: /docs/concepts/services-networking/ingress/ +short_description: > + Обʼєкт API, який управляє зовнішнім доступом до служб в кластері, зазвичай HTTP. + +aka: +- Вхід +tags: +- networking +- architecture +- extension +--- +Обʼєкт API, який управляє зовнішнім доступом до служб в кластері, зазвичай HTTP. + + + +Ingress може надавати балансування навантаження, розшифровування SSL-трафіку та віртуальний хостинг на основі імен. diff --git a/content/uk/docs/reference/glossary/init-container.md b/content/uk/docs/reference/glossary/init-container.md new file mode 100644 index 0000000000000..f3206f6b7d40a --- /dev/null +++ b/content/uk/docs/reference/glossary/init-container.md @@ -0,0 +1,18 @@ +--- +title: Контейнер ініціалізації +id: init-container +date: 2018-04-12 +full_link: +short_description: > + Один чи кілька контейнерів ініціалізації, які повинні повністю виконати та завершити дію, перед тим як будь-які контейнери застосунків почнуть виконуватися. + +aka: +- Init Container +tags: +- fundamental +--- +Один чи кілька контейнерів ініціалізації, які повинні повністю виконати та завершити дію, перед тим як будь-які контейнери застосунків почнуть виконуватися + + + +Контейнери ініціалізації (init) схожі на звичайні контейнери застосунків, з однією відмінністю: контейнери ініціалізації повинні завершити виконання, перед тим як будь-які контейнери застосунків почнуть виконуватись. Контейнери ініціалізації виконуються послідовно: кожен контейнер ініціалізації повинен закінчити виконання, перед тим як почнеться виконання наступного контейнера ініціалізації. diff --git a/content/uk/docs/reference/glossary/istio.md b/content/uk/docs/reference/glossary/istio.md new file mode 100644 index 0000000000000..e6afac8d33723 --- /dev/null +++ b/content/uk/docs/reference/glossary/istio.md @@ -0,0 +1,19 @@ +--- +title: Istio +id: istio +date: 2018-04-12 +full_link: https://istio.io/latest/about/service-mesh/#what-is-istio +short_description: > + Відкрита платформа (призначення не тільки для Kubernetes), яка забезпечує уніфікований спосіб інтеграції мікросервісів, управління потоком трафіку, виконання політик та агрегацію телеметричних даних. + +aka: +tags: +- networking +- architecture +- extension +--- +Відкрита платформа (призначення не тільки для Kubernetes), яка забезпечує уніфікований спосіб інтеграції мікросервісів, управління потоком трафіку, виконання політик та агрегацію телеметричних даних. + + + +Додавання Istio не вимагає зміни коду застосунку. Istio є шаром інфраструктури між Service та мережею, який, спільно з розгортанням служб, часто називається сервісною сіткою (service mesh). панель управління Istio абстрагується від базової платформи управління кластером, якою може бути Kubernetes, Mesosphere і т.д. diff --git a/content/uk/docs/reference/glossary/job.md b/content/uk/docs/reference/glossary/job.md new file mode 100644 index 0000000000000..bf1733b0ddbb5 --- /dev/null +++ b/content/uk/docs/reference/glossary/job.md @@ -0,0 +1,19 @@ +--- +title: Job +id: job +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/job/ +short_description: > + Скінченне або пакетне завдання, яке виконується до завершення. + +aka: +tags: +- fundamental +- core-object +- workload +--- +Скінченне або пакетне завдання, яке виконується до завершення. + + + +Створює один чи кілька {{< glossary_tooltip term_id="pod" text="Podʼів">}} і забезпечує, що зазначена кількість з них успішно завершиться. В міру успішного завершення Podʼів, Job відстежує успішні завершення їх роботи. diff --git a/content/uk/docs/reference/glossary/jwt.md b/content/uk/docs/reference/glossary/jwt.md new file mode 100644 index 0000000000000..04d3cc1165e4f --- /dev/null +++ b/content/uk/docs/reference/glossary/jwt.md @@ -0,0 +1,18 @@ +--- +title: JSON Web Token (JWT) +id: jwt +date: 2023-01-17 +full_link: https://www.rfc-editor.org/rfc/rfc7519 +short_description: > + Засіб представлення вимог для передачі між двома сторонами. + +aka: +tags: +- security +- architecture +--- +Засіб представлення вимог для передачі між двома сторонами. + + + +JWT може бути підписаний та зашифрований цифровим підписом. Kubernetes використовує JWT як токени автентифікації для перевірки сутностей, які хочуть виконувати дії в кластері. diff --git a/content/uk/docs/reference/glossary/kops.md b/content/uk/docs/reference/glossary/kops.md new file mode 100644 index 0000000000000..d12ef767bb72d --- /dev/null +++ b/content/uk/docs/reference/glossary/kops.md @@ -0,0 +1,30 @@ +--- +title: kOps (Kubernetes Operations) +id: kops +date: 2018-04-12 +full_link: /docs/setup/production-environment/kops/ +short_description: > + `kOps` не тільки допомагає створювати, оновлювати та підтримувати кластери Kubernetes промислового рівня з високою доступністю, але й надає необхідну хмарну інфраструктуру. + +aka: +tags: +- tool +- operation +--- + +`kOps` не тільки допомагає створювати, оновлювати та підтримувати кластери Kubernetes промислового рівня з високою доступністю, але й надає необхідну хмарну інфраструктуру. + + + +{{< note >}} +На цей час офіційно підтримуються AWS (Amazon Web Services), DigitalOcean, GCE та OpenStack з підтримкою бета-версій, Azure — альфа-версій. +{{< /note >}} + +`kOps` — це автоматизована система управління: + +* Повністю автоматизована установка +* Використовує DNS для ідентифікації кластерів +* Самовідновлення: все працює в групах автоматичного масштабування +* Підтримка різних операційних систем (Amazon Linux, Debian, Flatcar, RHEL, Rocky та Ubuntu) +* Підтримка високої доступності +* Може безпосередньо надавати інфраструктуру або генерувати маніфести terraform diff --git a/content/uk/docs/reference/glossary/kube-apiserver.md b/content/uk/docs/reference/glossary/kube-apiserver.md index 82e3caa0bae63..8259d86cd38f8 100644 --- a/content/uk/docs/reference/glossary/kube-apiserver.md +++ b/content/uk/docs/reference/glossary/kube-apiserver.md @@ -1,13 +1,10 @@ --- -# title: API server -title: API-сервер +title: API server id: kube-apiserver date: 2018-04-12 -full_link: /docs/reference/generated/kube-apiserver/ -# short_description: > -# Control plane component that serves the Kubernetes API. +full_link: /docs/concepts/overview/components/#kube-apiserver short_description: > - Компонент площини управління, що надає доступ до API Kubernetes. + Компоент панелі управління, що обслуговує API Kubernetes. aka: - kube-apiserver @@ -15,15 +12,8 @@ tags: - architecture - fundamental --- - -API-сервер є компонентом {{< glossary_tooltip text="площини управління" term_id="control-plane" >}} Kubernetes, через який можна отримати доступ до API Kubernetes. API-сервер є фронтендом площини управління Kubernetes. +Сервер API є компонентом {{< glossary_tooltip text="панелі управління" term_id="control-plane" >}} Kubernetes, який надає доступ до API Kubernetes. Сервер API є фронтендом для панелі управління Kubernetes. - - - -Основною реалізацією Kubernetes API-сервера є [kube-apiserver](/docs/reference/generated/kube-apiserver/). kube-apiserver підтримує горизонтальне масштабування, тобто масштабується за рахунок збільшення кількості інстансів. kube-apiserver можна запустити на декількох інстансах, збалансувавши між ними трафік. +Основна реалізація сервера API Kubernetes — [kube-apiserver](/docs/reference/generated/kube-apiserver/). kube-apiserver спроєктований для горизонтального масштабування, тобто масштабується за допомогою розгортання додаткових екземплярів. Ви можете запустити кілька екземплярів kube-apiserver та балансувати трафік між ними. diff --git a/content/uk/docs/reference/glossary/kube-controller-manager.md b/content/uk/docs/reference/glossary/kube-controller-manager.md index edd56dcc90ff6..954898009d898 100644 --- a/content/uk/docs/reference/glossary/kube-controller-manager.md +++ b/content/uk/docs/reference/glossary/kube-controller-manager.md @@ -3,20 +3,16 @@ 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: > -# Control Plane component that runs controller processes. short_description: > - Компонент площини управління, який запускає процеси контролера. + Компонент панелі управління, який запускає процеси контролера. aka: tags: - architecture - fundamental --- - -Компонент площини управління, який запускає процеси {{< glossary_tooltip text="контролера" term_id="controller" >}}. +Компонент панелі управління, який запускає процеси {{< glossary_tooltip text="контролера" term_id="controller" >}}. - За логікою, кожен {{< glossary_tooltip text="контролер" term_id="controller" >}} є окремим процесом. Однак для спрощення їх збирають в один бінарний файл і запускають як єдиний процес. diff --git a/content/uk/docs/reference/glossary/kube-proxy.md b/content/uk/docs/reference/glossary/kube-proxy.md index a6db7e07debe9..9642765b5054b 100644 --- a/content/uk/docs/reference/glossary/kube-proxy.md +++ b/content/uk/docs/reference/glossary/kube-proxy.md @@ -3,31 +3,18 @@ title: kube-proxy id: kube-proxy date: 2018-04-12 full_link: /docs/reference/command-line-tools-reference/kube-proxy/ -# short_description: > -# `kube-proxy` is a network proxy that runs on each node in the cluster. short_description: > - `kube-proxy` - це мережеве проксі, що запущене на кожному вузлі кластера. + `kube-proxy` — це мережевий проксі, що запущений на кожному вузлі кластера. aka: tags: - fundamental - networking --- - -[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) є мережевим проксі, що запущене на кожному вузлі кластера і реалізує частину концепції Kubernetes {{< glossary_tooltip term_id="service" text="Service">}}. +kube-proxy є мережевим проксі, що запущений на кожному вузлі кластера і реалізує частину концепції Kubernetes {{< glossary_tooltip term_id="service" text="Service">}}. - -kube-proxy відповідає за мережеві правила на вузлах. Ці правила обумовлюють підключення по мережі до ваших Pod'ів всередині чи поза межами кластера. +[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) забезпечує підтримання мережевих правил на вузлах. Ці правила обумовлюють підключення мережею до ваших Podʼів всередині чи поза межами кластера. - -kube-proxy використовує шар фільтрації пакетів операційної системи, за наявності такого. В іншому випадку kube-proxy скеровує трафік самостійно. +kube-proxy використовує шар фільтрації пакетів операційної системи, за його наявності. В іншому випадку kube-proxy скеровує трафік самостійно. diff --git a/content/uk/docs/reference/glossary/kube-scheduler.md b/content/uk/docs/reference/glossary/kube-scheduler.md index 0864f8570e93c..8c695dc786b40 100644 --- a/content/uk/docs/reference/glossary/kube-scheduler.md +++ b/content/uk/docs/reference/glossary/kube-scheduler.md @@ -3,20 +3,15 @@ title: kube-scheduler id: kube-scheduler date: 2018-04-12 full_link: /docs/reference/generated/kube-scheduler/ -# short_description: > -# Control Plane component that watches for newly created pods with no assigned node, and selects a node for them to run on. short_description: > - Компонент площини управління, що відстежує створені Pod'и, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть. + Компонент панелі управління, що відстежує створені Podʼи, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть. aka: tags: - architecture --- - -Компонент площини управління, що відстежує створені Pod'и, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть. +Компонент панелі управління, що відстежує створені {{< glossary_tooltip term_id="pod" text="Podʼи" >}}, які ще не розподілені по {{< glossary_tooltip term_id="node" text="вузлах">}}, і обирає вузол, на якому вони працюватимуть. - -При виборі вузла враховуються наступні фактори: індивідуальна і колективна потреба у ресурсах, обмеження за апаратним/програмним забезпеченням і політиками, характеристики affinity і anti-affinity, локальність даних, сумісність робочих навантажень і граничні терміни виконання. +При виборі вузла враховуються наступні фактори: індивідуальна і колективна потреба у ресурсах, обмеження за апаратним/програмним забезпеченням і політиками, характеристики affinity та anti-affinity, локальність даних, сумісність робочих навантажень і граничні терміни виконання. diff --git a/content/uk/docs/reference/glossary/kubeadm.md b/content/uk/docs/reference/glossary/kubeadm.md new file mode 100644 index 0000000000000..77e43221f5cdb --- /dev/null +++ b/content/uk/docs/reference/glossary/kubeadm.md @@ -0,0 +1,18 @@ +--- +title: Kubeadm +id: kubeadm +date: 2018-04-12 +full_link: /docs/reference/setup-tools/kubeadm/ +short_description: > + Інструмент для швидкого встановлення Kubernetes та налаштування захищеного кластера. + +aka: +tags: +- tool +- operation +--- +Інструмент для швидкого встановлення Kubernetes та налаштування захищеного кластера. + + + +Ви можете використовувати kubeadm для встановлення як панелі управління, так і компонентів {{< glossary_tooltip text="робочих вузлів" term_id="node" >}}. diff --git a/content/uk/docs/reference/glossary/kubectl.md b/content/uk/docs/reference/glossary/kubectl.md new file mode 100644 index 0000000000000..61a58b5578ae6 --- /dev/null +++ b/content/uk/docs/reference/glossary/kubectl.md @@ -0,0 +1,20 @@ +--- +title: Kubectl +id: kubectl +date: 2018-04-12 +full_link: /docs/reference/kubectl/ +short_description: > + Інструмент командного рядка для взаємодії із кластером Kubernetes. + +aka: +- kubectl +tags: +- tool +- fundamental +--- +Інструмент командного рядка для взаємодії із кластером Kubernetes, +{{< glossary_tooltip text="панеллю управління" term_id="control-plane" >}}, використовуючи API Kubernetes. + + + +Ви можете використовувати `kubectl` для створення, перегляду, оновлення та видалення обʼєктів Kubernetes. diff --git a/content/uk/docs/reference/glossary/kubelet.md b/content/uk/docs/reference/glossary/kubelet.md index d46d18610c8b8..6d15892a9404a 100644 --- a/content/uk/docs/reference/glossary/kubelet.md +++ b/content/uk/docs/reference/glossary/kubelet.md @@ -3,21 +3,16 @@ title: Kubelet id: kubelet date: 2018-04-12 full_link: /docs/reference/generated/kubelet -# short_description: > -# An agent that runs on each node in the cluster. It makes sure that containers are running in a pod. short_description: > - Агент, що запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів у Pod'ах. + Агент, запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів у Podʼах. aka: tags: - fundamental - core-object --- - -Агент, що запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів у Pod'ах. +Агент, запущений на кожному {{< glossary_tooltip text="вузлі" term_id="node" >}} кластера. Забезпечує запуск і роботу контейнерів в Podʼах. - -kubelet використовує специфікації PodSpecs, які надаються за допомогою різних механізмів, і забезпечує працездатність і справність усіх контейнерів, що описані у PodSpecs. kubelet керує лише тими контейнерами, що були створені Kubernetes. +[kubelet](/docs/reference/command-line-tools-reference/kubelet/) використовує специфікації PodSpecs, які надаються за допомогою різних механізмів, і забезпечує працездатність і справність усіх контейнерів, що описані у PodSpecs. kubelet керує лише тими контейнерами, що були створені Kubernetes. diff --git a/content/uk/docs/reference/glossary/kubernetes-api.md b/content/uk/docs/reference/glossary/kubernetes-api.md new file mode 100644 index 0000000000000..5fce0d5f0f2d2 --- /dev/null +++ b/content/uk/docs/reference/glossary/kubernetes-api.md @@ -0,0 +1,18 @@ +--- +title: API Kubernetes +id: kubernetes-api +date: 2018-04-12 +full_link: /docs/concepts/overview/kubernetes-api/ +short_description: > + Застосунок, який обслуговує функціонал Kubernetes через RESTful інтерфейс та зберігає стан кластера. + +aka: +tags: +- fundamental +- architecture +--- +Застосунок, який обслуговує функціонал Kubernetes через RESTful інтерфейс та зберігає стан кластера. + + + +Ресурси Kubernetes та "записи про наміри" зберігаються як обʼєкти API та модифікуються за допомогою RESTful викликів до API. API дозволяє керувати конфігурацією декларативним способом. Користувачі можуть взаємодіяти з API Kubernetes безпосередньо або за допомогою інструментів, таких як `kubectl`. Ядро API Kubernetes є гнучким та може бути розширено для підтримки власних ресурсів користувачів. diff --git a/content/uk/docs/reference/glossary/label.md b/content/uk/docs/reference/glossary/label.md new file mode 100644 index 0000000000000..7a1bb9f1d5788 --- /dev/null +++ b/content/uk/docs/reference/glossary/label.md @@ -0,0 +1,17 @@ +--- +title: Label +id: label +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/labels +short_description: > + Позначає обʼєкти атрибутами ідентифікації, які мають значення і є важливими для користувачів. + +aka: +tags: +- fundamental +--- +Позначає об'єкти атрибутами ідентифікації, які мають значення і є важливими для користувачів. + + + +Мітки — це пари ключ/значення, які приєднуються до обʼєктів, таких як {{< glossary_tooltip text="Pods" term_id="pod" >}}. Вони використовуються для організації та вибору підмножини обʼєктів. diff --git a/content/uk/docs/reference/glossary/limitrange.md b/content/uk/docs/reference/glossary/limitrange.md new file mode 100644 index 0000000000000..622bcd83ad77b --- /dev/null +++ b/content/uk/docs/reference/glossary/limitrange.md @@ -0,0 +1,21 @@ +--- +title: LimitRange +id: limitrange +date: 2019-04-15 +full_link: /docs/concepts/policy/limit-range/ +short_description: > + Впроваджує ліміти для обмеження обсягу споживання ресурсів для кожного контейнера чи Podʼу в просторі імен. + +aka: +tags: +- core-object +- fundamental +- architecture +related: + - pod + - container +--- +Впроваджує ліміти для обмеження обсягу споживання ресурсів для кожного {{< glossary_tooltip text="контейнера" term_id="container" >}} чи {{< glossary_tooltip text="поду" term_id="pod" >}} в просторі імен. + + +LimitRange обмежує кількість обʼєктів, які можна створити за типом, а також обсяг обчислювальних ресурсів, які можуть бути затребувані/спожиті окремими {{< glossary_tooltip text="контейнерами" term_id="container" >}} чи {{< glossary_tooltip text="Podʼами" term_id="pod" >}} в просторі імен. diff --git a/content/uk/docs/reference/glossary/logging.md b/content/uk/docs/reference/glossary/logging.md new file mode 100644 index 0000000000000..8e65a6c3fc6e7 --- /dev/null +++ b/content/uk/docs/reference/glossary/logging.md @@ -0,0 +1,18 @@ +--- +title: Logging +id: logging +date: 2019-04-04 +full_link: /docs/concepts/cluster-administration/logging/ +short_description: > + Логи — це перелік подій, які реєструються кластером або застосунком. + +aka: +tags: +- architecture +- fundamental +--- +Логи — це перелік подій, які реєструються {{< glossary_tooltip text="кластером" term_id="cluster" >}} або застосунком. + + + +Логи застосунків та системи можуть допомогти вам зрозуміти, що відбувається всередині вашого кластера. Ці логи особливо корисні для виправлення проблем та моніторингу активності кластера. diff --git a/content/uk/docs/reference/glossary/managed-service.md b/content/uk/docs/reference/glossary/managed-service.md new file mode 100644 index 0000000000000..adaa7d01b8fcd --- /dev/null +++ b/content/uk/docs/reference/glossary/managed-service.md @@ -0,0 +1,17 @@ +--- +title: Managed Service +id: managed-service +date: 2018-04-12 +full_link: +short_description: > + Програмне забезпечення, що підтримується стороннім постачальником. + +aka: +tags: +- extension +--- +Програмне забезпечення, що підтримується стороннім постачальником. + + + +Деякі приклади Managed Services: AWS EC2, Azure SQL Database та GCP Pub/Sub, але це можуть бути будь-які програмне забезпечення, що може бути використане застосунком. diff --git a/content/uk/docs/reference/glossary/manifest.md b/content/uk/docs/reference/glossary/manifest.md new file mode 100644 index 0000000000000..d74cb87637607 --- /dev/null +++ b/content/uk/docs/reference/glossary/manifest.md @@ -0,0 +1,15 @@ +--- +title: Манфіест +id: manifest +date: 2019-06-28 +short_description: > + Серіалізована специфікація одного чи кількох обʼєктів API Kubernetes. + +aka: +tags: +- fundamental +--- +Специфікація обʼєкта API Kubernetes у форматі JSON або YAML. + + +Маніфест вказує бажаний стан обʼєкта, який Kubernetes буде підтримувати при застосуванні маніфесту. Кожен конфігураційний файл може містити кілька маніфестів. diff --git a/content/uk/docs/reference/glossary/master.md b/content/uk/docs/reference/glossary/master.md new file mode 100644 index 0000000000000..cf54f23e26d02 --- /dev/null +++ b/content/uk/docs/reference/glossary/master.md @@ -0,0 +1,16 @@ +--- +title: Master +id: master +date: 2020-04-16 +short_description: > + Застарілий термін, використовується як синонім для вузлів, на яких працює панель управління. + +aka: +tags: +- fundamental +--- +Застарілий термін, використовується як синонім для {{< glossary_tooltip text="вузлів" term_id="node" >}}, на яких розміщено {{< glossary_tooltip text="панель управління" term_id="control-plane" >}}. + + + +Цей термін все ще використовується деякими інструментами для надання послуг, такими як {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}}, та сервісами, що надаються постачальниками послуг, для {{< glossary_tooltip text="позначення" term_id="label" >}} {{< glossary_tooltip text="вузлів" term_id="node" >}} за допомогою `kubernetes.io/role` та контролю розташування {{< glossary_tooltip text="панелі управління" term_id="control-plane" >}} {{< glossary_tooltip text="Podʼів" term_id="pod" >}}. diff --git a/content/uk/docs/reference/glossary/member.md b/content/uk/docs/reference/glossary/member.md new file mode 100644 index 0000000000000..cd9abb7942471 --- /dev/null +++ b/content/uk/docs/reference/glossary/member.md @@ -0,0 +1,16 @@ +--- +title: Член +id: member +date: 2018-04-12 +short_description: > + Постійний активний учасник чи учасниця спільноти Kubernetes. + +aka: +- Member +tags: +- community +--- +Постійний активний {{< glossary_tooltip text="учасник чи учасниця" term_id="contributor" >}} спільноті Kubernetes. + + +Учасники можуть мати призначені до них тікети та запити на втягування (pull request) та брати участь у {{< glossary_tooltip text="special interest groups (SIGs)" term_id="sig" >}} (командах GitHub). Для на втягування від учасників автоматично застосовуються тести перед злиттям їх змін. Очікується, що учасник залишатиметься активним учасником у спільноті. diff --git a/content/uk/docs/reference/glossary/minikube.md b/content/uk/docs/reference/glossary/minikube.md new file mode 100644 index 0000000000000..131334ca13aac --- /dev/null +++ b/content/uk/docs/reference/glossary/minikube.md @@ -0,0 +1,18 @@ +--- +title: Minikube +id: minikube +date: 2018-04-12 +full_link: /docs/setup/learning-environment/minikube/ +short_description: > + Інструмент для локального запуску Kubernetes. + +aka: +tags: +- fundamental +- tool +--- +Інструмент для локального запуску Kubernetes. + + + +Minikube запускає кластер з одного вузла всередині віртуальної машини на вашому компʼютері. Ви можете використовувати Minikube для того, щоб [ознайомитись з Kubernetes у навчальному середовищі](/docs/setup/learning-environment/). diff --git a/content/uk/docs/reference/glossary/mirror-pod.md b/content/uk/docs/reference/glossary/mirror-pod.md new file mode 100644 index 0000000000000..d312a54b2b8e3 --- /dev/null +++ b/content/uk/docs/reference/glossary/mirror-pod.md @@ -0,0 +1,19 @@ +--- +title: Дзеркальний Pod +id: mirror-pod +date: 2019-08-06 +short_description: > + Обʼєкт в API-сервері, який відстежує статичний Pod на kubelet. + +aka: +- Mirror Pod +tags: +- fundamental +--- +{{< glossary_tooltip text="Pod" term_id="pod" >}}, який {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} використовує для представлення {{< glossary_tooltip text="статичного Podʼа" term_id="static-pod" >}}. + + + +Коли kubelet знаходить статичний Pod у своїй конфігурації, він автоматично намагається створити обʼєкт Pod на сервері API Kubernetes для нього. Це означає, що Pod буде видно на сервері API, але ним не можна керувати звідти. + +(Наприклад, видалення дзеркального Podʼу не зупинить демона kubelet від його запуску). diff --git a/content/uk/docs/reference/glossary/mixed-version-proxy.md b/content/uk/docs/reference/glossary/mixed-version-proxy.md new file mode 100644 index 0000000000000..ee2712251b33c --- /dev/null +++ b/content/uk/docs/reference/glossary/mixed-version-proxy.md @@ -0,0 +1,18 @@ +--- +title: Mixed Version Proxy (MVP) +id: mvp +date: 2023-07-24 +short_description: > + Функціонал, який дозволяє kube-apiserver перенаправити запит на ресурс до іншого API-сервера. +aka: +- MVP +tags: +- architecture +--- +Функціонал, який дозволяє kube-apiserver перенаправити запит на ресурс до іншого API-сервера. + + + +Коли у кластері працюють різні версії Kubernetes на різних API-серверах, ця функція дозволяє правильно обслуговувати запити до ресурсів за допомогою відповідного API-сервера. + +MVP стандартно вимкнено і може бути активовано, увімкненням [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) з іменем `UnknownVersionInteroperabilityProxy` при запуску {{< glossary_tooltip text="API-сервера" term_id="kube-apiserver" >}}. diff --git a/content/uk/docs/reference/glossary/name.md b/content/uk/docs/reference/glossary/name.md new file mode 100644 index 0000000000000..e143cc073c9f6 --- /dev/null +++ b/content/uk/docs/reference/glossary/name.md @@ -0,0 +1,16 @@ +--- +title: Name +id: name +date: 2018-04-12 +short_description: > + Наданий клієнтом рядок, який посилається на обʼєкт в URL ресурсу, наприклад `/api/v1/pods/some-name`. + +aka: +tags: +- fundamental +--- +Наданий клієнтом рядок, який посилається на обʼєкт в URL ресурсу, наприклад `/api/v1/pods/some-name`. + + + +Тільки один обʼєкт вказаного виду (kind) може мати вказану назву одночасно. Проте, якщо ви видаляєте обʼєкт, ви можете створити новий обʼєкт з такою ж назвою. diff --git a/content/uk/docs/reference/glossary/namespace.md b/content/uk/docs/reference/glossary/namespace.md new file mode 100644 index 0000000000000..e40bb79480de5 --- /dev/null +++ b/content/uk/docs/reference/glossary/namespace.md @@ -0,0 +1,17 @@ +--- +title: Namespace +id: namespace +date: 2018-04-12 +short_description: > + Абстракція, що використовується в Kubernetes для ізоляції груп ресурсів в межах одного кластера. + +aka: +- Простір імен +tags: +- fundamental +--- +Абстракція, що використовується в Kubernetes для ізоляції груп ресурсів в межах одного кластера. + + + +Простори імен використовуються для організації обʼєктів в кластері та надають можливість поділу ресурсів кластера. Імена ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Простори імен застосовуються лише до обʼєктів, які належать до простору імен _(наприклад, Deployments, Services і т.д.)_, і не застосовуються до обʼєктів, які є загальними для кластера _(наприклад, StorageClass, Nodes, PersistentVolumes, і т.д.)_. diff --git a/content/uk/docs/reference/glossary/network-policy.md b/content/uk/docs/reference/glossary/network-policy.md new file mode 100644 index 0000000000000..7b70d73fca863 --- /dev/null +++ b/content/uk/docs/reference/glossary/network-policy.md @@ -0,0 +1,19 @@ +--- +title: Network Policy +id: network-policy +date: 2018-04-12 +short_description: > + Специфікація того, як дозволяється взаємодія групам Podʼів між собою та із іншими мережевими точками. + +aka: +- Мережева політика +tags: +- networking +- architecture +- extension +--- +Специфікація того, як дозволяється взаємодія групам Podʼів між собою та із іншими мережевими точками. + + + +Мережеві політики дозволяють вам декларативно налаштовувати, які Podʼи мають право підключатися одне до одного, які простори імен мають право взаємодіяти та більш конкретно, до яких портів слід застосовувати кожну політику. Ресурси `NetworkPolicy` використовують мітки для вибору Podʼів та визначення правил, які вказують, який трафік дозволяється обраним Podʼам. Мережеві політики реалізовані за допомогою підтримуваного мережевого втулка, який надає постачальник мережі. Зверніть увагу, що створення мережевого ресурсу без контролера для його виконання не матиме ефекту. diff --git a/content/uk/docs/reference/glossary/node-pressure-eviction.md b/content/uk/docs/reference/glossary/node-pressure-eviction.md new file mode 100644 index 0000000000000..93d2d77317a21 --- /dev/null +++ b/content/uk/docs/reference/glossary/node-pressure-eviction.md @@ -0,0 +1,20 @@ +--- +title: Вивільнення ресурсів через тиск на вузол +id: node-pressure-eviction +date: 2021-05-13 +short_description: > + Вивільнення ресурсів через тиск на вузол — це процес, при якому kubelet активно завершує роботу Podʼів для звільнення ресурсів на вузлах. + +aka: +- kubelet eviction +- Node-pressure eviction +tags: +- operation +--- +Вивільнення ресурсів через тиск на вузол — це процес, при якому {{}} активно завершує роботу Podʼів для звільнення ресурсів на вузлах. + + + +Kubelet веде моніторинг ресурсів, таких як ЦП, памʼять, місце на диску та іноді файлової системи на вузлах вашого кластера. Коли один або кілька з цих ресурсів досягають певних рівнів використання, kubelet може активно завершувати роботу одного або кількох Podʼів на вузлі для звільнення ресурсів та запобігання їх нестачі. + +Вивільнення ресурсів через тиск на вузол не є тим самим, що й [Ініційоване API вивільнення ресурсів](/docs/concepts/scheduling-eviction/api-eviction/). diff --git a/content/uk/docs/reference/glossary/node.md b/content/uk/docs/reference/glossary/node.md new file mode 100644 index 0000000000000..c4afee8840919 --- /dev/null +++ b/content/uk/docs/reference/glossary/node.md @@ -0,0 +1,19 @@ +--- +title: Вузол +id: node +date: 2018-04-12 +short_description: > + Вузол — це робоча машина в Kubernetes. + +aka: +- Node +tags: +- fundamental +--- +Вузол — це робоча машина в Kubernetes. + + + +Робочий вузол може бути віртуальною машиною або фізичною машиною, залежно від кластера. На ньому працюють локальні служби або служби, необхідні для виконання {{< glossary_tooltip text="Podʼів" term_id="pod" >}}, і ним керує панель управління. Демони на вузлі включають {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} та середовище виконання контейнерів, яке реалізує {{< glossary_tooltip text="CRI" term_id="cri" >}}, наприклад {{< glossary_tooltip term_id="docker" >}}. + +В ранніх версіях Kubernetes вузли називалися "Minions" (Міньйони). diff --git a/content/uk/docs/reference/glossary/object.md b/content/uk/docs/reference/glossary/object.md new file mode 100644 index 0000000000000..cf54a8ef19b09 --- /dev/null +++ b/content/uk/docs/reference/glossary/object.md @@ -0,0 +1,17 @@ +--- +title: Обʼєкт +id: object +date: 2020-10-12 +full_link: /docs/concepts/overview/working-with-objects/#kubernetes-objects +short_description: > + Сутність у системі Kubernetes, що представляє частину стану вашого кластеру. + +aka: +tags: +- fundamental +--- +Сутність у системі Kubernetes. Керуючись цими сутностями, API Kubernetes представляє стан вашого кластера. + + + +Обʼєкт Kubernetes зазвичай є "записом наміру" — коли ви створюєте обʼєкт, {{< glossary_tooltip text="панель управління" term_id="control-plane" >}} Kubernetes постійно працює над тим, щоб забезпечити існування представленого ним елемента. Створюючи обʼєкт, ви повідомляєте системі Kubernetes, як ви хочете, щоб ця частина робочого навантаження вашого кластера виглядала; це бажаний стан вашого кластера. diff --git a/content/uk/docs/reference/glossary/operator-pattern.md b/content/uk/docs/reference/glossary/operator-pattern.md new file mode 100644 index 0000000000000..8cc42e2060f0e --- /dev/null +++ b/content/uk/docs/reference/glossary/operator-pattern.md @@ -0,0 +1,19 @@ +--- +title: Шаблон Operator +id: operator-pattern +date: 2019-05-21 +full_link: /docs/concepts/extend-kubernetes/operator/ +short_description: > + Спеціалізований контролер, призначений для управління власним ресурсом. + +aka: +tags: +- architecture +--- +[Шаблон Operator](/docs/concepts/extend-kubernetes/operator/) — це системний дизайн, який повʼязує контролер з одним чи кількома власними ресурсами. + + + +Ви можете розширити функціонал Kubernetes, додаючи контролери до свого кластера, поза вбудованими контролерами, які поставляються разом з самим Kubernetes. + +Якщо запущений застосунок діє як контролер та має доступ до API для виконання завдань відносно власного ресурсу, що визначений в панелі управління, це приклад шаблону Operator. diff --git a/content/uk/docs/reference/glossary/persistent-volume-claim.md b/content/uk/docs/reference/glossary/persistent-volume-claim.md new file mode 100644 index 0000000000000..aef9d238fa915 --- /dev/null +++ b/content/uk/docs/reference/glossary/persistent-volume-claim.md @@ -0,0 +1,18 @@ +--- +title: Persistent Volume Claim +id: persistent-volume-claim +date: 2018-04-12 +full_link: /docs/concepts/storage/persistent-volumes/#persistentvolumeclaims +short_description: > + Запит на використання ресурсів зберігання, визначених у PersistentVolume, для їх монтування як томів в контейнері. + +aka: +tags: +- core-object +- storage +--- +Запит на використання ресурсів зберігання, визначених у {{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}}, для їх монтування як томів в {{< glossary_tooltip text="контейнері" term_id="container" >}}. + + + +Визначає ресурс зберігання, спосіб доступу до зберігання (тільки для читання, для читання та запису та/або виключний доступ) та спосіб його вилучення (збережений, перероблений або видалений). Деталі щодо самого зберігання описані в обʼєкті PersistentVolume. \ No newline at end of file diff --git a/content/uk/docs/reference/glossary/persistent-volume.md b/content/uk/docs/reference/glossary/persistent-volume.md new file mode 100644 index 0000000000000..1e36f8f333549 --- /dev/null +++ b/content/uk/docs/reference/glossary/persistent-volume.md @@ -0,0 +1,18 @@ +--- +title: Persistent Volume +id: persistent-volume +date: 2018-04-12 +full_link: /docs/concepts/storage/persistent-volumes/ +short_description: > + Обʼєкт API, який являє собою частину зберігання в кластері. Доступний як загальний, підʼєднуваний ресурс, який існує поза життєвим циклом будь-якого окремого {{< glossary_tooltip text="Podʼу" term_id="pod" >}}. + +aka: +tags: +- core-object +- storage +--- +Об'єкт API, який являє собою частину зберігання в кластері. Доступний як загальний, підʼєднуваний ресурс, який існує поза життєвим циклом будь-якого окремого {{< glossary_tooltip text="Podʼу" term_id="pod" >}}. + + + +PersistentVolumes (PVs) надають API, який абстрагує деталі того, як забезпечується зберігання від того, як воно використовується. PVs використовуються безпосередньо в сценаріях, де зберігання може бути створено заздалегідь (статичне розподілення). Для сценаріїв, які вимагають зберігання на вимогу (динамічне розподілення), замість цього використовуються PersistentVolumeClaims (PVCs). diff --git a/content/uk/docs/reference/glossary/platform-developer.md b/content/uk/docs/reference/glossary/platform-developer.md new file mode 100644 index 0000000000000..bec39e4fbcd99 --- /dev/null +++ b/content/uk/docs/reference/glossary/platform-developer.md @@ -0,0 +1,19 @@ +--- +title: Розробник платформи +id: platform-developer +date: 2018-04-12 +full_link: +short_description: > + Особа, яка налаштовує платформу Kubernetes, щоб вона відповідала потребам власного проєкту. + +aka: +tags: +- user-type +--- +Особа, яка налаштовує платформу Kubernetes, щоб вона відповідала потребам власного проєкту. + + + +Розробник платформи може, наприклад, використовувати [Власні Ресурси](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) або +[Розширювати Kubernetes API за допомогою шару агрегації](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +для додавання функціонала до свого екземпляра Kubernetes, зокрема для свого застосунку. Деякі розробники платформи також є {{< glossary_tooltip text="учасниками проєкту Kubernetes" term_id="contributor" >}} і створюють розширення, які передаються спільноті Kubernetes. Інші розробляють комерційні розширення з закритим вихідним кодом або специфічні для власного сайту. diff --git a/content/uk/docs/reference/glossary/pod-disruption-budget.md b/content/uk/docs/reference/glossary/pod-disruption-budget.md new file mode 100644 index 0000000000000..a7c92ba046c3a --- /dev/null +++ b/content/uk/docs/reference/glossary/pod-disruption-budget.md @@ -0,0 +1,24 @@ +--- +title: Обмеження переривання роботи Podʼів +id: pod-disruption-budget +full-link: /docs/concepts/workloads/pods/disruptions/ +date: 2019-02-12 +short_description: > + Обʼєкт, який обмежує кількість {{< glossary_tooltip text="Podʼів" term_id="pod" >}} реплікованого застосунку, які можуть бути вимкнені одночасно з причини добровільного переривання роботи. + +aka: + - PDB + - Pod Disruption Budget +related: + - pod + - container +tags: + - operation +--- + +[Обмеження переривання роботи Podʼів](/docs/concepts/workloads/pods/disruptions/) дозволяє власникам застосунків створювати обʼєкт для реплікованого застосунку, який гарантує, що певна кількість або відсоток Podʼів з визначеною міткою не буде добровільно вимкнена в будь-який момент часу. + + + +PDB не можуть запобігти невимушеним збоям; однак вони +зараховуються до бюджету. diff --git a/content/uk/docs/reference/glossary/pod-disruption.md b/content/uk/docs/reference/glossary/pod-disruption.md new file mode 100644 index 0000000000000..9a9427edf9af2 --- /dev/null +++ b/content/uk/docs/reference/glossary/pod-disruption.md @@ -0,0 +1,21 @@ +--- +id: pod-disruption +title: Переривання роботи Podʼу +full_link: /docs/concepts/workloads/pods/disruptions/ +date: 2021-05-12 +short_description: > + Процес, за якого Podʼи на вузлах припиняють роботу добровільно, або примусово. + +aka: +related: + - pod + - container +tags: + - operation +--- + +[Переривання роботи Podʼу](/docs/concepts/workloads/pods/disruptions/) — це процес, за якого Podʼи на вузлах припиняють роботу добровільно, або примусово. + + + +Добровільні переривання запускаються навмисно власниками застосунків або адміністраторами кластера. Примусові переривання є ненавмисними та можуть бути спричинені невідворотними проблемами, такими як вичерпання ресурсів вузлів, або випадковими видаленнями. diff --git a/content/uk/docs/reference/glossary/pod-lifecycle.md b/content/uk/docs/reference/glossary/pod-lifecycle.md new file mode 100644 index 0000000000000..4d8723dd48fc5 --- /dev/null +++ b/content/uk/docs/reference/glossary/pod-lifecycle.md @@ -0,0 +1,22 @@ +--- +title: Життєвий цикл Podʼа +id: pod-lifecycle +date: 2019-02-17 +full-link: /docs/concepts/workloads/pods/pod-lifecycle/ + +aka: +- Pod Lifecycle +related: + - pod + - container +tags: + - fundamental +short_description: > + Послідовність станів, через які проходить Pod протягом свого існування. + +--- + Послідовність станів, через які проходить Pod протягом свого існування. + + + +[Життєвий цикл Podа](/docs/concepts/workloads/pods/pod-lifecycle/) визначається станами або фазами Podʼа. Існує пʼять можливих фаз Podʼа: Pending, Running, Succeeded, Failed та Unknown. Високорівневий опис стану Podʼа знаходиться в полі `phase` [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core). diff --git a/content/uk/docs/reference/glossary/pod-priority.md b/content/uk/docs/reference/glossary/pod-priority.md new file mode 100644 index 0000000000000..cdeb011e4f504 --- /dev/null +++ b/content/uk/docs/reference/glossary/pod-priority.md @@ -0,0 +1,17 @@ +--- +title: Пріоритет Podʼа +id: pod-priority +date: 2019-01-31 +full_link: /docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority +short_description: > + Пріоритет Podʼа вказує на важливість Podʼа в порівнянні з іншими Podʼами. + +aka: +tags: +- operation +--- +Пріоритет Podʼа вказує на важливість {{< glossary_tooltip term_id="pod" text="Podʼа" >}} в порівнянні з іншими Podʼами. + + + +[Пріоритет Podʼа](/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) дає змогу встановлювати пріоритет планування Podʼа вищим або нижчим в порівнянні з іншими Podʼами — це важлива функція для навантаження промислових кластерів. diff --git a/content/uk/docs/reference/glossary/pod-security-policy.md b/content/uk/docs/reference/glossary/pod-security-policy.md new file mode 100644 index 0000000000000..f4dd7b9479a85 --- /dev/null +++ b/content/uk/docs/reference/glossary/pod-security-policy.md @@ -0,0 +1,21 @@ +--- +title: Політики безпеки Podʼа +id: pod-security-policy +date: 2018-04-12 +full_link: /docs/concepts/security/pod-security-policy/ +short_description: > + Дозволяєють деталізовану авторизацію створення та оновлення Podʼів. + +aka: +- Pod Security Policy +tags: +- core-object +- fundamental +--- +Дозволяє деталізовану авторизацію створення та оновлення {{< glossary_tooltip term_id="pod" text="Podʼів">}}. + + + +Ресурс на рівні кластера, який контролює аспекти безпеки, що стосуються специфікації Podʼа. Обʼєкти `PodSecurityPolicy` визначають набір умов, якими повинен відповідати Pod, щоб його можна було прийняти в систему, а також стандартні значення для повʼязаних полів. Керування політикою безпеки Podʼа реалізується як додатковий контролер допуску. + +Починаючи з Kubernetes v1.21, `PodSecurityPolicy` визнано застарілими, а з v1.25 — видалено. Як альтернативу, використовуйте [Допуски Безпеки Podʼа](/docs/concepts/security/pod-security-admission/) або сторонній втулок допуску. diff --git a/content/uk/docs/reference/glossary/pod.md b/content/uk/docs/reference/glossary/pod.md index 7ee87bb1af05a..07e6c662c3f1d 100644 --- a/content/uk/docs/reference/glossary/pod.md +++ b/content/uk/docs/reference/glossary/pod.md @@ -1,23 +1,18 @@ --- -# title: Pod title: Pod id: pod date: 2018-04-12 -full_link: /docs/concepts/workloads/pods/pod-overview/ -# short_description: > -# The smallest and simplest Kubernetes object. A Pod represents a set of running containers on your cluster. +full_link: /docs/concepts/workloads/pods/ short_description: > - Найменший і найпростіший об'єкт Kubernetes. Pod являє собою групу контейнерів, що запущені у вашому кластері. + Pod являє собою групу контейнерів, що запущені у вашому кластері. aka: tags: - core-object - fundamental --- - - Найменший і найпростіший об'єкт Kubernetes. Pod являє собою групу {{< glossary_tooltip text="контейнерів" term_id="container" >}}, що запущені у вашому кластері. +Найменший та найпростіший обʼєкт Kubernetes. Pod являє собою групу {{< glossary_tooltip text="контейнерів" term_id="container" >}}, що запущені у вашому кластері. - -Як правило, в одному Pod'і запускається один контейнер. У Pod'і також можуть бути запущені допоміжні контейнери, що забезпечують додаткову функціональність, наприклад, логування. Управління Pod'ами зазвичай здійснює {{< glossary_tooltip term_id="deployment" >}}. +Pod зазвичай налаштовується для запуску одного основного контейнера. Він також може запускати додаткові sidecar контейнери, які додають додаткові функції, наприклад журналювання. Podʼами зазвичай керує {{< glossary_tooltip term_id="deployment" >}}. diff --git a/content/uk/docs/reference/glossary/preemption.md b/content/uk/docs/reference/glossary/preemption.md new file mode 100644 index 0000000000000..bbcd94f7cfa2c --- /dev/null +++ b/content/uk/docs/reference/glossary/preemption.md @@ -0,0 +1,18 @@ +--- +title: Витіснення +id: preemption +date: 2019-01-31 +full_link: /docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption +short_description: > + Логіка пріоритетів в Kubernetes допомагає Podʼу, що очікує, знайти відповідний Вузол, витискаючи Podʼи з низьким пріоритетом, що вже існують на цьому Вузлі. + +aka: +- Preemption +tags: +- operation +--- +Логіка пріоритетів в Kubernetes допомагає {{< glossary_tooltip term_id="pod" text="Podʼу">}}, що очікує, знайти відповідний {{< glossary_tooltip term_id="node" text="Вузол" >}} витискаючи Podʼи з низьким пріоритетом, що вже існують на цьому Вузлі. + + + +Якщо Pod не можна призначити, планувальник намагається [витіснити](/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption) Podʼи з меншим пріоритетом, щоб забезпечити можливість призначення Podʼа, що перебуває в очікуванні вузла. diff --git a/content/uk/docs/reference/glossary/probe.md b/content/uk/docs/reference/glossary/probe.md new file mode 100644 index 0000000000000..ad5d99bd3f1f2 --- /dev/null +++ b/content/uk/docs/reference/glossary/probe.md @@ -0,0 +1,19 @@ +--- +title: Проба +id: probe +date: 2023-03-21 +full_link: /docs/concepts/workloads/pods/pod-lifecycle/#container-probes + +short_description: > + Періодична перевірка, яку kubelet виконує для контейнера в Podʼі. + +aka: +- Probe +tags: +- tool +--- +Періодична перевірка, яку {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} виконує для контейнера, що працює в Podʼі. Ця перевірка визначає стан та справності контейнера, і інформує про життєвий цикл контейнера. + + + +Для отримання додаткової інформації читайте [проби контейнера](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). diff --git a/content/uk/docs/reference/glossary/proxy.md b/content/uk/docs/reference/glossary/proxy.md new file mode 100644 index 0000000000000..f2b84a1c501d1 --- /dev/null +++ b/content/uk/docs/reference/glossary/proxy.md @@ -0,0 +1,21 @@ +--- +title: Проксі +id: proxy +date: 2019-09-10 +short_description: > + Застосунок, що діє посередником між клієнтами та серверами. + +aka: +- Proxy +tags: +- networking +--- +У компʼютерних науках проксі — це сервер, який діє як посередник для віддалених служб. + + + +Клієнт взаємодіє з проксі; проксі копіює дані клієнта на реальний сервер; реальний сервер відповідає проксі; проксі надсилає відповідь реального сервера клієнту. + +[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) — це мережевий проксі, який працює на кожному вузлі вашого кластера, реалізуючи частину концепції {{< glossary_tooltip term_id="service">}} в Kubernetes. + +Ви можете запускати kube-proxy як звичайний сервіс проксі на рівні користувача. Якщо ваша операційна система це підтримує, ви можете запускати kube-proxy в гібридному режимі, який досягає того самого результату, використовуючи менше системних ресурсів. diff --git a/content/uk/docs/reference/glossary/qos-class.md b/content/uk/docs/reference/glossary/qos-class.md new file mode 100644 index 0000000000000..e5bb9275eeefc --- /dev/null +++ b/content/uk/docs/reference/glossary/qos-class.md @@ -0,0 +1,22 @@ +--- +title: Клас обслуговування QoS +id: qos-class +date: 2019-04-15 +full_link: /docs/concepts/workloads/pods/pod-qos/ +short_description: > + Клас обслуговування QoS (Quality of Service Class) надає можливість Kubernetes класифікувати Podʼи в кластері в декілька класів і приймати рішення щодо їх планування та видалення. + +aka: +tags: +- core-object +- fundamental +- architecture +related: + - pod + +--- +Клас обслуговування QoS (Quality of Service Class) надає можливість Kubernetes класифікувати Podʼи в кластері в декілька класів і приймати рішення щодо їх планування та видалення. + + + +Клас QoS Podʼа встановлюється під час створення на основі його налаштувань обчислювальних ресурсів (запити та обмеження). Класи QoS використовуються для прийняття рішень щодо планування та видалення Podʼів. Kubernetes може присвоїти один із наступних класів QoS Поду: `Guaranteed`, `Burstable` або `BestEffort`. diff --git a/content/uk/docs/reference/glossary/quantity.md b/content/uk/docs/reference/glossary/quantity.md new file mode 100644 index 0000000000000..311d9b48b98b0 --- /dev/null +++ b/content/uk/docs/reference/glossary/quantity.md @@ -0,0 +1,23 @@ +--- +title: Кількість +id: quantity +date: 2018-08-07 +full_link: +short_description: > + Представлення цілих чисел малих або великих чисел за допомогою суфіксів [SI](https://en.wikipedia.org/wiki/International_System_of_Units). + +aka: +tags: +- core-object +--- +Представлення цілих чисел малих або великих чисел за допомогою суфіксів [SI](https://en.wikipedia.org/wiki/International_System_of_Units). + + + +Кількості — це представлення малих або великих чисел за допомогою компактного, запису цілих чисел із суфіксами СІ. Дробові числа використовуючи міліодиниці, тоді як великі числа можуть бути представлені кіло, мега або гіга одиницями. + +Наприклад, число `1.5` представляється як `1500m`, тоді як число `1000` можна представити як `1k`, а `1000000` як `1M`. Ви також можете вказати суфікси у [бінарному форматі](https://en.wikipedia.org/wiki/Binary_prefix); число 2048 можна записати як `2Ki`. + +Прийняті десяткові (за основою 10) одиниці — це `m` (мілі), `k` (кіло, свідомо в нижньому регістрі), `M` (мега), `G` (гіга), `T` (тера), `P` (пета), `E` (екса). + +Прийняті двійкові (за основою 2) одиниці — це `Ki` (кібі), `Mi` (мебі), `Gi` (гібі), `Ti` (тебі), `Pi` (пебі), `Ei` (ексбі). diff --git a/content/uk/docs/reference/glossary/rbac.md b/content/uk/docs/reference/glossary/rbac.md new file mode 100644 index 0000000000000..117474f3b1ed2 --- /dev/null +++ b/content/uk/docs/reference/glossary/rbac.md @@ -0,0 +1,20 @@ +--- +title: Керування доступом на основі ролей +id: rbac +date: 2018-04-12 +full_link: /docs/reference/access-authn-authz/rbac/ +short_description: > + Управління рішеннями з авторизації, яке дозволяє адміністраторам динамічно налаштовувати політики доступу через API Kubernetes. + +aka: +- RBAC +- Role-Based Access Control +tags: +- security +- fundamental +--- +Управління рішеннями з авторизації, яке дозволяє адміністраторам динамічно налаштовувати політики доступу через {{< glossary_tooltip text="API Kubernetes" term_id="kubernetes-api" >}}. + + + +RBAC використовує *ролі*, які містять правила дозволів, та *привʼязки ролей*, які надають дозволи, визначені в ролі, конкретному набору користувачів. diff --git a/content/uk/docs/reference/glossary/replica-set.md b/content/uk/docs/reference/glossary/replica-set.md new file mode 100644 index 0000000000000..1fe5d0d626598 --- /dev/null +++ b/content/uk/docs/reference/glossary/replica-set.md @@ -0,0 +1,21 @@ +--- +title: ReplicaSet +id: replica-set +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/replicaset/ +short_description: > + ReplicaSet забезпечує наявність певної кількості реплік обʼєкта Pod в поточний момент часу + +aka: +tags: +- fundamental +- core-object +- workload +--- +Обʼєкт ReplicaSet (має на меті) підтримувати набір реплік обʼєктів Pod, які завжди працюють в будь-який момент часу. + + + +Обʼєкти робочого навантаження, такі як {{< glossary_tooltip term_id="deployment" >}}, використовують ReplicaSet +для забезпечення того, що налаштована кількість {{< glossary_tooltip term_id="pod" text="Podʼів" >}} працювала +у вашому кластері на основі конфігурації цього ReplicaSet. diff --git a/content/uk/docs/reference/glossary/replica.md b/content/uk/docs/reference/glossary/replica.md new file mode 100644 index 0000000000000..6bfa3bd2f9605 --- /dev/null +++ b/content/uk/docs/reference/glossary/replica.md @@ -0,0 +1,22 @@ +--- +title: Replica +id: replica +date: 2023-06-11 +full_link: +short_description: > + Репліки — це копії обʼєктів Pod, які забезпечують доступність, масштабованість і стійкість до відмов за рахунок утримання ідентичних екземплярів. +aka: +tags: +- fundamental +- workload +--- +Копія або дублікат {{< glossary_tooltip text="Podʼу" term_id="pod" >}} або набору обʼєктів Pod. Репліки забезпечують високу доступність, масштабованість і стійкість до відмов +шляхом утримання кількох ідентичних екземплярів обʼєкта Pod. + + + +У Kubernetes репліки широко використовуються для досягнення бажаного стану застосунку та надійності роботи. Вони дозволяють масштабування робочого навантаження та його розподіл по різних вузлах кластера. + +Визначаючи кількість реплік в обʼєкті Deployment або ReplicaSet, Kubernetes переконується, що вказана кількість екземплярів працює, автоматично коригуючи кількість за необхідності. + +Управління репліками дозволяє ефективно балансувати навантаження, виконувати поетапні оновлення та забезпечує можливості самовідновлення в кластері Kubernetes. diff --git a/content/uk/docs/reference/glossary/replication-controller.md b/content/uk/docs/reference/glossary/replication-controller.md new file mode 100644 index 0000000000000..deea7ac7a4c81 --- /dev/null +++ b/content/uk/docs/reference/glossary/replication-controller.md @@ -0,0 +1,22 @@ +--- +title: ReplicationController +id: replication-controller +date: 2018-04-12 +full_link: +short_description: > + Обʼєкт API (застарілий), який керує реплікованим застосунком. + +aka: +tags: +- workload +- core-object +--- +Ресурс робочого навантаження, який керує реплікованим застосунком, забезпечуючи наявність певної кількості екземплярів обʼекта {{< glossary_tooltip text="Pod" term_id="pod" >}}. + + + +Панель управління забезпечує, що визначена кількість екземплярів Pod працює, навіть якщо деякі Pod відмовляють, якщо ви видаляєте Pod вручну або якщо помилково їх запускається забагато. + +{{< note >}} +ReplicationController є застарілим. Див. {{< glossary_tooltip text="Deployment" term_id="deployment" >}}, який є подібним. +{{< /note >}} diff --git a/content/uk/docs/reference/glossary/resource-quota.md b/content/uk/docs/reference/glossary/resource-quota.md new file mode 100644 index 0000000000000..321d6fd5d6ca5 --- /dev/null +++ b/content/uk/docs/reference/glossary/resource-quota.md @@ -0,0 +1,19 @@ +--- +title: Квоти ресурсів +id: resource-quota +date: 2018-04-12 +full_link: /docs/concepts/policy/resource-quotas/ +short_description: > + Впроваджує обмеження, які обмежують загальне споживання ресурсів для кожного простору імен. + +aka: +tags: +- fundamental +- operation +- architecture +--- +Впроваджує обмеження, які обмежують загальне споживання ресурсів для кожного {{< glossary_tooltip term_id="namespace" >}}. + + + +Обмежує кількість обʼєктів, які можна створити в просторі імен за типом, а також загальний обсяг ресурсів обчислювального характеру, які можуть бути спожиті ресурсами в проєкті. diff --git a/content/uk/docs/reference/glossary/reviewer.md b/content/uk/docs/reference/glossary/reviewer.md new file mode 100644 index 0000000000000..36c1fb72ee761 --- /dev/null +++ b/content/uk/docs/reference/glossary/reviewer.md @@ -0,0 +1,18 @@ +--- +title: Рецензент +id: reviewer +date: 2018-04-12 +full_link: +short_description: > + Особа, яка перевіряє код для визначення його якості та коректності в певній частині проєкту. + +aka: +- Reviewer +tags: +- community +--- +Особа, яка перевіряє код для визначення його якості та коректності в певній частині проєкту. + + + +Рецензенти мають знання як щодо кодової бази, так і щодо принципів інженерії програмного забезпечення. Статус рецензента обмежений певною частиною кодової бази. diff --git a/content/uk/docs/reference/glossary/secret.md b/content/uk/docs/reference/glossary/secret.md new file mode 100644 index 0000000000000..93bdbfeb8bb6e --- /dev/null +++ b/content/uk/docs/reference/glossary/secret.md @@ -0,0 +1,23 @@ +--- +title: Секрет +id: secret +date: 2018-04-12 +full_link: /docs/concepts/configuration/secret/ +short_description: > + Зберігає конфіденційну інформацію, таку як паролі, токени OAuth та ключі SSH. + +aka: +- Secret +tags: +- core-object +- security +--- +Зберігає конфіденційну інформацію, таку як паролі, токени OAuth та ключі SSH. + + + +Секрети дають вам більше контролю над тим, як використовується конфіденційна інформація і зменшують ризик випадкового її розголошення. Значення секрету кодуються як рядки base64 і +зазвичай зберігаються в незашифрованому вигляді, але можуть бути налаштовані для [шифрування в стані покою](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted). + +{{< glossary_tooltip text="Pod" term_id="pod" >}} може посилатися на Секрет різними способами, такими як монтування тома, чи як змінна середовища. Секрети призначені для конфіденційних даних, а +[ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) призначені для неконфіденційних даних. diff --git a/content/uk/docs/reference/glossary/security-context.md b/content/uk/docs/reference/glossary/security-context.md new file mode 100644 index 0000000000000..aa7d2b3d2a05a --- /dev/null +++ b/content/uk/docs/reference/glossary/security-context.md @@ -0,0 +1,20 @@ +--- +title: Контекст Безпеки +id: security-context +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/security-context/ +short_description: > + Поле `securityContext` визначає налаштування привілеїв та контролю доступу для Podʼа або контейнера. + +aka: +tags: +- security +--- +Поле `securityContext` визначає налаштування привілеїв та контролю доступу для {{< glossary_tooltip text="Podʼа" term_id="pod" >}} або +{{< glossary_tooltip text="контейнера" term_id="container" >}}. + + + +У `securityContext` можна визначити: користувача, яким виконуються процеси, групу, якою виконуються процеси, та налаштування привілеїв. Також можна налаштувати політики безпеки (наприклад: SELinux, AppArmor чи seccomp). + +Налаштування `PodSpec.securityContext` застосовується до всіх контейнерів в Podʼі. diff --git a/content/uk/docs/reference/glossary/selector.md b/content/uk/docs/reference/glossary/selector.md index 77eb861f4edb2..80122d7e8f443 100644 --- a/content/uk/docs/reference/glossary/selector.md +++ b/content/uk/docs/reference/glossary/selector.md @@ -1,22 +1,18 @@ --- -# title: Selector title: Селектор id: selector date: 2018-04-12 full_link: /docs/concepts/overview/working-with-objects/labels/ -# short_description: > -# Allows users to filter a list of resources based on labels. short_description: > Дозволяє користувачам фільтрувати ресурси за мітками. aka: +- Selector tags: - fundamental --- - -Дозволяє користувачам фільтрувати ресурси за мітками. +Дозволяє користувачам фільтрувати ресурси за {{< glossary_tooltip text="мітками" term_id="label" >}}. - -Селектори застосовуються при створенні запитів для фільтрації ресурсів за {{< glossary_tooltip text="мітками" term_id="label" >}}. +Селектори застосовуються при створенні запитів для фільтрації ресурсів за мітками. diff --git a/content/uk/docs/reference/glossary/service-account.md b/content/uk/docs/reference/glossary/service-account.md new file mode 100644 index 0000000000000..b7bea5980593f --- /dev/null +++ b/content/uk/docs/reference/glossary/service-account.md @@ -0,0 +1,18 @@ +--- +title: ServiceAccount +id: service-account +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/configure-service-account/ +short_description: > + Забезпечує ідентифікацію для процесів, які працюють в Podʼі. + +aka: +tags: +- fundamental +- core-object +--- +Забезпечує ідентифікацію для процесів, які працюють в {{< glossary_tooltip text="Podʼі" term_id="pod" >}}. + + + +Коли процеси всередині Podʼів отримують доступ до кластера, їх автентифікує сервер API як певний обліковий запис сервісу, наприклад, `default`. При створенні Podʼа, якщо ви не вказали обліковий запис сервісу, йому автоматично буде призначений типовий обліковий запис сервісу у тому ж {{< glossary_tooltip text="Namespace" term_id="namespace" >}}. diff --git a/content/uk/docs/reference/glossary/service-catalog.md b/content/uk/docs/reference/glossary/service-catalog.md new file mode 100644 index 0000000000000..47168052b5313 --- /dev/null +++ b/content/uk/docs/reference/glossary/service-catalog.md @@ -0,0 +1,18 @@ +--- +title: Сервісний Каталог +id: service-catalog +date: 2018-04-12 +full_link: +short_description: > + Колишній API розширення, який дозволяв програмам, що працюють у кластерах Kubernetes, легко використовувати зовнішні пропозиції керованого програмного забезпечення, наприклад службу сховища даних, яку пропонує постачальник хмарних послуг. + +aka: +- Service Catalog +tags: +- extension +--- +Колишній API розширення, який дозволяв програмам, що працюють у кластерах Kubernetes, легко використовувати зовнішні пропозиції керованого програмного забезпечення, наприклад службу сховища даних, яку пропонує постачальник хмарних послуг. + + + +Це забезпечувало можливість переглядати, створювати та звʼязуватися з зовнішніми {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}}, не потребуючи докладних знань того, як ці служби будуть створені чи управлятися. diff --git a/content/uk/docs/reference/glossary/service.md b/content/uk/docs/reference/glossary/service.md index d813d7056c6b0..f838f1fd47a33 100644 --- a/content/uk/docs/reference/glossary/service.md +++ b/content/uk/docs/reference/glossary/service.md @@ -3,22 +3,20 @@ title: Service id: service date: 2018-04-12 full_link: /docs/concepts/services-networking/service/ -# A way to expose an application running on a set of Pods as a network service. short_description: > - Спосіб відкрити доступ до застосунку, що запущений на декількох Pod'ах у вигляді мережевої служби. + Спосіб відкрити доступ до застосунку, що запущений на декількох Podʼах у вигляді мережевої служби. -aka: tags: - fundamental - core-object --- - -Це абстрактний спосіб відкрити доступ до застосунку, що працює як один (або декілька) {{< glossary_tooltip text="Pod'ів" term_id="pod" >}} у вигляді мережевої служби. +Метод надання доступу ззовні до мережевого застосунку, який працює як один чи кілька {{< glossary_tooltip text="Podʼів" term_id="pod" >}} у вашому кластері. - -Переважно група Pod'ів визначається як Service за допомогою {{< glossary_tooltip text="селектора" term_id="selector" >}}. Додання або вилучення Pod'ів змінить групу Pod'ів, визначених селектором. Service забезпечує надходження мережевого трафіка до актуальної групи Pod'ів для підтримки робочого навантаження. +Набір Podʼів, з якими працює Service, (зазвичай) визначається +{{< glossary_tooltip text="селектором" term_id="selector" >}}. Якщо додаються чи видаляються деякі Podʼи, набір Podʼів, що відповідає селектору, буде змінено. Service переконується, що мережевий трафік може бути направлений на поточний набір Podʼів з робочим навантаженням. + +Serviceʼи Kubernetes можуть використовувати IP-мережу (IPv4, IPv6 або обидві) або посилатися на зовнішнє імʼя в Domain Name System (DNS). + +Абстракція Service дозволяє використовувати інші механізми, такі як Ingress та Gateway. diff --git a/content/uk/docs/reference/glossary/shuffle-sharding.md b/content/uk/docs/reference/glossary/shuffle-sharding.md new file mode 100644 index 0000000000000..b3d120713517b --- /dev/null +++ b/content/uk/docs/reference/glossary/shuffle-sharding.md @@ -0,0 +1,19 @@ +--- +title: Shuffle-sharding +id: shuffle-sharding +date: 2020-03-04 +full_link: +short_description: > + Техніка розподілу запитів до черг, яка забезпечує кращу ізоляцію, ніж хешування за модулем кількості черг. + +aka: +tags: +- fundamental +--- +Техніка розподілу запитів до черг, яка забезпечує кращу ізоляцію, ніж хешування за модулем кількості черг. + + + +Ми часто переймаємось ізоляцією різних потоків запитів один від одного, щоб інтенсивний потік не витісняв менш інтенсивні потоки. Простий спосіб розміщення запитів у черзі — хешування деяких характеристик запиту за модулем кількості черг, щоб отримати індекс черги для використання. Хеш-функція використовує вхідні характеристики запиту, які відповідають потокам. Наприклад, в Інтернеті це часто 5-кортеж джерела та призначення адреси, протоколу та джерела та призначення порту. + +Ця проста схема, заснована на хешуванні, має властивість того, що будь-який інтенсивний потік витісняє всі менш інтенсивні потоки, які хешуються в ту ж чергу. Для забезпечення хорошої ізоляції для великої кількості потоків потрібна велика кількість черг, що є проблематичним. Shuffle-sharding — це легша техніка, яка може краще ізолювати менш інтенсивні потоки від більш інтенсивних. Термінологія shuffle-sharding використовує метафору роздачі карт з колоди; кожна черга — це метафорична карта. Техніка shuffle-sharding починається з хешування характеристик, які ідентифікують потік запитів, для створення хеш-значення з десятками або більше бітів. Потім значення хешу використовується як джерело ентропії для перемішування колоди та роздачі карт на руки (черг). Оглядаються всі роздані черги, і запит поміщається в одну з оглянутих черг з найкоротшою довжиною. З помірним розміром руки не треба оглядати всі роздані карти, і у менш інтенсивного потоку є хороші шанси уникнути впливів більш інтенсивного потоку. З великим розміром руки дорого оглядати роздані черги та складніше для менш інтенсивних потоків уникнути колективних ефектів набору більш інтенсивних потоків. Таким чином, розмір руки повинен бути розумно обраний. diff --git a/content/uk/docs/reference/glossary/sig.md b/content/uk/docs/reference/glossary/sig.md new file mode 100644 index 0000000000000..52715390b4816 --- /dev/null +++ b/content/uk/docs/reference/glossary/sig.md @@ -0,0 +1,20 @@ +--- +title: SIG (special interest group) +id: sig +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#special-interest-groups +short_description: > + Члени спільноти, які спільно керують тривалим процесом або аспектом великого відкритого проєкту Kubernetes. + +aka: +tags: +- community +--- +{{< glossary_tooltip text="Члени спільноти" term_id="member" >}}, які спільно керують тривалим процесом або аспектом великого відкритого проєкту Kubernetes. + + + +Члени в межах SIG мають спільний інтерес у розвитку певної області, такої як архітектура, машинерія API або документація. +SIG повинні дотримуватися [настанов з управління](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md), але вони можуть мати свої власні правила участі та канали комунікації. + +Для отримання додаткової інформації див. репозиторій [kubernetes/community](https://github.com/kubernetes/community) та поточний список [SIG та робочих груп](https://github.com/kubernetes/community/blob/master/sig-list.md). diff --git a/content/uk/docs/reference/glossary/spec.md b/content/uk/docs/reference/glossary/spec.md new file mode 100644 index 0000000000000..dc912176ee8ae --- /dev/null +++ b/content/uk/docs/reference/glossary/spec.md @@ -0,0 +1,21 @@ +--- +title: Spec +id: spec +date: 2023-12-17 +full_link: /docs/concepts/overview/working-with-objects/#object-spec-and-status +short_description: > + Це поле в маніфестах Kubernetes визначає бажаний стан чи конфігурацію конкретних обʼєктів Kubernetes. + +aka: +- Специфікація +tags: +- fundamental +- architecture +--- +Визначає, як слід налаштовувати кожен обʼєкт, такий як Pod або Services, та його бажаний стан. + + + +Практично кожен обʼєкт Kubernetes має два вкладені поля обʼєкта, які визначають конфігурацію обʼєкта: spec та status. Для обʼєктів, які мають специфікацію (spec), ви повинні встановити її при створенні обʼєкта, надаючи опис характеристик, які ви хочете, щоб ресурс мав — його бажаний стан. + +Специфікація різниться для різних обʼєктів, таких як Podʼи, StatefulSets та Services, надаючи налаштування, такі як контейнери, томи, репліки, порти та інші унікальні для кожного типу обʼєкта специфікації. Це поле вказує те, який стан Kubernetes повинен утримувати для визначеного обʼєкта. diff --git a/content/uk/docs/reference/glossary/statefulset.md b/content/uk/docs/reference/glossary/statefulset.md new file mode 100644 index 0000000000000..9bd70062dd1b1 --- /dev/null +++ b/content/uk/docs/reference/glossary/statefulset.md @@ -0,0 +1,22 @@ +--- +title: StatefulSet +id: statefulset +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/statefulset/ +short_description: > + StatefulSet керує розгортанням і масштабуванням групи обʼєктів Pod з постійним сховищем та постійними ідентифікаторами для кожного обʼєкта Pod. + +aka: +tags: +- fundamental +- core-object +- workload +- storage +--- +StatefulSet керує розгортанням і масштабуванням групи {{< glossary_tooltip text="Podʼів" term_id="pod" >}}, *і забезпечує гарантії щодо порядку та унікальності* цих Podʼів. + + + +Схожий на {{< glossary_tooltip term_id="deployment" >}}, StatefulSet керує Podʼами, які базуються на ідентичній специфікації контейнерів. На відміну від Deployment, StatefulSet зберігає постійну ідентичність для кожного свого Podʼа. Ці Podʼи створюються за однаковою специфікацією, але не є взаємозамінними: у кожного є постійний ідентифікатор, який він утримує при переплануванні. + +Якщо ви хочете використовувати томи для забезпечення постійності для вашого завдання, ви можете використовувати StatefulSet як частину рішення. Навіть якщо окремі Podʼи в StatefulSet можуть вийти з ладу, постійні ідентифікатори Podʼів полегшують відповідність наявних томів новим Podʼам, які замінюють ті, що вийшли з ладу. diff --git a/content/uk/docs/reference/glossary/static-pod.md b/content/uk/docs/reference/glossary/static-pod.md new file mode 100644 index 0000000000000..346bcf470492f --- /dev/null +++ b/content/uk/docs/reference/glossary/static-pod.md @@ -0,0 +1,19 @@ +--- +title: Static Pod +id: static-pod +date: 2019-02-12 +full_link: /docs/tasks/configure-pod-container/static-pod/ +short_description: > + Pod, яким управляє безпосередньо демон kubelet на певному вузлі. + +aka: +tags: +- fundamental +--- +{{< glossary_tooltip text="Pod" term_id="pod" >}}, яким управляє безпосередньо демон {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} на певному вузлі, + + + +без його спостереження через сервер API. + +Static Pod не підтримують {{< glossary_tooltip text="ефемерні контейнери" term_id="ephemeral-container" >}}. diff --git a/content/uk/docs/reference/glossary/storage-class.md b/content/uk/docs/reference/glossary/storage-class.md new file mode 100644 index 0000000000000..320bc953e81af --- /dev/null +++ b/content/uk/docs/reference/glossary/storage-class.md @@ -0,0 +1,19 @@ +--- +title: Storage Class +id: storageclass +date: 2018-04-12 +full_link: /docs/concepts/storage/storage-classes +short_description: > + StorageClass надає можливість адміністраторам описати різні доступні типи сховищ. + +aka: +- Клас сховища +tags: +- core-object +- storage +--- + StorageClass надає можливість адміністраторам описати різні доступні типи сховищ. + + + +Класи сховища можуть відповідати рівням обслуговування, політиці резервного копіювання або довільними політиками, визначеними адміністраторами кластера. Кожен клас сховища містить поля `provisioner`, `parameters` та `reclaimPolicy`, які використовуються, коли динамічно резервується {{< glossary_tooltip text="Persistent Volume" term_id="persistent-volume" >}}, що належить класу. Користувачі можуть запитувати певний клас, використовуючи імʼя обʼєкта класу сховища. diff --git a/content/uk/docs/reference/glossary/sysctl.md b/content/uk/docs/reference/glossary/sysctl.md new file mode 100644 index 0000000000000..1a659be571977 --- /dev/null +++ b/content/uk/docs/reference/glossary/sysctl.md @@ -0,0 +1,19 @@ +--- +title: sysctl +id: sysctl +date: 2019-02-12 +full_link: /docs/tasks/administer-cluster/sysctl-cluster/ +short_description: > + Інтерфейс для отримання та встановлення параметрів ядра Unix. + +aka: +tags: +- tool +--- + `sysctl` — це напівстандартизований інтерфейс для читання або зміни атрибутів ядра Unix. + + + +На подібних до Unix системах `sysctl` — це назва інструмента, яким користуються адміністратори для перегляду та зміни цих параметрів, а також системних викликів, які використовують цей інструмент. + +{{< glossary_tooltip text="Контейнер" term_id="container" >}} та мережеві втулки можуть покладатися на значення `sysctl` встановлені певним чином. diff --git a/content/uk/docs/reference/glossary/taint.md b/content/uk/docs/reference/glossary/taint.md new file mode 100644 index 0000000000000..574a83cb8c511 --- /dev/null +++ b/content/uk/docs/reference/glossary/taint.md @@ -0,0 +1,18 @@ +--- +title: Taint +id: taint +date: 2019-01-11 +full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/ +short_description: > + Основний обʼєкт, що складається з трьох обовʼязкових властивостей: key, value, та effect. Taints (додаткові властивості) запобігають розміщенню Podʼів на вузлах чи групах вузлів. + +aka: +tags: +- core-object +- fundamental +--- +Основний обʼєкт, що складається з трьох обовʼязкових властивостей: key, value, та effect. Taints (додаткові властивості) запобігають розміщенню {{< glossary_tooltip text="Podʼів" term_id="pod" >}} на вузлах чи групах вузлів. + + + +Taints та {{< glossary_tooltip text="tolerations" term_id="toleration" >}} співпрацюють, щоб забезпечити те, що Podʼи не розміщуються на непридатних вузлах. Один чи декілька taints застосовуються до вузла. Вузол повинен розміщувати лише Podʼи з tolerations, що збігаються з налаштованими taints. diff --git a/content/uk/docs/reference/glossary/toleration.md b/content/uk/docs/reference/glossary/toleration.md new file mode 100644 index 0000000000000..7e55efb88f2ac --- /dev/null +++ b/content/uk/docs/reference/glossary/toleration.md @@ -0,0 +1,18 @@ +--- +title: Toleration +id: toleration +date: 2019-01-11 +full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/ +short_description: > + Основний обʼєкт, що складається з трьох обовʼязкових властивостей: key, value, та effect. Toleration (дозвіл) дозволяє розміщення Podʼів на вузлах чи групах вузлів, які мають відповідні {{< glossary_tooltip text="taints" term_id="taint" >}}. + +aka: +tags: +- core-object +- fundamental +--- +Основний обʼєкт, що складається з трьох обовʼязкових властивостей: key, value, та effect. Toleration (дозвіл) дозволяє розміщення {{< glossary_tooltip text="Podʼів" term_id="pod" >}} на вузлах чи групах вузлів, які мають відповідні {{< glossary_tooltip text="taints" term_id="taint" >}}. + + + +Tolerations та {{< glossary_tooltip text="taints" term_id="taint" >}} співпрацюють, щоб забезпечити те, що Podʼи не розміщуються на непридатних вузлах. Один чи декілька tolerations застосовуються до {{< glossary_tooltip text="Podʼа" term_id="pod" >}}. Toleration вказує, що {{< glossary_tooltip text="Pod" term_id="pod" >}} може (але не обовʼязково) бути розміщений на вузлах чи групах вузлів із відповідними {{< glossary_tooltip text="taints" term_id="taint" >}}. diff --git a/content/uk/docs/reference/glossary/uid.md b/content/uk/docs/reference/glossary/uid.md new file mode 100644 index 0000000000000..4bcd42165333f --- /dev/null +++ b/content/uk/docs/reference/glossary/uid.md @@ -0,0 +1,17 @@ +--- +title: UID +id: uid +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + Рядок, створений системами Kubernetes для унікальної ідентифікації обʼєктів. + +aka: +tags: +- fundamental +--- +Рядок, створений системами Kubernetes для унікальної ідентифікації обʼєктів. + + + +Кожен обʼєкт, створений протягом усього життя кластера Kubernetes, має відмінний UID. Він призначений для відмінності між історичними випадками схожих сутностей. diff --git a/content/uk/docs/reference/glossary/upstream.md b/content/uk/docs/reference/glossary/upstream.md new file mode 100644 index 0000000000000..a81b589b66160 --- /dev/null +++ b/content/uk/docs/reference/glossary/upstream.md @@ -0,0 +1,18 @@ +--- +title: Upstream (розʼяснення) +id: upstream +date: 2018-04-12 +full_link: +short_description: > + Може вказувати на: основний код Kubernetes або вихідний репозитарій, з якого було зроблено форк репозиторію. + +aka: +tags: +- community +--- +Може вказувати на: основний код Kubernetes або вихідний репозитарій, з якого було зроблено форк репозиторію. + + + +* В **Спільноті Kubernetes**: В розмовах термін *upstream* часто використовується для позначення основного коду Kubernetes, на якому ґрунтуються загальна екосистема, інший код або інструменти сторонніх розробників. Наприклад, [члени спільноти](#term-member) можуть пропонувати перемістити функцію upstream, щоб вона була в основному коді, а не у втулку чи інструменті стороннього розробника. +* В **GitHub** або **git**: Зазвичай вихідний репозитарій називається *upstream*, тоді як репозитарій, який був зроблений форк, вважається *downstream*. diff --git a/content/uk/docs/reference/glossary/userns.md b/content/uk/docs/reference/glossary/userns.md new file mode 100644 index 0000000000000..c882cd5af86bd --- /dev/null +++ b/content/uk/docs/reference/glossary/userns.md @@ -0,0 +1,23 @@ +--- +title: user namespace +id: userns +date: 2021-07-13 +full_link: https://man7.org/linux/man-pages/man7/user_namespaces.7.html +short_description: > + Функція ядра Linux для емуляції привілеїв суперкористувача для непривілейованих користувачів. + +aka: +tags: +- security +--- + +Функція ядра Linux для емуляції привілеїв суперкористувача. Використовується для "контейнерів без прав root". + + + +Простори імен користувача — це особливість ядра Linux, яка дозволяє користувачеві без прав root емулювати привілеї суперкористувача ("root"), наприклад, для запуску контейнерів без прав root поза контейнером. + +Простір імен користувача ефективно застосовується для помʼякшення наслідків можливих атак на прорив з контейнера. + +У контексті просторів імен користувача термін "простір імен" вказує на особливість ядра Linux, а не на +{{< glossary_tooltip text="простір імен" term_id="namespace" >}} у розумінні Kubernetes. diff --git a/content/uk/docs/reference/glossary/volume-plugin.md b/content/uk/docs/reference/glossary/volume-plugin.md new file mode 100644 index 0000000000000..66b92b5c1da54 --- /dev/null +++ b/content/uk/docs/reference/glossary/volume-plugin.md @@ -0,0 +1,18 @@ +--- +title: Volume Plugin +id: volumeplugin +date: 2018-04-12 +full_link: +short_description: > + Втулок томів дозволяє інтеграцію сховища усередині Podʼа. + +aka: +tags: +- core-object +- storage +--- + Втулок томів дозволяє інтеграцію сховища усередині {{< glossary_tooltip text="Podʼа" term_id="pod" >}}. + + + +Втулок томів дозволяє підʼєднувати та монтувати томи сховища для використання у {{< glossary_tooltip text="Podʼі" term_id="pod" >}}. Втулки томів можуть бути _вбудовані_ або _зовнішні_. Вбудовані втулки є частиною репозиторію коду Kubernetes і слідують за його циклом випуску. Зовнішні втулки розробляються незалежно. diff --git a/content/uk/docs/reference/glossary/volume.md b/content/uk/docs/reference/glossary/volume.md new file mode 100644 index 0000000000000..85e6ace50e881 --- /dev/null +++ b/content/uk/docs/reference/glossary/volume.md @@ -0,0 +1,21 @@ +--- +title: Том +id: volume +date: 2018-04-12 +full_link: /docs/concepts/storage/volumes/ +short_description: > + Тека, що містить дані та доступна для контейнерів у Podʼі. + +aka: +- Volume +tags: +- core-object +- fundamental +--- +Тека, що містить дані та доступна для {{< glossary_tooltip text="контейнерів" term_id="container" >}} у {{< glossary_tooltip term_id="pod" text="Podʼі" >}}. + + + +Том Kubernetes існує так довго, як і Pod, який його містить. Відповідно, том існує довше, ніж будь-які контейнери, які працюють у межах Podʼа, і дані в томі зберігаються при перезапуску контейнера. + +Дивіться [сховище](/docs/concepts/storage/) для отримання додаткової інформації. diff --git a/content/uk/docs/reference/glossary/wg.md b/content/uk/docs/reference/glossary/wg.md new file mode 100644 index 0000000000000..dd4947e27b91f --- /dev/null +++ b/content/uk/docs/reference/glossary/wg.md @@ -0,0 +1,20 @@ +--- +title: Робоча група +id: wg +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-working-group-list +short_description: > + Сприяє обговоренню та/або реалізації проєкту з коротким терміном, вузького спрямування чи відокремленого від інших проєктів комітету, SIG чи універсального проєкту. + +aka: +- Working Group +tags: +- community +--- +Сприяє обговоренню та/або реалізації проєкту з коротким терміном, вузького спрямування чи відокремленого від інших проєктів комітету, {{< glossary_tooltip text="SIG" term_id="sig" >}} чи універсального проєкту. + + + +Робочі групи є способом організації людей для виконання конкретного завдання. + +Для отримання додаткової інформації дивіться репозиторій [kubernetes/community](https://github.com/kubernetes/community) та поточний список [SIGs та робочих груп](https://github.com/kubernetes/community/blob/master/sig-list.md). diff --git a/content/uk/docs/reference/glossary/workload.md b/content/uk/docs/reference/glossary/workload.md new file mode 100644 index 0000000000000..0706d08da5563 --- /dev/null +++ b/content/uk/docs/reference/glossary/workload.md @@ -0,0 +1,19 @@ +--- +title: Робоче навантаження +id: workload +date: 2019-02-13 +full_link: /docs/concepts/workloads/ +short_description: > + Робоче навантаження є застосунком, який запущено в Kubernetes. + +aka: +tags: +- fundamental +--- + Робоче навантаження є застосунком, який запущено в Kubernetes. + + + +Різноманітні основні обʼєкти, які представляють різні типи або частини робочого навантаження, включають обʼєкти DaemonSet, Deployment, Job, ReplicaSet та StatefulSet. + +Наприклад, робоче навантаження, що має вебсервер та базу даних має виконувати базу даних в одному {{< glossary_tooltip term_id="StatefulSet" >}} та вебсервер в {{< glossary_tooltip term_id="Deployment" >}}. diff --git a/content/uk/docs/reference/instrumentation/_index.md b/content/uk/docs/reference/instrumentation/_index.md new file mode 100644 index 0000000000000..19c77fa398aa9 --- /dev/null +++ b/content/uk/docs/reference/instrumentation/_index.md @@ -0,0 +1,4 @@ +--- +title: "Інструментування" +weight: 60 +--- \ No newline at end of file diff --git a/content/uk/docs/reference/issues-security/_index.md b/content/uk/docs/reference/issues-security/_index.md new file mode 100644 index 0000000000000..16afa3b3bc2c7 --- /dev/null +++ b/content/uk/docs/reference/issues-security/_index.md @@ -0,0 +1,4 @@ +--- +title: Безпека та проблеми Kubernetes +weight: 70 +--- diff --git a/content/uk/docs/reference/kubectl/_index.md b/content/uk/docs/reference/kubectl/_index.md new file mode 100644 index 0000000000000..eb43a542a2b41 --- /dev/null +++ b/content/uk/docs/reference/kubectl/_index.md @@ -0,0 +1,542 @@ +--- +title: Інструмент командного рядка (kubectl) +content_type: reference +weight: 110 +no_list: true +card: + name: reference + title: Інструмент командного рядка (kubectl) + weight: 20 +--- + + +{{< glossary_definition prepend="Kubernetes надає" term_id="kubectl" length="short" >}} + +Цей інструмент має назву `kubectl`. + +Для отримання налаштувань `kubectl` шукає файл `config` в теці `$HOME/.kube`. Ви можете вказати інший файл [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) у змінній оточення `KUBECONFIG` або у значенні ключа [`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/). + +Тут ми розглянемо синтаксис команд `kubectl`, опис операторів та розберемо їх на прикладах. Докладніше про кожну команду, включаючи всі підтримувані прапорці та підкоманди, див. довідкову документацію [kubectl](/docs/reference/kubectl/generated/kubectl/). + +Інструкції з встановлення знаходяться у статті [Встановлення kubectl](/docs/tasks/tools/#kubectl); короткий посібник є у [шпаргалці](/docs/reference/kubectl/quick-reference/). Якщо ви звикли користуватись інструмент командного рядка `docker`, [`kubectl` для користувачів Docker](/docs/reference/kubectl/docker-cli-to-kubectl/) пояснює деякі еквівалентні команди для Kubernetes. + + + +## Синтаксис {#syntax} + +Використовуйте наступний синтаксис для виконання команд `kubectl` у вашому терміналі: + +```shell +kubectl [команда] [ТИП] [ІМʼЯ] [прапорці] +``` + +де `команда`, `ТИП`, `ІМʼЯ` та `прапорці` визначаються наступним чином: + +* `команда`: Вказує операцію, яку ви хочете виконати з одним чи кількома ресурсами, наприклад `create`, `get`, `describe`, `delete`. + +* `ТИП`: Вказує [тип ресурсу](#resource-types). Типи ресурсів нечутливі до регістру, і можна вказувати форми однини, множини чи абревіатури. Наприклад, наступні команди виводять той самий результат: + + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` + +* `ІМʼЯ`: Вказує імʼя ресурсу. Імена чутливі до регістру. Якщо імʼя відсутнє, виводяться деталі для всіх ресурсів, наприклад `kubectl get pods`. + + При виконанні операції над кількома ресурсами можна вказати кожен ресурс за типом та іменем або вказати один чи кілька файлів: + + * Щоб вказати ресурси за типом та іменем: + + * Щоб групувати ресурси, якщо вони всі є тим самим типом: `ТИП1 імʼя1 імʼя2 імʼя<#>`. + Приклад: `kubectl get pod example-pod1 example-pod2`. + + * Щоб вказати кілька типів ресурсів окремо: `ТИП1/імʼя1 ТИП1/імʼя2 ТИП2/імʼя3 ТИП<#>/імʼя<#>`. + Приклад: `kubectl get pod/example-pod1 replicationcontroller/example-rc1`. + + * Щоб вказати ресурси за допомогою одного чи кількох файлів: `-f файл1 -f файл2 -f файл<#>`. + + * [Використовуйте YAML замість JSON](/docs/concepts/configuration/overview/#general-configuration-tips), оскільки YAML зазвичай є зручнішим для користувача, особливо для файлів конфігурації. + Приклад: `kubectl get -f ./pod.yaml` + +* `прапорці`: Є необовʼязковими. Наприклад, ви можете використовувати прапорці `-s` або `--server`, щоб вказати адресу та порт сервера API Kubernetes. + +{{< caution >}} +Прапорці, які ви вказуєте в командному рядку, перевизначають стандартні значення та будь-які відповідні змінні середовища. +{{< /caution >}} + +Якщо вам потрібна допомога, виконайте команду `kubectl help` у вікні термінала. + +## Автентифікація та перевизначення простору імен в кластері {#in-cluster-authentication-and-namespace-overrides} + +Типово `kubectl` спочатку визначатиме, чи він виконується в середині Podʼа, і отже, в кластері. Програма починає з перевірки наявності змінних середовища `KUBERNETES_SERVICE_HOST` та `KUBERNETES_SERVICE_PORT`, а також наявності файлу токена облікового запису служби за шляхом `/var/run/secrets/kubernetes.io/serviceaccount/token`. Якщо всі три умови виконуються, вважається, що використовується автентифікація в кластері. + +Для забезпечення зворотної сумісності, якщо під час автентифікації в кластері встановлено змінну середовища `POD_NAMESPACE`, вона перевизначить типовий простір імен скориставшись токеном облікового запису служби. Це буде впливати на будь-які маніфести або інструменти, які покладаються на типовий простір імен. + +**Змінна середовища `POD_NAMESPACE`** + +Якщо змінна середовища `POD_NAMESPACE` встановлена, операції CLI для ресурсів з обмеженим простором імен будуть отримувати типове значення від цієї змінної. Наприклад, якщо змінна встановлена в `seattle`, `kubectl get pods` поверне Podʼи з простору імен `seattle`. Це тому, що Podʼи є ресурсом з обмеженим простором імен, і ми не вказали команді простір імен в командному рядку. Ознайомтесь з виводом `kubectl api-resources`, щоб визначити, чи ресурс має обмежений простір імен чи ні. + +Явне використання `--namespace ` перевизначає цю поведінку. + +**Як `kubectl` обробляє токени ServiceAccount** + +Якщо: + +* маємо файл токена облікового запису служби Kubernetes, змонтований за шляхом `/var/run/secrets/kubernetes.io/serviceaccount/token`, і +* встановлено змінну середовища `KUBERNETES_SERVICE_HOST`, і +* встановлено змінну середовища `KUBERNETES_SERVICE_PORT`, і +* ви не вказуєте простір імен явно в командному рядку `kubectl` + +тоді `kubectl` вважатиме, що він працює в вашому кластері. Інструмент `kubectl` знаходить простір імен цього облікового запису служби (це такий самий простір імен, що й у Podʼа) та діє відповідно до цього простору імен. Це відрізняється від того, що відбувається поза кластером; коли `kubectl` працює за межами кластера і ви не вказуєте простір імен, команда `kubectl` діє в просторі імен, встановленому для поточного контексту у вашій конфігурації клієнта. Щоб змінити типовий простір імен для `kubectl`, ви можете використовувати наступну команду: + +```shell +kubectl config set-context --current --namespace= +``` + +## Операції {#operations} + +Наступна таблиця містить короткі описи та загальний синтаксис для всіх операцій `kubectl`: + +Операція | Синтаксис | Опис +-- | -- | -- +`alpha` | `kubectl alpha SUBCOMMAND [flags]` | Вивести список доступних команд, які відповідають альфа-функціям, які зазвичай не є активованими у кластерах Kubernetes. +`annotate` | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | Додати або оновити анотації одного чи кількох ресурсів. +`api-resources` | `kubectl api-resources [flags]` | Вивести список доступних ресурсів API. +`api-versions` | `kubectl api-versions [flags]` | Вивести список доступних версій API. +`apply` | `kubectl apply -f FILENAME [flags]`| Застосувати зміну конфігурації до ресурсу з файлу або stdin. +`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | Приєднатися до запущеного контейнера для перегляду виводу або взаємодії з контейнером (stdin). +`auth` | `kubectl auth [flags] [options]` | Перегляд авторизації. +`autoscale` | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | Автоматично масштабувати набір Podʼів, керованих контролером реплікації. +`certificate` | `kubectl certificate SUBCOMMAND [options]` | Змінити ресурси сертифікатів. +`cluster-info` | `kubectl cluster-info [flags]` | Показати інформацію про кінцеві точки майстра та служб в кластері. +`completion` | `kubectl completion SHELL [options]` | Вивести код функції автозавершення оболонки для bash або zsh. +`config` | `kubectl config SUBCOMMAND [flags]` | Змінити файли kubeconfig. Див. окремі команди для отримання деталей. +`convert` | `kubectl convert -f FILENAME [options]` | Конвертувати файли конфігурації між різними версіями API. Приймаються формати YAML та JSON. Примітка — потрібно встановити втулок `kubectl-convert`. +`cordon` | `kubectl cordon NODE [options]` | Позначити вузол як недоступний для планування. +`cp` | `kubectl cp [options]` | Копіювати файли та теки в та з контейнерів. +`create` | `kubectl create -f FILENAME [flags]` | Створити один чи кілька ресурсів з файлу або stdin. +`delete` | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | Видалити ресурси з файлу, stdin або вказати селектори міток, імена, селектори ресурсів або ресурси. +`describe` | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | Показати докладний стан одного чи кількох ресурсів. +`diff` | `kubectl diff -f FILENAME [flags]`| Показати розбіжності між файлом або stdin від робочої конфігурації. +`drain` | `kubectl drain NODE [options]` | Звільнити вузол від ресурсів для підготовки його до обслуговування. +`edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | Редагувати та оновити визначення одного чи кількох ресурсів на сервері за допомогою типового редактора. +`events` | `kubectl events` | Вивести список подій. +`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Виконати команду в контейнері у Podʼі. +`explain` | `kubectl explain TYPE [--recursive=false] [flags]` | Отримати документацію про різні ресурси, такі як Podʼи, вузли, служби і т. д. +`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] | Надати доступ ззовні до контролеру реплікації, Service або Pod, як до нового Service Kubernetes. +`get` | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | Вивести список ресурсів. +`kustomize` | `kubectl kustomize [flags] [options]` | Вивести список ресурсів API, згенерованих з інструкцій у файлі kustomization.yaml. Аргумент повинен бути шляхом до теки, що містить файл, або URL репозиторію git з суфіксом шляху, який вказує на те ж саме відносно кореня репозиторію. +`label` | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | Додати або оновити мітки одного чи кількох ресурсів. +`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Вивести логи контейнера у Podʼі. +`options` | `kubectl options` | Список глобальних параметрів командного рядка, які застосовуються до всіх команд. +`patch` | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | Оновити одне чи кілька полів ресурсу за допомогою процесу стратегічного обʼєднання патчів. +`plugin` | `kubectl plugin [flags] [options]` | Надає інструменти для взаємодії з втулками. +`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | Переспрямувати один або декілька локальних портів у Pod. +`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Запустити проксі до сервера API Kubernetes. +`replace` | `kubectl replace -f FILENAME` | Замінити ресурс з файлу або stdin. +`rollout` | `kubectl rollout SUBCOMMAND [options]` | Керувати розгортанням ресурсу. Дійсні типи ресурсів: Deployment, DaemonSet та StatefulSet. +`run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | Запустити вказаний образ у кластері. +`scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | Оновити розмір вказаного контролера реплікації. +`set` | `kubectl set SUBCOMMAND [options]` | Налаштувати ресурси застосунку. +`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | Оновити taint на одному чи декількох вузлах. +`top` | kubectl top (POD | NODE) [flags] [options] | Показати використання ресурсів (CPU/Memory/Storage) для Podʼу чи вузла. +`uncordon` | `kubectl uncordon NODE [options]` | Позначити вузол як доступний для планування. +`version` | `kubectl version [--client] [flags]` | Показати версію Kubernetes, яка працює на клієнті та сервері. +`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | Експериментально: чекати на певний стан одного чи кількох ресурсів. + +Щоб дізнатися більше про операції, що виконують команди, див. довідку [kubectl](/docs/reference/kubectl/kubectl/). + +## Типи ресурсів {#resource-types} + +У наступній таблиці наведено список всіх підтримуваних типів ресурсів та їх скорочених аліасів. + +(Цей вивід можна отримати за допомогою `kubectl api-resources` і був актуальним на момент Kubernetes 1.25.0) + +| ІМʼЯ | СКОРОЧЕННЯ | ВЕРСІЯ API | ВИМІРЮВАНИЙ | ТИП | +|---|---|---|---|---| +| `bindings` | | v1 | true | Binding | +| `componentstatuses` | `cs` | v1 | false | ComponentStatus | +| `configmaps` | `cm` | v1 | true | ConfigMap | +| `endpoints` | `ep` | v1 | true | Endpoints | +| `events` | `ev` | v1 | true | Event | +| `limitranges` | `limits` | v1 | true | LimitRange | +| `namespaces` | `ns` | v1 | false | Namespace | +| `nodes` | `no` | v1 | false | Node | +| `persistentvolumeclaims` | `pvc` | v1 | true | PersistentVolumeClaim | +| `persistentvolumes` | `pv` | v1 | false | PersistentVolume | +| `pods` | `po` | v1 | true | Pod | +| `podtemplates` | | v1 | true | PodTemplate | +| `replicationcontrollers` | `rc` | v1 | true | ReplicationController | +| `resourcequotas` | `quota` | v1 | true | ResourceQuota | +| `secrets` | | v1 | true | Secret | +| `serviceaccounts` | `sa` | v1 | true | ServiceAccount | +| `services` | `svc` | v1 | true | Service | +| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io/v1 | false | MutatingWebhookConfiguration | +| `validatingwebhookconfigurations` | | admissionregistration.k8s.io/v1 | false | ValidatingWebhookConfiguration | +| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io/v1 | false | CustomResourceDefinition | +| `apiservices` | | apiregistration.k8s.io/v1 | false | APIService | +| `controllerrevisions` | | apps/v1 | true | ControllerRevision | +| `daemonsets` | `ds` | apps/v1 | true | DaemonSet | +| `deployments` | `deploy` | apps/v1 | true | Deployment | +| `replicasets` | `rs` | apps/v1 | true | ReplicaSet | +| `statefulsets` | `sts` | apps/v1 | true | StatefulSet | +| `tokenreviews` | | authentication.k8s.io/v1 | false | TokenReview | +| `localsubjectaccessreviews` | | authorization.k8s.io/v1 | true | LocalSubjectAccessReview | +| `selfsubjectaccessreviews` | | authorization.k8s.io/v1 | false | SelfSubjectAccessReview | +| `selfsubjectrulesreviews` | | authorization.k8s.io/v1 | false | SelfSubjectRulesReview | +| `subjectaccessreviews` | | authorization.k8s.io/v1 | false | SubjectAccessReview | +| `horizontalpodautoscalers` | `hpa` | autoscaling/v2 | true | HorizontalPodAutoscaler | +| `cronjobs` | `cj` | batch/v1 | true | CronJob | +| `jobs` | | batch/v1 | true | Job | +| `certificatesigningrequests` | `csr` | certificates.k8s.io/v1 | false | CertificateSigningRequest | +| `leases` | | coordination.k8s.io/v1 | true | Lease | +| `endpointslices` | | discovery.k8s.io/v1 | true | EndpointSlice | +| `events` | `ev` | events.k8s.io/v1 | true | Event | +| `flowschemas` | | flowcontrol.apiserver.k8s.io/v1beta2 | false | FlowSchema | +| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io/v1beta2 | false | PriorityLevelConfiguration | +| `ingressclasses` | | networking.k8s.io/v1 | false | IngressClass | +| `ingresses` | `ing` | networking.k8s.io/v1 | true | Ingress | +| `networkpolicies` | `netpol` | networking.k8s.io/v1 | true | NetworkPolicy | +| `runtimeclasses` | | node.k8s.io/v1 | false | RuntimeClass | +| `poddisruptionbudgets` | `pdb` | policy/v1 | true | PodDisruptionBudget | +| `podsecuritypolicies` | `psp` | policy/v1beta1 | false | PodSecurityPolicy | +| `clusterrolebindings` | | rbac.authorization.k8s.io/v1 | false | ClusterRoleBinding | +| `clusterroles` | | rbac.authorization.k8s.io/v1 | false | ClusterRole | +| `rolebindings` | | rbac.authorization.k8s.io/v1 | true | RoleBinding | +| `roles` | | rbac.authorization.k8s.io/v1 | true | Role | +| `priorityclasses` | `pc` | scheduling.k8s.io/v1 | false | PriorityClass | +| `csidrivers` | | storage.k8s.io/v1 | false | CSIDriver | +| `csinodes` | | storage.k8s.io/v1 | false | CSINode | +| `csistoragecapacities` | | storage.k8s.io/v1 | true | CSIStorageCapacity | +| `storageclasses` | `sc` | storage.k8s.io/v1 | false | StorageClass | +| `volumeattachments` | | storage.k8s.io/v1 | false | VolumeAttachment | + +## Параметри виводу {#output-options} + +Використовуйте наступні розділи для отримання інформації про те, як ви можете форматувати або сортувати вивід деяких команд. Докладні відомості щодо команд, які підтримують різні параметри виводу, див. в документації по [kubectl](/docs/reference/kubectl/kubectl/). + +### Форматування виводу {#formatting-output} + +Стандартний формат виводу для всіх команд `kubectl` – це читабельний текстовий формат. Щоб вивести деталі у вашому терміналі у певному форматі, ви можете додати параметр `-o` або `--output` до підтримуваної команди `kubectl`. + +#### Синтаксис + +```shell +kubectl [команда] [ТИП] [ІМʼЯ] -o <формат_виводу> +``` + +Залежно від операції `kubectl`, підтримуються наступні формати виводу: + +Формат виводу | Опис +--------------| ----------- +`-o custom-columns=<специфікація>` | Вивести таблицю, використовуючи розділений комою список [власних стовпців](#custom-columns). +`-o custom-columns-file=<імʼя_файлу>` | Вивести таблицю, використовуючи шаблон [власних стовпців](#custom-columnsв) у файлі `<імʼя_файлу>`. +`-o json` | Вивести обʼєкт API у форматі JSON. +`-o jsonpath=<шаблон>` | Вивести поля, визначені в виразі [jsonpath](/docs/reference/kubectl/jsonpath/). +`-o jsonpath-file=<імʼя_файлу>` | Вивести поля, визначені в виразі [jsonpath](/docs/reference/kubectl/jsonpath/) у файлі `<імʼя_файлу>`. +`-o name` | Вивести лише імʼя ресурсу і нічого більше. +`-o wide` | Вивести у текстовому форматі з будь-якою додатковою інформацією. Для Pod включно з імʼям вузла. +`-o yaml` | Вивести обʼєкт API у форматі YAML. + +##### Приклад + +Тут наступна команда виводить інформацію про Pod у форматі YAML: + +```shell +kubectl get pod web-pod-13je7 -o yaml +``` + +Нагадування: Дивіться довідку [kubectl](/docs/reference/kubectl/kubectl/) для отримання деталей щодо підтримуваних форматів виводу для кожної команди. + +#### Власні стовпці {#custom-columns} + +Щоб визначити власні стовпці та виводити лише ті деталі, які вам потрібні у вигляді таблиці, ви можете використовувати опцію `custom-columns`. Ви можете вибрати визначення спеціальних стовпців під час складення параметрів команди або використовувати файл шаблону: `-o custom-columns=` або `-o custom-columns-file=`. + +##### Приклади + +З використанням параметрів в командному рядку: + +```shell +kubectl get pods -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion +``` + +З використанням файлу шаблону `template.txt`: + +```shell +kubectl get pods -o custom-columns-file=template.txt +``` + +де `template.txt` містить: + +``` +NAME RSRC +metadata.name metadata.resourceVersion +``` + +Результати виводу будуть виглядати як для використання шаблону, так і для параметрів командного рядка, як: + +``` +NAME RSRC +submit-queue 610995 +``` + +#### Стовпці на стороні сервера {#server-side-columns} + +`kubectl` підтримує отримання конкретної інформації в стовпці щодо обʼєктів від сервера. Це означає, що для будь-якого заданого ресурсу сервер поверне стовпці та рядки, що стосуються цього ресурсу, для показу його клієнту. Це дозволяє отримати послідовний, зручний для читання вивід для різних клієнтів, які використовуються для одного і того ж кластера, оскільки сервер ізолює деталі виведення. + +Ця функція стандартно увімкнена. Щоб вимкнути її, додайте прапорець `--server-print=false` до команди `kubectl get`. + +##### Приклади + +Щоб вивести інформацію про стан Podʼа, використовуйте команду на зразок наступної: + +```shell +kubectl get pods --server-print=false +``` + +Вивід буде подібний до: + +``` +NAME AGE +pod-name 1m +``` + +### Сортування списку обʼєктів {#sorting-list-of-objects} + +Щоб вивести обʼєкти в відсортованому списку у вашому вікні термінала, ви можете додати прапорець `--sort-by` до команди `kubectl`. Впорядкуйте ваші обʼєкти, вказавши будь-яке числове чи рядкове поле з прапорцем `--sort-by`. Для вказання поля використовуйте вираз [jsonpath](/docs/reference/kubectl/jsonpath/). + +#### Синтаксис + +```shell +kubectl [команда] [ТИП] [ІМ'Я] --sort-by=<вираз_jsonpath> +``` + +##### Приклад + +Щоб вивести список Podʼів, відсортованих за назвами, зробіть наступне: + +```shell +kubectl get pods --sort-by=.metadata.name +``` + +## Приклади: Загальні операції {#examples-common-operations} + +Використовуйте цей набір прикладів, щоб ознайомитися з тим, як використовувати найпоширеніші операції `kubectl`: + +`kubectl apply` — Застосувати або оновити ресурс із файлу чи stdin. + +```shell +# Створити службу, використовуючи визначення у файлі example-service.yaml. +kubectl apply -f example-service.yaml + +# Створити контролер реплікації, використовуючи визначення у файлі example-controller.yaml. +kubectl apply -f example-controller.yaml + +# Створити обʼєкти, які визначені у файлах з розширеннями .yaml, .yml, або .json у теці . +kubectl apply -f +``` + +`kubectl get` — Показати відомості про один чи кілька ресурсів. + +```shell +# Показати всі Podʼі у форматі звичайного тексту. +kubectl get pods + +# Показати всі Podʼі у форматі звичайного тексту та додаткову інформацію (наприклад, імʼя вузла). +kubectl get pods -o wide + +# Показати контролер реплікації із вказаним імʼям у форматі звичайного тексту. Порада: Ви можете скоротити та замінити тип ресурсу 'replicationcontroller' на скорочену назву 'rc'. +kubectl get replicationcontroller + +# Показати всі контролери реплікації та служби разом у форматі звичайного тексту. +kubectl get rc,services + +# Показати всі daemonsets у форматі звичайного тексту. +kubectl get ds + +# Показати всі Podʼи, які працюють на вузлі server01 +kubectl get pods --field-selector=spec.nodeName=server01 +``` + +`kubectl describe` — Показати детальний стан одного чи кількох ресурсів, включаючи ті, які ще не ініціалізовані. + +```shell +# Показати деталі вузла із ім'ям . +kubectl describe nodes + +# Показати деталі Podʼу із ім'ям . +kubectl describe pods/ + +# Показати деталі всіх Podʼів, які керуються контролером реплікації із вказаним ім'ям . +# Памʼятайте: Будь-які Podʼи, які створює контролер реплікації, отримують префікс із імʼям контролера реплікації. +kubectl describe pods + +# Показати всі Podʼи +kubectl describe pods +``` + +{{< note >}} +Команда `kubectl get` зазвичай використовується для отримання одного чи кількох ресурсів того ж типу ресурсу. Вона має багатий набір прапорців, що дозволяють налаштовувати формат виводу за допомогою прапорця `-o` або `--output`, наприклад. Ви можете вказати прапорець `-w` або `--watch`, щоб почати слідкування за оновленнями для певного обʼєкта. Команда `kubectl describe` більше фокусується на описі багатьох повʼязаних аспектів вказаного ресурсу. Вона може робити кілька викликів до API-сервера для побудови виводу для користувача. Наприклад, команда `kubectl describe node` отримує не тільки інформацію про вузол, але й підсумок Podʼів, які працюють на ньому, події, створені для вузла, і т. д. +{{< /note >}} + +`kubectl delete` — Видалити ресурси або з використанням файлу, або з stdin, або вказавши селектори міток, імена, селектори ресурсів чи самі ресурси. + +```shell +# Видалити Pod, використовуючи тип та імʼя, вказане у файлі pod.yaml. +kubectl delete -f pod.yaml + +# Видалити всі Podʼи та служби із міткою '='. +kubectl delete pods,services -l = + +# Видалити всі Podʼи, включаючи неініціалізовані. +kubectl delete pods --all +``` + +`kubectl exec` — Виконати команду у контейнері Podʼу. + +```shell +# Отримати вивід виконання команди 'date' у Podʼі . Типово вивід виконується з першого контейнера. +kubectl exec -- date + +# Отримати вивід виконання команди 'date' у контейнері Podʼу . +kubectl exec -c -- date + +# Отримати інтерактивний TTY та виконати /bin/bash у Podʼі . Типово вивід виконується з першого контейнера. +kubectl exec -ti -- /bin/bash +``` + +`kubectl logs` — Вивести логи для контейнера у Podʼі. + +```shell +# Отримати логи із Podʼу . +kubectl logs + +# Почати виведення логів у режимі стрічки із Podʼу . Це схоже на команду 'tail -f' у Linux. +kubectl logs -f +``` + +`kubectl diff` — Переглянути відмінності запропонованих оновлень кластера. + +```shell +# Відмінності ресурсів, включених у "pod.json". +kubectl diff -f pod.json + +# Відмінності, отримані з stdin. +cat service.yaml | kubectl diff -f - +``` + +## Приклади: Створення та використання втулків {#examples-creating-and-using-plugins} + +Використовуйте цей набір прикладів, щоб ознайомитися із написанням та використанням втулків `kubectl`: + +```shell +# створіть простий втулок будь-якою мовою та зробить файл виконуваним +# так, щоб він починався префіксом "kubectl-" +cat ./kubectl-hello +``` + +```shell +#!/bin/sh + +# цей втулок виводить слова "hello world" +echo "hello world" +``` + +Дайте втулку права на виконання: + +```bash +chmod a+x ./kubectl-hello + +# та перемістіть його в місце, яке є у вашому шляху (PATH) +sudo mv ./kubectl-hello /usr/local/bin +sudo chown root:root /usr/local/bin + +# Ви зараз створили та "встановили" втулок kubectl. +# Ви можете почати використовувати цей втулок, викликаючи його з kubectl, +# ніби це звичайна команда +kubectl hello +``` + +``` +hello world +``` + +```shell +# Ви можете "вилучити" втулок, видаливши його з теки у вашому +# $PATH, де ви його розмістили +sudo rm /usr/local/bin/kubectl-hello +``` + +Щоб переглянути всі втулки, доступні для `kubectl`, використовуйте команду `kubectl plugin list`: + +```shell +kubectl plugin list +``` + +Вивід буде схожий на: + +``` +The following kubectl-compatible plugins are available: + +/usr/local/bin/kubectl-hello +/usr/local/bin/kubectl-foo +/usr/local/bin/kubectl-bar +``` + +`kubectl plugin list` також попереджає вас про втулки, які не мають прав на виконання, або які перекриваються з іншими втулками; наприклад: + +```shell +sudo chmod -x /usr/local/bin/kubectl-foo # вилучити права виконання +kubectl plugin list +``` + +``` +The following kubectl-compatible plugins are available: + +/usr/local/bin/kubectl-hello +/usr/local/bin/kubectl-foo + - попередження: /usr/local/bin/kubectl-foo визначено як втулок, але він не є виконавчим +/usr/local/bin/kubectl-bar + +error: one plugin warning was found +``` + +Ви можете думати про втулки як про можливість будувати більш складні функції на основі наявних команд `kubectl`: + +```shell +cat ./kubectl-whoami +``` + +Наступні кілька прикладів передбачають, що ви вже зробили так, що `kubectl-whoami` має наступний вміст: + +```shell +#!/bin/bash + +# цей втулок використовує команду `kubectl config` для виведення +# інформації про поточного користувача, на основі вибраного контексту +kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}' +``` + +Запуск вищезазначеної команди дає вам вивід із зазначенням користувача для поточного контексту у вашому файлі KUBECONFIG: + +```shell +# зробіть файл виконавчим +sudo chmod +x ./kubectl-whoami + +# та перемістіть його у ваш шлях (PATH) +sudo mv ./kubectl-whoami /usr/local/bin + +kubectl whoami +Current user: plugins-user +``` + +## {{% heading "whatsnext" %}} + +* Ознайомтеся з документацією `kubectl`: + * [довідник команд](/docs/reference/kubectl/kubectl/) + * специфікації аргументів командного рядка в [довіднику](/docs/reference/kubectl/generated/kubectl/) +* Дізнайтеся про [домовленості використання `kubectl`](/docs/reference/kubectl/conventions/) +* Ознайомтеся з підтримкою [JSONPath](/docs/reference/kubectl/jsonpath/) у kubectl +* Дізнайтеся, як [розширювати kubectl за допомогою втулків](/docs/tasks/extend-kubectl/kubectl-plugins) + * Для отримання додаткової інформації про втулки, подивіться [приклад CLI-втулка](https://github.com/kubernetes/sample-cli-plugin). diff --git a/content/uk/docs/reference/kubernetes-api/_index.md b/content/uk/docs/reference/kubernetes-api/_index.md new file mode 100644 index 0000000000000..b9c741de081a0 --- /dev/null +++ b/content/uk/docs/reference/kubernetes-api/_index.md @@ -0,0 +1,12 @@ +--- +title: "API Kubernetes" +weight: 50 +card: + title: Довідник API Kubernetes + name: reference + weight: 40 +--- + + + +{{< glossary_definition prepend="API Kubernetes це" term_id="kubernetes-api" length="all" >}} diff --git a/content/uk/docs/reference/labels-annotations-taints/_index.md b/content/uk/docs/reference/labels-annotations-taints/_index.md new file mode 100644 index 0000000000000..21ae4adfa7571 --- /dev/null +++ b/content/uk/docs/reference/labels-annotations-taints/_index.md @@ -0,0 +1,2344 @@ +--- +title: Відомі мітки, анотації та позначення +content_type: concept +weight: 40 +no_list: true +card: + name: reference + weight: 30 + anchors: + - anchor: "#labels-annotations-and-taints-used-on-api-objects" + title: Мітки, анотації та позначення +--- + + + +Kubernetes реалізує всі мітки та анотації в просторах імен `kubernetes.io` та `k8s.io`. + +Цей документ одночасно є і довідником, і точкою для призначення значень. + + + +## Мітки, анотації та позначення, використані в обʼєктах API {#labels-annotations-and-taints-used-on-api-objects} + +### apf.kubernetes.io/autoupdate-spec + +Тип: Annotation + +Приклад: `apf.kubernetes.io/autoupdate-spec: "true"` + +Використовується для: [Обʼєктів `FlowSchema` та `PriorityLevelConfiguration`](/docs/concepts/cluster-administration/flow-control/#defaults) + +Якщо ця анотація встановлена в значення true для FlowSchema або PriorityLevelConfiguration, то `spec` для цього обʼєкта управляється kube-apiserver. Якщо сервер API не впізнає обʼєкт APF та ви анотуєте його для автоматичного оновлення, сервер API видаляє весь обʼєкт. У іншому випадку сервер API не управляє специфікацією обʼєкта. Докладніше читайте [Обслуговування обовʼязкових та рекомендованих обʼєктів конфігурації](/docs/concepts/cluster-administration/flow-control/#maintenance-of-the-mandatory-and-suggested-configuration-objects). + +### app.kubernetes.io/component + +Тип: Label + +Приклад: `app.kubernetes.io/component: "database"` + +Використовується для: Всі обʼєкти (зазвичай використовується на [ресурсах робочого навантаження](/docs/reference/kubernetes-api/workload-resources/)). + +Компонент в архітектурі застосунку. + +Одна з [рекомендованих міток](/docs/concepts/overview/working-with-objects/common-labels/#labels). + +### app.kubernetes.io/created-by (deprecated) + +Тип: Label + +Приклад: `app.kubernetes.io/created-by: "controller-manager"` + +Використовується для: Всі обʼєкти (зазвичай використовується на [ресурсах робочого навантаження](/docs/reference/kubernetes-api/workload-resources/)). + +Контролер/користувач, який створив цей ресурс. + +{{< note >}} +Починаючи з v1.9, ця мітка є застарілою. +{{< /note >}} + +### app.kubernetes.io/instance + +Тип: Label + +Приклад: `app.kubernetes.io/instance: "mysql-abcxzy"` + +Використовується для: Всі обʼєкти (зазвичай використовується на +[ресурсах робочого навантаження](/docs/reference/kubernetes-api/workload-resources/)). + +Унікальне імʼя, що ідентифікує екземпляр застосунку. +Для призначення неунікального імені використовуйте [app.kubernetes.io/name](#app-kubernetes-io-name). + +Одна з [рекомендованих міток](/docs/concepts/overview/working-with-objects/common-labels/#labels). + +### app.kubernetes.io/managed-by + +Тип: Label + +Приклад: `app.kubernetes.io/managed-by: "helm"` + +Використовується для: Всі обʼєкти (зазвичай використовується на +[ресурсах робочого навантаження](/docs/reference/kubernetes-api/workload-resources/)). + +Інструмент, що використовується для управління роботою застосунку. + +Одна з [рекомендованих міток](/docs/concepts/overview/working-with-objects/common-labels/#labels). + +### app.kubernetes.io/name + +Тип: Label + +Приклад: `app.kubernetes.io/name: "mysql"` + +Використовується для: Всі обʼєкти (зазвичай використовується на +[ресурсах робочого навантаження](/docs/reference/kubernetes-api/workload-resources/)). + +Назва застосунку. + +Одна з [рекомендованих міток](/docs/concepts/overview/working-with-objects/common-labels/#labels). + +### app.kubernetes.io/part-of + +Тип: Label + +Приклад: `app.kubernetes.io/part-of: "wordpress"` + +Використовується для: Всі обʼєкти (зазвичай використовується на +[ресурсах робочого навантаження](/docs/reference/kubernetes-api/workload-resources/)). + +Назва більшої системи, до якої належить застосунок. + +Одна з [рекомендованих міток](/docs/concepts/overview/working-with-objects/common-labels/#labels). + +### app.kubernetes.io/version + +Тип: Label + +Приклад: `app.kubernetes.io/version: "5.7.21"` + +Використовується для: Всі обʼєкти (зазвичай використовується на +[ресурсах робочого навантаження](/docs/reference/kubernetes-api/workload-resources/)). + +Поточна версія застосунку. + +Загальні форми значень включають: + +- [семантична версія](https://semver.org/spec/v1.0.0.html) +- [хеш ревізії Git](https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection#_single_revisions) для вихідного коду. + +Одна з [рекомендованих міток](/docs/concepts/overview/working-with-objects/common-labels/#labels). + +### applyset.kubernetes.io/additional-namespaces (alpha) {#applyset-kubernetes-io-additional-namespaces} + +Тип: Annotation + +Приклад: `applyset.kubernetes.io/additional-namespaces: "namespace1,namespace2"` + +Використовується для: Обʼєкти, які використовуються як батьки ApplySet. + +Використання цієї анотації є альфа-версією. Для Kubernetes версії {{< skew currentVersion >}} ви можете використовувати цю анотацію на Secrets, ConfigMaps або власних ресурсах, якщо {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinition" >}}, що їх визначає, має мітку `applyset.kubernetes.io/is-parent-type`. + +Частина специфікації, яка використовується для реалізації [обрізки на основі ApplySet в kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune). Ця анотація застосовується до батьківського обʼєкта, який використовується для відстеження ApplySet для розширення області застосування ApplySet поза власним простором імен батьківського об'єкта (якщо є). Значення — це розділені комами імена просторів імен, в яких знаходяться обʼєкти, відмінні від простору імен батьківського обʼєкта. + + + + +### applyset.kubernetes.io/contains-group-resources (alpha) {#applyset-kubernetes-io-contains-group-resources} + +Type: Annotation + +Example: `applyset.kubernetes.io/contains-group-resources: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"` + +Used on: Objects being used as ApplySet parents. + +Use of this annotation is Alpha. +For Kubernetes version {{< skew currentVersion >}}, you can use this annotation on Secrets, ConfigMaps, +or custom resources if the CustomResourceDefinition +defining them has the `applyset.kubernetes.io/is-parent-type` label. + +Part of the specification used to implement +[ApplySet-based pruning in kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune). +This annotation is applied to the parent object used to track an ApplySet to optimize listing of +ApplySet member objects. It is optional in the ApplySet specification, as tools can perform discovery +or use a different optimization. However, as of Kubernetes version {{< skew currentVersion >}}, +it is required by kubectl. When present, the value of this annotation must be a comma separated list +of the group-kinds, in the fully-qualified name format, i.e. `.`. + +### applyset.kubernetes.io/id (alpha) {#applyset-kubernetes-io-id} + +Type: Label + +Example: `applyset.kubernetes.io/id: "applyset-0eFHV8ySqp7XoShsGvyWFQD3s96yqwHmzc4e0HR1dsY-v1"` + +Used on: Objects being used as ApplySet parents. + +Use of this label is Alpha. +For Kubernetes version {{< skew currentVersion >}}, you can use this label on Secrets, ConfigMaps, +or custom resources if the CustomResourceDefinition +defining them has the `applyset.kubernetes.io/is-parent-type` label. + +Part of the specification used to implement +[ApplySet-based pruning in kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune). +This label is what makes an object an ApplySet parent object. +Its value is the unique ID of the ApplySet, which is derived from the identity of the parent +object itself. This ID **must** be the base64 encoding (using the URL safe encoding of RFC4648) of +the hash of the group-kind-name-namespace of the object it is on, in the form: +`...))>`. +There is no relation between the value of this label and object UID. + +### applyset.kubernetes.io/is-parent-type (alpha) {#applyset-kubernetes-io-is-parent-type} + +Type: Label + +Example: `applyset.kubernetes.io/is-parent-type: "true"` + +Used on: Custom Resource Definition (CRD) + +Use of this label is Alpha. +Part of the specification used to implement +[ApplySet-based pruning in kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune). +You can set this label on a CustomResourceDefinition (CRD) to identify the custom resource type it +defines (not the CRD itself) as an allowed parent for an ApplySet. +The only permitted value for this label is `"true"`; if you want to mark a CRD as +not being a valid parent for ApplySets, omit this label. + +### applyset.kubernetes.io/part-of (alpha) {#applyset-kubernetes-io-part-of} + +Type: Label + +Example: `applyset.kubernetes.io/part-of: "applyset-0eFHV8ySqp7XoShsGvyWFQD3s96yqwHmzc4e0HR1dsY-v1"` + +Used on: All objects. + +Use of this label is Alpha. +Part of the specification used to implement +[ApplySet-based pruning in kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune). +This label is what makes an object a member of an ApplySet. +The value of the label **must** match the value of the `applyset.kubernetes.io/id` +label on the parent object. + +### applyset.kubernetes.io/tooling (alpha) {#applyset-kubernetes-io-tooling} + +Type: Annotation + +Example: `applyset.kubernetes.io/tooling: "kubectl/v{{< skew currentVersion >}}"` + +Used on: Objects being used as ApplySet parents. + +Use of this annotation is Alpha. +For Kubernetes version {{< skew currentVersion >}}, you can use this annotation on Secrets, +ConfigMaps, or custom resources if the CustomResourceDefinitiondefining them has the +`applyset.kubernetes.io/is-parent-type` label. + +Part of the specification used to implement +[ApplySet-based pruning in kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune). +This annotation is applied to the parent object used to track an ApplySet to indicate which +tooling manages that ApplySet. Tooling should refuse to mutate ApplySets belonging to other tools. +The value must be in the format `/`. + +### apps.kubernetes.io/pod-index (beta) {#apps-kubernetes.io-pod-index} + +Type: Label + +Example: `apps.kubernetes.io/pod-index: "0"` + +Used on: Pod + +When a StatefulSet controller creates a Pod for the StatefulSet, it sets this label on that Pod. +The value of the label is the ordinal index of the pod being created. + +See [Pod Index Label](/docs/concepts/workloads/controllers/statefulset/#pod-index-label) +in the StatefulSet topic for more details. +Note the [PodIndexLabel](/docs/reference/command-line-tools-reference/feature-gates/) +feature gate must be enabled for this label to be added to pods. + +### cluster-autoscaler.kubernetes.io/safe-to-evict + +Type: Annotation + +Example: `cluster-autoscaler.kubernetes.io/safe-to-evict: "true"` + +Used on: Pod + +When this annotation is set to `"true"`, the cluster autoscaler is allowed to evict a Pod +even if other rules would normally prevent that. +The cluster autoscaler never evicts Pods that have this annotation explicitly set to +`"false"`; you could set that on an important Pod that you want to keep running. +If this annotation is not set then the cluster autoscaler follows its Pod-level behavior. + +### config.kubernetes.io/local-config + +Type: Annotation + +Example: `config.kubernetes.io/local-config: "true"` + +Used on: All objects + +This annotation is used in manifests to mark an object as local configuration that +should not be submitted to the Kubernetes API. + +A value of `"true"` for this annotation declares that the object is only consumed by +client-side tooling and should not be submitted to the API server. + +A value of `"false"` can be used to declare that the object should be submitted to +the API server even when it would otherwise be assumed to be local. + +This annotation is part of the Kubernetes Resource Model (KRM) Functions Specification, +which is used by Kustomize and similar third-party tools. +For example, Kustomize removes objects with this annotation from its final build output. + + +### container.apparmor.security.beta.kubernetes.io/* (beta) {#container-apparmor-security-beta-kubernetes-io} + +Type: Annotation + +Example: `container.apparmor.security.beta.kubernetes.io/my-container: my-custom-profile` + +Used on: Pods + +This annotation allows you to specify the AppArmor security profile for a container within a +Kubernetes pod. +To learn more, see the [AppArmor](/docs/tutorials/security/apparmor/) tutorial. +The tutorial illustrates using AppArmor to restrict a container's abilities and access. + +The profile specified dictates the set of rules and restrictions that the containerized process must +adhere to. This helps enforce security policies and isolation for your containers. + +### internal.config.kubernetes.io/* (reserved prefix) {#internal.config.kubernetes.io-reserved-wildcard} + +Type: Annotation + +Used on: All objects + +This prefix is reserved for internal use by tools that act as orchestrators in accordance +with the Kubernetes Resource Model (KRM) Functions Specification. +Annotations with this prefix are internal to the orchestration process and are not persisted to +the manifests on the filesystem. In other words, the orchestrator tool should set these +annotations when reading files from the local filesystem and remove them when writing the output +of functions back to the filesystem. + +A KRM function **must not** modify annotations with this prefix, unless otherwise specified for a +given annotation. This enables orchestrator tools to add additional internal annotations, without +requiring changes to existing functions. + +### internal.config.kubernetes.io/path + +Type: Annotation + +Example: `internal.config.kubernetes.io/path: "relative/file/path.yaml"` + +Used on: All objects + +This annotation records the slash-delimited, OS-agnostic, relative path to the manifest file the +object was loaded from. The path is relative to a fixed location on the filesystem, determined by +the orchestrator tool. + +This annotation is part of the Kubernetes Resource Model (KRM) Functions Specification, which is +used by Kustomize and similar third-party tools. + +A KRM Function **should not** modify this annotation on input objects unless it is modifying the +referenced files. A KRM Function **may** include this annotation on objects it generates. + +### internal.config.kubernetes.io/index + +Type: Annotation + +Example: `internal.config.kubernetes.io/index: "2"` + +Used on: All objects + +This annotation records the zero-indexed position of the YAML document that contains the object +within the manifest file the object was loaded from. Note that YAML documents are separated by +three dashes (`---`) and can each contain one object. When this annotation is not specified, a +value of 0 is implied. + +This annotation is part of the Kubernetes Resource Model (KRM) Functions Specification, +which is used by Kustomize and similar third-party tools. + +A KRM Function **should not** modify this annotation on input objects unless it is modifying the +referenced files. A KRM Function **may** include this annotation on objects it generates. + +### kubernetes.io/arch + +Type: Label + +Example: `kubernetes.io/arch: "amd64"` + +Used on: Node + +The Kubelet populates this with `runtime.GOARCH` as defined by Go. +This can be handy if you are mixing ARM and x86 nodes. + +### kubernetes.io/os + +Type: Label + +Example: `kubernetes.io/os: "linux"` + +Used on: Node, Pod + +For nodes, the kubelet populates this with `runtime.GOOS` as defined by Go. This can be handy if you are +mixing operating systems in your cluster (for example: mixing Linux and Windows nodes). + +You can also set this label on a Pod. Kubernetes allows you to set any value for this label; +if you use this label, you should nevertheless set it to the Go `runtime.GOOS` string for the operating +system that this Pod actually works with. + +When the `kubernetes.io/os` label value for a Pod does not match the label value on a Node, +the kubelet on the node will not admit the Pod. However, this is not taken into account by +the kube-scheduler. Alternatively, the kubelet refuses to run a Pod where you have specified a Pod OS, if +this isn't the same as the operating system for the node where that kubelet is running. Just +look for [Pods OS](/docs/concepts/workloads/pods/#pod-os) for more details. + +### kubernetes.io/metadata.name + +Type: Label + +Example: `kubernetes.io/metadata.name: "mynamespace"` + +Used on: Namespaces + +The Kubernetes API server (part of the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}) +sets this label on all namespaces. The label value is set +to the name of the namespace. You can't change this label's value. + +This is useful if you want to target a specific namespace with a label +{{< glossary_tooltip text="selector" term_id="selector" >}}. + +### kubernetes.io/limit-ranger + +Type: Annotation + +Example: `kubernetes.io/limit-ranger: "LimitRanger plugin set: cpu, memory request for container nginx; cpu, memory limit for container nginx"` + +Used on: Pod + +Kubernetes by default doesn't provide any resource limit, that means unless you explicitly define +limits, your container can consume unlimited CPU and memory. +You can define a default request or default limit for pods. You do this by creating a LimitRange +in the relevant namespace. Pods deployed after you define a LimitRange will have these limits +applied to them. +The annotation `kubernetes.io/limit-ranger` records that resource defaults were specified for the Pod, +and they were applied successfully. +For more details, read about [LimitRanges](/docs/concepts/policy/limit-range). + +### kubernetes.io/config.hash + +Type: Annotation + +Example: `kubernetes.io/config.hash: "df7cc47f8477b6b1226d7d23a904867b"` + +Used on: Pod + +When the kubelet creates a static Pod based on a given manifest, it attaches this annotation +to the static Pod. The value of the annotation is the UID of the Pod. +Note that the kubelet also sets the `.spec.nodeName` to the current node name as if the Pod +was scheduled to the node. + +### kubernetes.io/config.mirror + +Type: Annotation + +Example: `kubernetes.io/config.mirror: "df7cc47f8477b6b1226d7d23a904867b"` + +Used on: Pod + +For a static Pod created by the kubelet on a node, a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}} +is created on the API server. The kubelet adds an annotation to indicate that this Pod is +actually a mirror Pod. The annotation value is copied from the [`kubernetes.io/config.hash`](#kubernetes-io-config-hash) +annotation, which is the UID of the Pod. + +When updating a Pod with this annotation set, the annotation cannot be changed or removed. +If a Pod doesn't have this annotation, it cannot be added during a Pod update. + +### kubernetes.io/config.source + +Type: Annotation + +Example: `kubernetes.io/config.source: "file"` + +Used on: Pod + +This annotation is added by the kubelet to indicate where the Pod comes from. +For static Pods, the annotation value could be one of `file` or `http` depending +on where the Pod manifest is located. For a Pod created on the API server and then +scheduled to the current node, the annotation value is `api`. + +### kubernetes.io/config.seen + +Type: Annotation + +Example: `kubernetes.io/config.seen: "2023-10-27T04:04:56.011314488Z"` + +Used on: Pod + +When the kubelet sees a Pod for the first time, it may add this annotation to +the Pod with a value of current timestamp in the RFC3339 format. + +### addonmanager.kubernetes.io/mode + +Type: Label + +Example: `addonmanager.kubernetes.io/mode: "Reconcile"` + +Used on: All objects + +To specify how an add-on should be managed, you can use the `addonmanager.kubernetes.io/mode` label. +This label can have one of three values: `Reconcile`, `EnsureExists`, or `Ignore`. + +- `Reconcile`: Addon resources will be periodically reconciled with the expected state. + If there are any differences, the add-on manager will recreate, reconfigure or delete + the resources as needed. This is the default mode if no label is specified. +- `EnsureExists`: Addon resources will be checked for existence only but will not be modified + after creation. The add-on manager will create or re-create the resources when there is + no instance of the resource with that name. +- `Ignore`: Addon resources will be ignored. This mode is useful for add-ons that are not + compatible with the add-on manager or that are managed by another controller. + +For more details, see [Addon-manager](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/addon-manager/README.md). + +### beta.kubernetes.io/arch (deprecated) + +Type: Label + +This label has been deprecated. Please use [`kubernetes.io/arch`](#kubernetes-io-arch) instead. + +### beta.kubernetes.io/os (deprecated) + +Type: Label + +This label has been deprecated. Please use [`kubernetes.io/os`](#kubernetes-io-os) instead. + +### kube-aggregator.kubernetes.io/automanaged {#kube-aggregator-kubernetesio-automanaged} + +Type: Label + +Example: `kube-aggregator.kubernetes.io/automanaged: "onstart"` + +Used on: APIService + +The `kube-apiserver` sets this label on any APIService object that the API server +has created automatically. The label marks how the control plane should manage that +APIService. You should not add, modify, or remove this label by yourself. + +{{< note >}} +Automanaged APIService objects are deleted by kube-apiserver when it has no built-in +or custom resource API corresponding to the API group/version of the APIService. +{{< /note >}} + +There are two possible values: + +- `onstart`: The APIService should be reconciled when an API server starts up, but not otherwise. +- `true`: The API server should reconcile this APIService continuously. + +### service.alpha.kubernetes.io/tolerate-unready-endpoints (deprecated) + +Type: Annotation + +Used on: StatefulSet + +This annotation on a Service denotes if the Endpoints controller should go ahead and create +Endpoints for unready Pods. Endpoints of these Services retain their DNS records and continue +receiving traffic for the Service from the moment the kubelet starts all containers in the pod +and marks it _Running_, til the kubelet stops all containers and deletes the pod from +the API server. + +### kubernetes.io/hostname {#kubernetesiohostname} + +Type: Label + +Example: `kubernetes.io/hostname: "ip-172-20-114-199.ec2.internal"` + +Used on: Node + +The Kubelet populates this label with the hostname of the node. Note that the hostname +can be changed from the "actual" hostname by passing the `--hostname-override` flag to +the `kubelet`. + +This label is also used as part of the topology hierarchy. +See [topology.kubernetes.io/zone](#topologykubernetesiozone) for more information. + +### kubernetes.io/change-cause {#change-cause} + +Type: Annotation + +Example: `kubernetes.io/change-cause: "kubectl edit --record deployment foo"` + +Used on: All Objects + +This annotation is a best guess at why something was changed. + +It is populated when adding `--record` to a `kubectl` command that may change an object. + +### kubernetes.io/description {#description} + +Type: Annotation + +Example: `kubernetes.io/description: "Description of K8s object."` + +Used on: All Objects + +This annotation is used for describing specific behaviour of given object. + +### kubernetes.io/enforce-mountable-secrets {#enforce-mountable-secrets} + +Type: Annotation + +Example: `kubernetes.io/enforce-mountable-secrets: "true"` + +Used on: ServiceAccount + +The value for this annotation must be **true** to take effect. +When you set this annotation to "true", Kubernetes enforces the following rules for +Pods running as this ServiceAccount: + +1. Secrets mounted as volumes must be listed in the ServiceAccount's `secrets` field. +1. Secrets referenced in `envFrom` for containers (including sidecar containers and init containers) + must also be listed in the ServiceAccount's secrets field. + If any container in a Pod references a Secret not listed in the ServiceAccount's `secrets` field + (and even if the reference is marked as `optional`), then the Pod will fail to start, + and an error indicating the non-compliant secret reference will be generated. +1. Secrets referenced in a Pod's `imagePullSecrets` must be present in the + ServiceAccount's `imagePullSecrets` field, the Pod will fail to start, + and an error indicating the non-compliant image pull secret reference will be generated. + +When you create or update a Pod, these rules are checked. If a Pod doesn't follow them, it won't start and you'll see an error message. +If a Pod is already running and you change the `kubernetes.io/enforce-mountable-secrets` annotation +to true, or you edit the associated ServiceAccount to remove the reference to a Secret +that the Pod is already using, the Pod continues to run. + +### node.kubernetes.io/exclude-from-external-load-balancers + +Type: Label + +Example: `node.kubernetes.io/exclude-from-external-load-balancers` + +Used on: Node + +Kubernetes automatically enables the `ServiceNodeExclusion` feature gate on +the clusters it creates. With this feature gate enabled on a cluster, +you can add labels to particular worker nodes to exclude them from the list of backend servers. +The following command can be used to exclude a worker node from the list of backend servers in a +backend set: + +```shell +kubectl label nodes node.kubernetes.io/exclude-from-external-load-balancers=true +``` + +### controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} + +Type: Annotation + +Example: `controller.kubernetes.io/pod-deletion-cost: "10"` + +Used on: Pod + +This annotation is used to set [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost) +which allows users to influence ReplicaSet downscaling order. +The annotation value parses into an `int32` type. + +### cluster-autoscaler.kubernetes.io/enable-ds-eviction + +Type: Annotation + +Example: `cluster-autoscaler.kubernetes.io/enable-ds-eviction: "true"` + +Used on: Pod + +This annotation controls whether a DaemonSet pod should be evicted by a ClusterAutoscaler. +This annotation needs to be specified on DaemonSet pods in a DaemonSet manifest. +When this annotation is set to `"true"`, the ClusterAutoscaler is allowed to evict +a DaemonSet Pod, even if other rules would normally prevent that. +To disallow the ClusterAutoscaler from evicting DaemonSet pods, +you can set this annotation to `"false"` for important DaemonSet pods. +If this annotation is not set, then the ClusterAutoscaler follows its overall behavior +(i.e evict the DaemonSets based on its configuration). + +{{< note >}} +This annotation only impacts DaemonSet Pods. +{{< /note >}} + +### kubernetes.io/ingress-bandwidth + +Type: Annotation + +Example: `kubernetes.io/ingress-bandwidth: 10M` + +Used on: Pod + +You can apply quality-of-service traffic shaping to a pod and effectively limit its available +bandwidth. Ingress traffic to a Pod is handled by shaping queued packets to effectively +handle data. To limit the bandwidth on a Pod, write an object definition JSON file and specify +the data traffic speed using `kubernetes.io/ingress-bandwidth` annotation. The unit used for +specifying ingress rate is bits per second, as a +[Quantity](/docs/reference/kubernetes-api/common-definitions/quantity/). +For example, `10M` means 10 megabits per second. + +{{< note >}} +Ingress traffic shaping annotation is an experimental feature. +If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI +configuration file (default `/etc/cni/net.d`) and ensure that the binary is included in your CNI +bin dir (default `/opt/cni/bin`). +{{< /note >}} + +### kubernetes.io/egress-bandwidth + +Type: Annotation + +Example: `kubernetes.io/egress-bandwidth: 10M` + +Used on: Pod + +Egress traffic from a Pod is handled by policing, which simply drops packets in excess of the +configured rate. The limits you place on a Pod do not affect the bandwidth of other Pods. +To limit the bandwidth on a Pod, write an object definition JSON file and specify the data traffic +speed using `kubernetes.io/egress-bandwidth` annotation. The unit used for specifying egress rate +is bits per second, as a [Quantity](/docs/reference/kubernetes-api/common-definitions/quantity/). +For example, `10M` means 10 megabits per second. + +{{< note >}} +Egress traffic shaping annotation is an experimental feature. +If you want to enable traffic shaping support, you must add the `bandwidth` plugin to your CNI +configuration file (default `/etc/cni/net.d`) and ensure that the binary is included in your CNI +bin dir (default `/opt/cni/bin`). +{{< /note >}} + +### beta.kubernetes.io/instance-type (deprecated) + +Type: Label + +{{< note >}} +Starting in v1.17, this label is deprecated in favor of +[node.kubernetes.io/instance-type](#nodekubernetesioinstance-type). +{{< /note >}} + +### node.kubernetes.io/instance-type {#nodekubernetesioinstance-type} + +Type: Label + +Example: `node.kubernetes.io/instance-type: "m3.medium"` + +Used on: Node + +The Kubelet populates this with the instance type as defined by the cloud provider. +This will be set only if you are using a cloud provider. This setting is handy +if you want to target certain workloads to certain instance types, but typically you want +to rely on the Kubernetes scheduler to perform resource-based scheduling. +You should aim to schedule based on properties rather than on instance types +(for example: require a GPU, instead of requiring a `g2.2xlarge`). + +### failure-domain.beta.kubernetes.io/region (deprecated) {#failure-domainbetakubernetesioregion} + +Type: Label + +{{< note >}} +Starting in v1.17, this label is deprecated in favor of +[topology.kubernetes.io/region](#topologykubernetesioregion). +{{< /note >}} + +### failure-domain.beta.kubernetes.io/zone (deprecated) {#failure-domainbetakubernetesiozone} + +Type: Label + +{{< note >}} +Starting in v1.17, this label is deprecated in favor of +[topology.kubernetes.io/zone](#topologykubernetesiozone). +{{< /note >}} + +### pv.kubernetes.io/bind-completed {#pv-kubernetesiobind-completed} + +Type: Annotation + +Example: `pv.kubernetes.io/bind-completed: "yes"` + +Used on: PersistentVolumeClaim + +When this annotation is set on a PersistentVolumeClaim (PVC), that indicates that the lifecycle +of the PVC has passed through initial binding setup. When present, that information changes +how the control plane interprets the state of PVC objects. +The value of this annotation does not matter to Kubernetes. + +### pv.kubernetes.io/bound-by-controller {#pv-kubernetesioboundby-controller} + +Type: Annotation + +Example: `pv.kubernetes.io/bound-by-controller: "yes"` + +Used on: PersistentVolume, PersistentVolumeClaim + +If this annotation is set on a PersistentVolume or PersistentVolumeClaim, it indicates that a +storage binding (PersistentVolume → PersistentVolumeClaim, or PersistentVolumeClaim → PersistentVolume) +was installed by the {{< glossary_tooltip text="controller" term_id="controller" >}}. +If the annotation isn't set, and there is a storage binding in place, the absence of that +annotation means that the binding was done manually. +The value of this annotation does not matter. + +### pv.kubernetes.io/provisioned-by {#pv-kubernetesiodynamically-provisioned} + +Type: Annotation + +Example: `pv.kubernetes.io/provisioned-by: "kubernetes.io/rbd"` + +Used on: PersistentVolume + +This annotation is added to a PersistentVolume(PV) that has been dynamically provisioned by Kubernetes. +Its value is the name of volume plugin that created the volume. It serves both users (to show where a PV +comes from) and Kubernetes (to recognize dynamically provisioned PVs in its decisions). + +### pv.kubernetes.io/migrated-to {#pv-kubernetesio-migratedto} + +Type: Annotation + +Example: `pv.kubernetes.io/migrated-to: pd.csi.storage.gke.io` + +Used on: PersistentVolume, PersistentVolumeClaim + +It is added to a PersistentVolume(PV) and PersistentVolumeClaim(PVC) that is supposed to be +dynamically provisioned/deleted by its corresponding CSI driver through the `CSIMigration` feature gate. +When this annotation is set, the Kubernetes components will "stand-down" and the +`external-provisioner` will act on the objects. + +### statefulset.kubernetes.io/pod-name {#statefulsetkubernetesiopod-name} + +Type: Label + +Example: `statefulset.kubernetes.io/pod-name: "mystatefulset-7"` + +Used on: Pod + +When a StatefulSet controller creates a Pod for the StatefulSet, the control plane +sets this label on that Pod. The value of the label is the name of the Pod being created. + +See [Pod Name Label](/docs/concepts/workloads/controllers/statefulset/#pod-name-label) +in the StatefulSet topic for more details. + +### scheduler.alpha.kubernetes.io/node-selector {#schedulerkubernetesnode-selector} + +Type: Annotation + +Example: `scheduler.alpha.kubernetes.io/node-selector: "name-of-node-selector"` + +Used on: Namespace + +The [PodNodeSelector](/docs/reference/access-authn-authz/admission-controllers/#podnodeselector) +uses this annotation key to assign node selectors to pods in namespaces. + +### topology.kubernetes.io/region {#topologykubernetesioregion} + +Type: Label + +Example: `topology.kubernetes.io/region: "us-east-1"` + +Used on: Node, PersistentVolume + +See [topology.kubernetes.io/zone](#topologykubernetesiozone). + +### topology.kubernetes.io/zone {#topologykubernetesiozone} + +Type: Label + +Example: `topology.kubernetes.io/zone: "us-east-1c"` + +Used on: Node, PersistentVolume + +**On Node**: The `kubelet` or the external `cloud-controller-manager` populates this +with the information from the cloud provider. This will be set only if you are using +a cloud provider. However, you can consider setting this on nodes if it makes sense +in your topology. + +**On PersistentVolume**: topology-aware volume provisioners will automatically set +node affinity constraints on a `PersistentVolume`. + +A zone represents a logical failure domain. It is common for Kubernetes clusters to +span multiple zones for increased availability. While the exact definition of a zone +is left to infrastructure implementations, common properties of a zone include +very low network latency within a zone, no-cost network traffic within a zone, and +failure independence from other zones. +For example, nodes within a zone might share a network switch, but nodes in different +zones should not. + +A region represents a larger domain, made up of one or more zones. +It is uncommon for Kubernetes clusters to span multiple regions, +While the exact definition of a zone or region is left to infrastructure implementations, +common properties of a region include higher network latency between them than within them, +non-zero cost for network traffic between them, and failure independence from other zones or regions. +For example, nodes within a region might share power infrastructure (e.g. a UPS or generator), +but nodes in different regions typically would not. + +Kubernetes makes a few assumptions about the structure of zones and regions: + +1. regions and zones are hierarchical: zones are strict subsets of regions and + no zone can be in 2 regions +2. zone names are unique across regions; for example region "africa-east-1" might be comprised + of zones "africa-east-1a" and "africa-east-1b" + +It should be safe to assume that topology labels do not change. +Even though labels are strictly mutable, consumers of them can assume that a given node +is not going to be moved between zones without being destroyed and recreated. + +Kubernetes can use this information in various ways. +For example, the scheduler automatically tries to spread the Pods in a ReplicaSet across nodes +in a single-zone cluster (to reduce the impact of node failures, see +[kubernetes.io/hostname](#kubernetesiohostname)). +With multiple-zone clusters, this spreading behavior also applies to zones (to reduce the impact of zone failures). +This is achieved via _SelectorSpreadPriority_. + +_SelectorSpreadPriority_ is a best effort placement. If the zones in your cluster are +heterogeneous (for example: different numbers of nodes, different types of nodes, or different pod +resource requirements), this placement might prevent equal spreading of your Pods across zones. +If desired, you can use homogeneous zones (same number and types of nodes) to reduce the probability +of unequal spreading. + +The scheduler (through the _VolumeZonePredicate_ predicate) also will ensure that Pods, +that claim a given volume, are only placed into the same zone as that volume. +Volumes cannot be attached across zones. + +If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, +you should consider adding the labels manually (or adding support for `PersistentVolumeLabel`). +With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. +If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all. + +### volume.beta.kubernetes.io/storage-provisioner (deprecated) + +Type: Annotation + +Example: `volume.beta.kubernetes.io/storage-provisioner: "k8s.io/minikube-hostpath"` + +Used on: PersistentVolumeClaim + +This annotation has been deprecated since v1.23. +See [volume.kubernetes.io/storage-provisioner](#volume-kubernetes-io-storage-provisioner). + +### volume.beta.kubernetes.io/storage-class (deprecated) + +Type: Annotation + +Example: `volume.beta.kubernetes.io/storage-class: "example-class"` + +Used on: PersistentVolume, PersistentVolumeClaim + +This annotation can be used for PersistentVolume(PV) or PersistentVolumeClaim(PVC) +to specify the name of [StorageClass](/docs/concepts/storage/storage-classes/). +When both the `storageClassName` attribute and the `volume.beta.kubernetes.io/storage-class` +annotation are specified, the annotation `volume.beta.kubernetes.io/storage-class` +takes precedence over the `storageClassName` attribute. + +This annotation has been deprecated. Instead, set the +[`storageClassName` field](/docs/concepts/storage/persistent-volumes/#class) +for the PersistentVolumeClaim or PersistentVolume. + +### volume.beta.kubernetes.io/mount-options (deprecated) {#mount-options} + +Type: Annotation + +Example : `volume.beta.kubernetes.io/mount-options: "ro,soft"` + +Used on: PersistentVolume + +A Kubernetes administrator can specify additional +[mount options](/docs/concepts/storage/persistent-volumes/#mount-options) +for when a PersistentVolume is mounted on a node. + +### volume.kubernetes.io/storage-provisioner {#volume-kubernetes-io-storage-provisioner} + +Type: Annotation + +Used on: PersistentVolumeClaim + +This annotation is added to a PVC that is supposed to be dynamically provisioned. +Its value is the name of a volume plugin that is supposed to provision a volume +for this PVC. + +### volume.kubernetes.io/selected-node + +Type: Annotation + +Used on: PersistentVolumeClaim + +This annotation is added to a PVC that is triggered by a scheduler to be +dynamically provisioned. Its value is the name of the selected node. + +### volumes.kubernetes.io/controller-managed-attach-detach + +Type: Annotation + +Used on: Node + +If a node has the annotation `volumes.kubernetes.io/controller-managed-attach-detach`, +its storage attach and detach operations are being managed by the _volume attach/detach_ +{{< glossary_tooltip text="controller" term_id="controller" >}}. + +The value of the annotation isn't important. + +### node.kubernetes.io/windows-build {#nodekubernetesiowindows-build} + +Type: Label + +Example: `node.kubernetes.io/windows-build: "10.0.17763"` + +Used on: Node + +When the kubelet is running on Microsoft Windows, it automatically labels its Node +to record the version of Windows Server in use. + +The label's value is in the format "MajorVersion.MinorVersion.BuildNumber". + +### service.kubernetes.io/headless {#servicekubernetesioheadless} + +Type: Label + +Example: `service.kubernetes.io/headless: ""` + +Used on: Service + +The control plane adds this label to an Endpoints object when the owning Service is headless. + +### service.kubernetes.io/topology-aware-hints (deprecated) {#servicekubernetesiotopology-aware-hints} + +Example: `service.kubernetes.io/topology-aware-hints: "Auto"` + +Used on: Service + +This annotation was used for enabling _topology aware hints_ on Services. Topology aware +hints have since been renamed: the concept is now called +[topology aware routing](/docs/concepts/services-networking/topology-aware-routing/). +Setting the annotation to `Auto`, on a Service, configured the Kubernetes control plane to +add topology hints on EndpointSlices associated with that Service. You can also explicitly +set the annotation to `Disabled`. + +If you are running a version of Kubernetes older than {{< skew currentVersion >}}, +check the documentation for that Kubernetes version to see how topology aware routing +works in that release. + +There are no other valid values for this annotation. If you don't want topology aware hints +for a Service, don't add this annotation. + +### service.kubernetes.io/topology-mode + +Type: Annotation + +Example: `service.kubernetes.io/topology-mode: Auto` + +Used on: Service + +This annotation provides a way to define how Services handle network topology; +for example, you can configure a Service so that Kubernetes prefers keeping traffic between +a client and server within a single topology zone. +In some cases this can help reduce costs or improve network performance. + +See [Topology Aware Routing](/docs/concepts/services-networking/topology-aware-routing/) +for more details. + +### kubernetes.io/service-name {#kubernetesioservice-name} + +Type: Label + +Example: `kubernetes.io/service-name: "my-website"` + +Used on: EndpointSlice + +Kubernetes associates [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) with +[Services](/docs/concepts/services-networking/service/) using this label. + +This label records the {{< glossary_tooltip term_id="name" text="name">}} of the +Service that the EndpointSlice is backing. All EndpointSlices should have this label set to +the name of their associated Service. + +### kubernetes.io/service-account.name + +Type: Annotation + +Example: `kubernetes.io/service-account.name: "sa-name"` + +Used on: Secret + +This annotation records the {{< glossary_tooltip term_id="name" text="name">}} of the +ServiceAccount that the token (stored in the Secret of type `kubernetes.io/service-account-token`) +represents. + +### kubernetes.io/service-account.uid + +Type: Annotation + +Example: `kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da` + +Used on: Secret + +This annotation records the {{< glossary_tooltip term_id="uid" text="unique ID" >}} of the +ServiceAccount that the token (stored in the Secret of type `kubernetes.io/service-account-token`) +represents. + +### kubernetes.io/legacy-token-last-used + +Type: Label + +Example: `kubernetes.io/legacy-token-last-used: 2022-10-24` + +Used on: Secret + +The control plane only adds this label to Secrets that have the type +`kubernetes.io/service-account-token`. +The value of this label records the date (ISO 8601 format, UTC time zone) when the control plane +last saw a request where the client authenticated using the service account token. + +If a legacy token was last used before the cluster gained the feature (added in Kubernetes v1.26), +then the label isn't set. + +### kubernetes.io/legacy-token-invalid-since + +Type: Label + +Example: `kubernetes.io/legacy-token-invalid-since: 2023-10-27` + +Used on: Secret + +The control plane automatically adds this label to auto-generated Secrets that +have the type `kubernetes.io/service-account-token`, provided that you have the +`LegacyServiceAccountTokenCleanUp` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +enabled. Kubernetes {{< skew currentVersion >}} enables that behavior by default. +This label marks the Secret-based token as invalid for authentication. The value +of this label records the date (ISO 8601 format, UTC time zone) when the control +plane detects that the auto-generated Secret has not been used for a specified +duration (defaults to one year). + +### endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by} + +Type: Label + +Example: `endpointslice.kubernetes.io/managed-by: "controller"` + +Used on: EndpointSlices + +The label is used to indicate the controller or entity that manages the EndpointSlice. This label +aims to enable different EndpointSlice objects to be managed by different controllers or entities +within the same cluster. + +### endpointslice.kubernetes.io/skip-mirror {#endpointslicekubernetesioskip-mirror} + +Type: Label + +Example: `endpointslice.kubernetes.io/skip-mirror: "true"` + +Used on: Endpoints + +The label can be set to `"true"` on an Endpoints resource to indicate that the +EndpointSliceMirroring controller should not mirror this resource with EndpointSlices. + +### service.kubernetes.io/service-proxy-name {#servicekubernetesioservice-proxy-name} + +Type: Label + +Example: `service.kubernetes.io/service-proxy-name: "foo-bar"` + +Used on: Service + +The kube-proxy has this label for custom proxy, which delegates service control to custom proxy. + +### experimental.windows.kubernetes.io/isolation-type (deprecated) {#experimental-windows-kubernetes-io-isolation-type} + +Type: Annotation + +Example: `experimental.windows.kubernetes.io/isolation-type: "hyperv"` + +Used on: Pod + +The annotation is used to run Windows containers with Hyper-V isolation. + +{{< note >}} +Starting from v1.20, this annotation is deprecated. +Experimental Hyper-V support was removed in 1.21. +{{< /note >}} + +### ingressclass.kubernetes.io/is-default-class + +Type: Annotation + +Example: `ingressclass.kubernetes.io/is-default-class: "true"` + +Used on: IngressClass + +When a IngressClass resource has this annotation set to `"true"`, new Ingress resource +without a class specified will be assigned this default class. + +### kubernetes.io/ingress.class (deprecated) + +Type: Annotation + +Used on: Ingress + +{{< note >}} +Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. +{{< /note >}} + +### storageclass.kubernetes.io/is-default-class + +Type: Annotation + +Example: `storageclass.kubernetes.io/is-default-class: "true"` + +Used on: StorageClass + +When a single StorageClass resource has this annotation set to `"true"`, new PersistentVolumeClaim +resource without a class specified will be assigned this default class. + +### alpha.kubernetes.io/provided-node-ip (alpha) {#alpha-kubernetes-io-provided-node-ip} + +Type: Annotation + +Example: `alpha.kubernetes.io/provided-node-ip: "10.0.0.1"` + +Used on: Node + +The kubelet can set this annotation on a Node to denote its configured IPv4 and/or IPv6 address. + +When kubelet is started with the `--cloud-provider` flag set to any value (includes both external +and legacy in-tree cloud providers), it sets this annotation on the Node to denote an IP address +set from the command line flag (`--node-ip`). This IP is verified with the cloud provider as valid +by the cloud-controller-manager. + +### batch.kubernetes.io/job-completion-index + +Type: Annotation, Label + +Example: `batch.kubernetes.io/job-completion-index: "3"` + +Used on: Pod + +The Job controller in the kube-controller-manager sets this as a label and annotation for Pods +created with Indexed [completion mode](/docs/concepts/workloads/controllers/job/#completion-mode). + +Note the [PodIndexLabel](/docs/reference/command-line-tools-reference/feature-gates/) +feature gate must be enabled for this to be added as a pod **label**, +otherwise it will just be an annotation. + +### batch.kubernetes.io/cronjob-scheduled-timestamp + +Type: Annotation + +Example: `batch.kubernetes.io/cronjob-scheduled-timestamp: "2016-05-19T03:00:00-07:00"` + +Used on: Jobs and Pods controlled by CronJobs + +This annotation is used to record the original (expected) creation timestamp for a Job, +when that Job is part of a CronJob. +The control plane sets the value to that timestamp in RFC3339 format. If the Job belongs to a CronJob +with a timezone specified, then the timestamp is in that timezone. Otherwise, the timestamp is in controller-manager's local time. + +### kubectl.kubernetes.io/default-container + +Type: Annotation + +Example: `kubectl.kubernetes.io/default-container: "front-end-app"` + +The value of the annotation is the container name that is default for this Pod. +For example, `kubectl logs` or `kubectl exec` without `-c` or `--container` flag +will use this default container. + +### kubectl.kubernetes.io/default-logs-container (deprecated) + +Type: Annotation + +Example: `kubectl.kubernetes.io/default-logs-container: "front-end-app"` + +The value of the annotation is the container name that is the default logging container for this +Pod. For example, `kubectl logs` without `-c` or `--container` flag will use this default +container. + +{{< note >}} +This annotation is deprecated. You should use the +[`kubectl.kubernetes.io/default-container`](#kubectl-kubernetes-io-default-container) +annotation instead. Kubernetes versions 1.25 and newer ignore this annotation. +{{< /note >}} + +### kubectl.kubernetes.io/last-applied-configuration + +Type: Annotation + +Example: _see following snippet_ +```yaml + kubectl.kubernetes.io/last-applied-configuration: > + {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"name":"example","namespace":"default"},"spec":{"selector":{"matchLabels":{"app.kubernetes.io/name":foo}},"template":{"metadata":{"labels":{"app.kubernetes.io/name":"foo"}},"spec":{"containers":[{"image":"container-registry.example/foo-bar:1.42","name":"foo-bar","ports":[{"containerPort":42}]}]}}}} +``` + +Used on: all objects + +The kubectl command line tool uses this annotation as a legacy mechanism +to track changes. That mechanism has been superseded by +[Server-side apply](/docs/reference/using-api/server-side-apply/). + +### endpoints.kubernetes.io/over-capacity + +Type: Annotation + +Example: `endpoints.kubernetes.io/over-capacity:truncated` + +Used on: Endpoints + +The {{< glossary_tooltip text="control plane" term_id="control-plane" >}} adds this annotation to +an [Endpoints](/docs/concepts/services-networking/service/#endpoints) object if the associated +{{< glossary_tooltip term_id="service" >}} has more than 1000 backing endpoints. +The annotation indicates that the Endpoints object is over capacity and the number of endpoints +has been truncated to 1000. + +If the number of backend endpoints falls below 1000, the control plane removes this annotation. + +### control-plane.alpha.kubernetes.io/leader (deprecated) {#control-plane-alpha-kubernetes-io-leader} + +Type: Annotation + +Example: `control-plane.alpha.kubernetes.io/leader={"holderIdentity":"controller-0","leaseDurationSeconds":15,"acquireTime":"2023-01-19T13:12:57Z","renewTime":"2023-01-19T13:13:54Z","leaderTransitions":1}` + +Used on: Endpoints + +The {{< glossary_tooltip text="control plane" term_id="control-plane" >}} previously set annotation on +an [Endpoints](/docs/concepts/services-networking/service/#endpoints) object. This annotation provided +the following detail: + +- Who is the current leader. +- The time when the current leadership was acquired. +- The duration of the lease (of the leadership) in seconds. +- The time the current lease (the current leadership) should be renewed. +- The number of leadership transitions that happened in the past. + +Kubernetes now uses [Leases](/docs/concepts/architecture/leases/) to +manage leader assignment for the Kubernetes control plane. + +### batch.kubernetes.io/job-tracking (deprecated) {#batch-kubernetes-io-job-tracking} + +Type: Annotation + +Example: `batch.kubernetes.io/job-tracking: ""` + +Used on: Jobs + +The presence of this annotation on a Job used to indicate that the control plane is +[tracking the Job status using finalizers](/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers). +Adding or removing this annotation no longer has an effect (Kubernetes v1.27 and later) +All Jobs are tracked with finalizers. + +### job-name (deprecated) {#job-name} + +Type: Label + +Example: `job-name: "pi"` + +Used on: Jobs and Pods controlled by Jobs + +{{< note >}} +Starting from Kubernetes 1.27, this label is deprecated. +Kubernetes 1.27 and newer ignore this label and use the prefixed `job-name` label. +{{< /note >}} + +### controller-uid (deprecated) {#controller-uid} + +Type: Label + +Example: `controller-uid: "$UID"` + +Used on: Jobs and Pods controlled by Jobs + +{{< note >}} +Starting from Kubernetes 1.27, this label is deprecated. +Kubernetes 1.27 and newer ignore this label and use the prefixed `controller-uid` label. +{{< /note >}} + +### batch.kubernetes.io/job-name {#batchkubernetesio-job-name} + +Type: Label + +Example: `batch.kubernetes.io/job-name: "pi"` + +Used on: Jobs and Pods controlled by Jobs + +This label is used as a user-friendly way to get Pods corresponding to a Job. +The `job-name` comes from the `name` of the Job and allows for an easy way to +get Pods corresponding to the Job. + +### batch.kubernetes.io/controller-uid {#batchkubernetesio-controller-uid} + +Type: Label + +Example: `batch.kubernetes.io/controller-uid: "$UID"` + +Used on: Jobs and Pods controlled by Jobs + +This label is used as a programmatic way to get all Pods corresponding to a Job. +The `controller-uid` is a unique identifier that gets set in the `selector` field so the Job +controller can get all the corresponding Pods. + +### scheduler.alpha.kubernetes.io/defaultTolerations {#scheduleralphakubernetesio-defaulttolerations} + +Type: Annotation + +Example: `scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Equal", "value": "value1", "effect": "NoSchedule", "key": "dedicated-node"}]'` + +Used on: Namespace + +This annotation requires the [PodTolerationRestriction](/docs/reference/access-authn-authz/admission-controllers/#podtolerationrestriction) +admission controller to be enabled. This annotation key allows assigning tolerations to a +namespace and any new pods created in this namespace would get these tolerations added. + +### scheduler.alpha.kubernetes.io/tolerationsWhitelist {#schedulerkubernetestolerations-whitelist} + +Type: Annotation + +Example: `scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'` + +Used on: Namespace + +This annotation is only useful when the (Alpha) +[PodTolerationRestriction](/docs/reference/access-authn-authz/admission-controllers/#podtolerationrestriction) +admission controller is enabled. The annotation value is a JSON document that defines a list of +allowed tolerations for the namespace it annotates. When you create a Pod or modify its +tolerations, the API server checks the tolerations to see if they are mentioned in the allow list. +The pod is admitted only if the check succeeds. + +### scheduler.alpha.kubernetes.io/preferAvoidPods (deprecated) {#scheduleralphakubernetesio-preferavoidpods} + +Type: Annotation + +Used on: Node + +This annotation requires the [NodePreferAvoidPods scheduling plugin](/docs/reference/scheduling/config/#scheduling-plugins) +to be enabled. The plugin is deprecated since Kubernetes 1.22. +Use [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) instead. + +### node.kubernetes.io/not-ready + +Type: Taint + +Example: `node.kubernetes.io/not-ready: "NoExecute"` + +Used on: Node + +The Node controller detects whether a Node is ready by monitoring its health +and adds or removes this taint accordingly. + +### node.kubernetes.io/unreachable + +Type: Taint + +Example: `node.kubernetes.io/unreachable: "NoExecute"` + +Used on: Node + +The Node controller adds the taint to a Node corresponding to the +[NodeCondition](/docs/concepts/architecture/nodes/#condition) `Ready` being `Unknown`. + +### node.kubernetes.io/unschedulable + +Type: Taint + +Example: `node.kubernetes.io/unschedulable: "NoSchedule"` + +Used on: Node + +The taint will be added to a node when initializing the node to avoid race condition. + +### node.kubernetes.io/memory-pressure + +Type: Taint + +Example: `node.kubernetes.io/memory-pressure: "NoSchedule"` + +Used on: Node + +The kubelet detects memory pressure based on `memory.available` and `allocatableMemory.available` +observed on a Node. The observed values are then compared to the corresponding thresholds that can +be set on the kubelet to determine if the Node condition and taint should be added/removed. + +### node.kubernetes.io/disk-pressure + +Type: Taint + +Example: `node.kubernetes.io/disk-pressure :"NoSchedule"` + +Used on: Node + +The kubelet detects disk pressure based on `imagefs.available`, `imagefs.inodesFree`, +`nodefs.available` and `nodefs.inodesFree`(Linux only) observed on a Node. +The observed values are then compared to the corresponding thresholds that can be set on the +kubelet to determine if the Node condition and taint should be added/removed. + +### node.kubernetes.io/network-unavailable + +Type: Taint + +Example: `node.kubernetes.io/network-unavailable: "NoSchedule"` + +Used on: Node + +This is initially set by the kubelet when the cloud provider used indicates a requirement for +additional network configuration. Only when the route on the cloud is configured properly will the +taint be removed by the cloud provider. + +### node.kubernetes.io/pid-pressure + +Type: Taint + +Example: `node.kubernetes.io/pid-pressure: "NoSchedule"` + +Used on: Node + +The kubelet checks D-value of the size of `/proc/sys/kernel/pid_max` and the PIDs consumed by +Kubernetes on a node to get the number of available PIDs that referred to as the `pid.available` +metric. The metric is then compared to the corresponding threshold that can be set on the kubelet +to determine if the node condition and taint should be added/removed. + +### node.kubernetes.io/out-of-service + +Type: Taint + +Example: `node.kubernetes.io/out-of-service:NoExecute` + +Used on: Node + +A user can manually add the taint to a Node marking it out-of-service. +If the `NodeOutOfServiceVolumeDetach` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +is enabled on `kube-controller-manager`, and a Node is marked out-of-service with this taint, +the Pods on the node will be forcefully deleted if there are no matching tolerations on it and +volume detach operations for the Pods terminating on the node will happen immediately. +This allows the Pods on the out-of-service node to recover quickly on a different node. + +{{< caution >}} +Refer to [Non-graceful node shutdown](/docs/concepts/architecture/nodes/#non-graceful-node-shutdown) +for further details about when and how to use this taint. +{{< /caution >}} + +### node.cloudprovider.kubernetes.io/uninitialized + +Type: Taint + +Example: `node.cloudprovider.kubernetes.io/uninitialized: "NoSchedule"` + +Used on: Node + +Sets this taint on a Node to mark it as unusable, when kubelet is started with the "external" +cloud provider, until a controller from the cloud-controller-manager initializes this Node, and +then removes the taint. + +### node.cloudprovider.kubernetes.io/shutdown + +Type: Taint + +Example: `node.cloudprovider.kubernetes.io/shutdown: "NoSchedule"` + +Used on: Node + +If a Node is in a cloud provider specified shutdown state, the Node gets tainted accordingly +with `node.cloudprovider.kubernetes.io/shutdown` and the taint effect of `NoSchedule`. + +### feature.node.kubernetes.io/* + +Type: Label + +Example: `feature.node.kubernetes.io/network-sriov.capable: "true"` + +Used on: Node + +These labels are used by the Node Feature Discovery (NFD) component to advertise +features on a node. All built-in labels use the `feature.node.kubernetes.io` label +namespace and have the format `feature.node.kubernetes.io/: "true"`. +NFD has many extension points for creating vendor and application-specific labels. +For details, see the [customization guide](https://kubernetes-sigs.github.io/node-feature-discovery/v0.12/usage/customization-guide). + +### nfd.node.kubernetes.io/master.version + +Type: Annotation + +Example: `nfd.node.kubernetes.io/master.version: "v0.6.0"` + +Used on: Node + +For node(s) where the Node Feature Discovery (NFD) +[master](https://kubernetes-sigs.github.io/node-feature-discovery/stable/usage/nfd-master.html) +is scheduled, this annotation records the version of the NFD master. +It is used for informative use only. + +### nfd.node.kubernetes.io/worker.version + +Type: Annotation + +Example: `nfd.node.kubernetes.io/worker.version: "v0.4.0"` + +Used on: Nodes + +This annotation records the version for a Node Feature Discovery's +[worker](https://kubernetes-sigs.github.io/node-feature-discovery/stable/usage/nfd-worker.html) +if there is one running on a node. It's used for informative use only. + +### nfd.node.kubernetes.io/feature-labels + +Type: Annotation + +Example: `nfd.node.kubernetes.io/feature-labels: "cpu-cpuid.ADX,cpu-cpuid.AESNI,cpu-hardware_multithreading,kernel-version.full"` + +Used on: Nodes + +This annotation records a comma-separated list of node feature labels managed by +[Node Feature Discovery](https://kubernetes-sigs.github.io/node-feature-discovery/) (NFD). +NFD uses this for an internal mechanism. You should not edit this annotation yourself. + +### nfd.node.kubernetes.io/extended-resources + +Type: Annotation + +Example: `nfd.node.kubernetes.io/extended-resources: "accelerator.acme.example/q500,example.com/coprocessor-fx5"` + +Used on: Nodes + +This annotation records a comma-separated list of +[extended resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources) +managed by [Node Feature Discovery](https://kubernetes-sigs.github.io/node-feature-discovery/) (NFD). +NFD uses this for an internal mechanism. You should not edit this annotation yourself. + +### nfd.node.kubernetes.io/node-name + +Type: Label + +Example: `nfd.node.kubernetes.io/node-name: node-1` + +Used on: Nodes + +It specifies which node the NodeFeature object is targeting. +Creators of NodeFeature objects must set this label and +consumers of the objects are supposed to use the label for +filtering features designated for a certain node. + +{{< note >}} +These Node Feature Discovery (NFD) labels or annotations only apply to +the nodes where NFD is running. To learn more about NFD and +its components go to its official [documentation](https://kubernetes-sigs.github.io/node-feature-discovery/stable/get-started/). +{{< /note >}} + +### service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval (beta) {#service-beta-kubernetes-io-aws-load-balancer-access-log-emit-interval} + +Example: `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval: "5"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +the load balancer for a Service based on this annotation. The value determines +how often the load balancer writes log entries. For example, if you set the value +to 5, the log writes occur 5 seconds apart. + +### service.beta.kubernetes.io/aws-load-balancer-access-log-enabled (beta) {#service-beta-kubernetes-io-aws-load-balancer-access-log-enabled} + +Example: `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "false"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +the load balancer for a Service based on this annotation. Access logging is enabled +if you set the annotation to "true". + +### service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name (beta) {#service-beta-kubernetes-io-aws-load-balancer-access-log-s3-bucket-name} + +Example: `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: example` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +the load balancer for a Service based on this annotation. The load balancer +writes logs to an S3 bucket with the name you specify. + +### service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix (beta) {#service-beta-kubernetes-io-aws-load-balancer-access-log-s3-bucket-prefix} + +Example: `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled: "/example"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +the load balancer for a Service based on this annotation. The load balancer +writes log objects with the prefix that you specify. + +### service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags (beta) {#service-beta-kubernetes-io-aws-load-balancer-additional-resource-tags} + +Example: `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: "Environment=demo,Project=example"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +tags (an AWS concept) for a load balancer based on the comma-separated key/value +pairs in the value of this annotation. + +### service.beta.kubernetes.io/aws-load-balancer-alpn-policy (beta) {#service-beta-kubernetes-io-aws-load-balancer-alpn-policy} + +Example: `service.beta.kubernetes.io/aws-load-balancer-alpn-policy: HTTP2Optional` + +Used on: Service + +The [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) +uses this annotation. +See [annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/) +in the AWS load balancer controller documentation. + +### service.beta.kubernetes.io/aws-load-balancer-attributes (beta) {#service-beta-kubernetes-io-aws-load-balancer-attributes} + +Example: `service.beta.kubernetes.io/aws-load-balancer-attributes: "deletion_protection.enabled=true"` + +Used on: Service + +The [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) +uses this annotation. +See [annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/) +in the AWS load balancer controller documentation. + +### service.beta.kubernetes.io/aws-load-balancer-backend-protocol (beta) {#service-beta-kubernetes-io-aws-load-balancer-backend-protocol} + +Example: `service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +the load balancer listener based on the value of this annotation. + +### service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled (beta) {#service-beta-kubernetes-io-aws-load-balancer-connection-draining-enabled} + +Example: `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled: "false"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +the load balancer based on this annotation. The load balancer's connection draining +setting depends on the value you set. + +### service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout (beta) {#service-beta-kubernetes-io-aws-load-balancer-connection-draining-timeout} + +Example: `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout: "60"` + +Used on: Service + +If you configure [connection draining](#service-beta-kubernetes-io-aws-load-balancer-connection-draining-enabled) +for a Service of `type: LoadBalancer`, and you use the AWS cloud, the integration configures +the draining period based on this annotation. The value you set determines the draining +timeout in seconds. + +### service.beta.kubernetes.io/aws-load-balancer-ip-address-type (beta) {#service-beta-kubernetes-io-aws-load-balancer-ip-address-type} + +Example: `service.beta.kubernetes.io/aws-load-balancer-ip-address-type: ipv4` + +Used on: Service + +The [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) +uses this annotation. +See [annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/) +in the AWS load balancer controller documentation. + +### service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout (beta) {#service-beta-kubernetes-io-aws-load-balancer-connection-idle-timeout} + +Example: `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. The load balancer has a configured idle +timeout period (in seconds) that applies to its connections. If no data has been +sent or received by the time that the idle timeout period elapses, the load balancer +closes the connection. + +### service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled (beta) {#service-beta-kubernetes-io-aws-load-balancer-cross-zone-load-balancing-enabled} + +Example: `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. If you set this annotation to "true", +each load balancer node distributes requests evenly across the registered targets +in all enabled [availability zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones). +If you disable cross-zone load balancing, each load balancer node distributes requests +evenly across the registered targets in its availability zone only. + +### service.beta.kubernetes.io/aws-load-balancer-eip-allocations (beta) {#service-beta-kubernetes-io-aws-load-balancer-eip-allocations} + +Example: `service.beta.kubernetes.io/aws-load-balancer-eip-allocations: "eipalloc-01bcdef23bcdef456,eipalloc-def1234abc4567890"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. The value is a comma-separated list +of elastic IP address allocation IDs. + +This annotation is only relevant for Services of `type: LoadBalancer`, where +the load balancer is an AWS Network Load Balancer. + +### service.beta.kubernetes.io/aws-load-balancer-extra-security-groups (beta) {#service-beta-kubernetes-io-aws-load-balancer-extra-security-groups} + +Example: `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-12abcd3456,sg-34dcba6543"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. The annotation value is a comma-separated +list of extra AWS VPC security groups to configure for the load balancer. + +### service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold (beta) {#service-beta-kubernetes-io-aws-load-balancer-healthcheck-healthy-threshold} + +Example: `service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "3"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. The annotation value specifies the number of +successive successful health checks required for a backend to be considered healthy +for traffic. + +### service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval (beta) {#service-beta-kubernetes-io-aws-load-balancer-healthcheck-interval} + +Example: `service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "30"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. The annotation value specifies the interval, +in seconds, between health check probes made by the load balancer. + +### service.beta.kubernetes.io/aws-load-balancer-healthcheck-path (beta) {#service-beta-kubernetes-io-aws-load-balancer-healthcheck-papth} + +Example: `service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: /healthcheck` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. The annotation value determines the +path part of the URL that is used for HTTP health checks. + +### service.beta.kubernetes.io/aws-load-balancer-healthcheck-port (beta) {#service-beta-kubernetes-io-aws-load-balancer-healthcheck-port} + +Example: `service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "24"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. The annotation value determines which +port the load balancer connects to when performing health checks. + +### service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol (beta) {#service-beta-kubernetes-io-aws-load-balancer-healthcheck-protocol} + +Example: `service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: TCP` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. The annotation value determines how the +load balancer checks the health of backend targets. + +### service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout (beta) {#service-beta-kubernetes-io-aws-load-balancer-healthcheck-timeout} + +Example: `service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "3"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. The annotation value specifies the number +of seconds before a probe that hasn't yet succeeded is automatically treated as +having failed. + +### service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold (beta) {#service-beta-kubernetes-io-aws-load-balancer-healthcheck-unhealthy-threshold} + +Example: `service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. The annotation value specifies the number of +successive unsuccessful health checks required for a backend to be considered unhealthy +for traffic. + +### service.beta.kubernetes.io/aws-load-balancer-internal (beta) {#service-beta-kubernetes-io-aws-load-balancer-internal} + +Example: `service.beta.kubernetes.io/aws-load-balancer-internal: "true"` + +Used on: Service + +The cloud controller manager integration with AWS elastic load balancing configures +a load balancer based on this annotation. When you set this annotation to "true", +the integration configures an internal load balancer. + +If you use the [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/), +see [`service.beta.kubernetes.io/aws-load-balancer-scheme`](#service-beta-kubernetes-io-aws-load-balancer-scheme). + +### service.beta.kubernetes.io/aws-load-balancer-manage-backend-security-group-rules (beta) {#service-beta-kubernetes-io-aws-load-balancer-manage-backend-security-group-rules} + +Example: `service.beta.kubernetes.io/aws-load-balancer-manage-backend-security-group-rules: "true"` + +Used on: Service + +The [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) +uses this annotation. +See [annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/) +in the AWS load balancer controller documentation. + +### service.beta.kubernetes.io/aws-load-balancer-name (beta) {#service-beta-kubernetes-io-aws-load-balancer-name} + +Example: `service.beta.kubernetes.io/aws-load-balancer-name: my-elb` + +Used on: Service + +If you set this annotation on a Service, and you also annotate that Service with +`service.beta.kubernetes.io/aws-load-balancer-type: "external"`, and you use the +[AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) +in your cluster, then the AWS load balancer controller sets the name of that load +balancer to the value you set for _this_ annotation. + +See [annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/) +in the AWS load balancer controller documentation. + +### service.beta.kubernetes.io/aws-load-balancer-nlb-target-type (beta) {#service-beta-kubernetes-io-aws-load-balancer-nlb-target-type} + +Example: `service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "true"` + +Used on: Service + +The [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) +uses this annotation. +See [annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/) +in the AWS load balancer controller documentation. + +### service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses (beta) {#service-beta-kubernetes-io-aws-load-balancer-private-ipv4-addresses} + +Example: `service.beta.kubernetes.io/aws-load-balancer-private-ipv4-addresses: "198.51.100.0,198.51.100.64"` + +Used on: Service + +The [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) +uses this annotation. +See [annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/) +in the AWS load balancer controller documentation. + +### service.beta.kubernetes.io/aws-load-balancer-proxy-protocol (beta) {#service-beta-kubernetes-io-aws-load-balancer-proxy-protocol} + +Example: `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"` + +Used on: Service + +The official Kubernetes integration with AWS elastic load balancing configures +a load balancer based on this annotation. The only permitted value is `"*"`, +which indicates that the load balancer should wrap TCP connections to the backend +Pod with the PROXY protocol. + +### service.beta.kubernetes.io/aws-load-balancer-scheme (beta) {#service-beta-kubernetes-io-aws-load-balancer-scheme} + +Example: `service.beta.kubernetes.io/aws-load-balancer-scheme: internal` + +Used on: Service + +The [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) +uses this annotation. +See [annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/) +in the AWS load balancer controller documentation. + +### service.beta.kubernetes.io/aws-load-balancer-security-groups (deprecated) {#service-beta-kubernetes-io-aws-load-balancer-security-groups} + +Example: `service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f,sg-8725gr62r"` + +Used on: Service + +The AWS load balancer controller uses this annotation to specify a comma separated list +of security groups you want to attach to an AWS load balancer. Both name and ID of security +are supported where name matches a `Name` tag, not the `groupName` attribute. + +When this annotation is added to a Service, the load-balancer controller attaches the security groups +referenced by the annotation to the load balancer. If you omit this annotation, the AWS load balancer +controller automatically creates a new security group and attaches it to the load balancer. + +{{< note >}} +Kubernetes v1.27 and later do not directly set or read this annotation. However, the AWS +load balancer controller (part of the Kubernetes project) does still use the +`service.beta.kubernetes.io/aws-load-balancer-security-groups` annotation. +{{< /note >}} + +### service.beta.kubernetes.io/load-balancer-source-ranges (deprecated) {#service-beta-kubernetes-io-load-balancer-source-ranges} + +Example: `service.beta.kubernetes.io/load-balancer-source-ranges: "192.0.2.0/25"` + +Used on: Service + +The [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) +uses this annotation. You should set `.spec.loadBalancerSourceRanges` for the Service instead. + +### service.beta.kubernetes.io/aws-load-balancer-ssl-cert (beta) {#service-beta-kubernetes-io-aws-load-balancer-ssl-cert} + +Example: `service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012"` + +Used on: Service + +The official integration with AWS elastic load balancing configures TLS for a Service of +`type: LoadBalancer` based on this annotation. The value of the annotation is the +AWS Resource Name (ARN) of the X.509 certificate that the load balancer listener should +use. + +(The TLS protocol is based on an older technology that abbreviates to SSL.) + +### service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy (beta) {#service-beta-kubernetes-io-aws-load-balancer-ssl-negotiation-policy} + +Example: `service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy: ELBSecurityPolicy-TLS-1-2-2017-01` + +The official integration with AWS elastic load balancing configures TLS for a Service of +`type: LoadBalancer` based on this annotation. The value of the annotation is the name +of an AWS policy for negotiating TLS with a client peer. + +### service.beta.kubernetes.io/aws-load-balancer-ssl-ports (beta) {#service-beta-kubernetes-io-aws-load-balancer-ssl-ports} + +Example: `service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "*"` + +The official integration with AWS elastic load balancing configures TLS for a Service of +`type: LoadBalancer` based on this annotation. The value of the annotation is either `"*"`, +which means that all the load balancer's ports should use TLS, or it is a comma separated +list of port numbers. + +### service.beta.kubernetes.io/aws-load-balancer-subnets (beta) {#service-beta-kubernetes-io-aws-load-balancer-subnets} + +Example: `service.beta.kubernetes.io/aws-load-balancer-subnets: "private-a,private-b"` + +Kubernetes' official integration with AWS uses this annotation to configure a +load balancer and determine in which AWS availability zones to deploy the managed +load balancing service. The value is either a comma separated list of subnet names, or a +comma separated list of subnet IDs. + +### service.beta.kubernetes.io/aws-load-balancer-target-group-attributes (beta) {#service-beta-kubernetes-io-aws-load-balancer-target-group-attributes} + +Example: `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: "stickiness.enabled=true,stickiness.type=source_ip"` + +Used on: Service + +The [AWS load balancer controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) +uses this annotation. +See [annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/) +in the AWS load balancer controller documentation. + +### service.beta.kubernetes.io/aws-load-balancer-target-node-labels (beta) {#service-beta-kubernetes-io-aws-target-node-labels} + +Example: `service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "kubernetes.io/os=Linux,topology.kubernetes.io/region=us-east-2"` + +Kubernetes' official integration with AWS uses this annotation to determine which +nodes in your cluster should be considered as valid targets for the load balancer. + +### service.beta.kubernetes.io/aws-load-balancer-type (beta) {#service-beta-kubernetes-io-aws-load-balancer-type} + +Example: `service.beta.kubernetes.io/aws-load-balancer-type: external` + +Kubernetes' official integrations with AWS use this annotation to determine +whether the AWS cloud provider integration should manage a Service of +`type: LoadBalancer`. + +There are two permitted values: + +`nlb` +: the cloud controller manager configures a Network Load Balancer + +`external` +: the cloud controller manager does not configure any load balancer + +If you deploy a Service of `type: LoadBalancer` on AWS, and you don't set any +`service.beta.kubernetes.io/aws-load-balancer-type` annotation, +the AWS integration deploys a classic Elastic Load Balancer. This behavior, +with no annotation present, is the default unless you specify otherwise. + +When you set this annotation to `external` on a Service of `type: LoadBalancer`, +and your cluster has a working deployment of the AWS Load Balancer controller, +then the AWS Load Balancer controller attempts to deploy a load balancer based +on the Service specification. + +{{< caution >}} +Do not modify or add the `service.beta.kubernetes.io/aws-load-balancer-type` annotation +on an existing Service object. See the AWS documentation on this topic for more +details. +{{< /caution >}} + +### pod-security.kubernetes.io/enforce + +Type: Label + +Example: `pod-security.kubernetes.io/enforce: "baseline"` + +Used on: Namespace + +Value **must** be one of `privileged`, `baseline`, or `restricted` which correspond to +[Pod Security Standard](/docs/concepts/security/pod-security-standards) levels. +Specifically, the `enforce` label _prohibits_ the creation of any Pod in the labeled +Namespace which does not meet the requirements outlined in the indicated level. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +### pod-security.kubernetes.io/enforce-version + +Type: Label + +Example: `pod-security.kubernetes.io/enforce-version: "{{< skew currentVersion >}}"` + +Used on: Namespace + +Value **must** be `latest` or a valid Kubernetes version in the format `v.`. +This determines the version of the +[Pod Security Standard](/docs/concepts/security/pod-security-standards) +policies to apply when validating a Pod. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +### pod-security.kubernetes.io/audit + +Type: Label + +Example: `pod-security.kubernetes.io/audit: "baseline"` + +Used on: Namespace + +Value **must** be one of `privileged`, `baseline`, or `restricted` which correspond to +[Pod Security Standard](/docs/concepts/security/pod-security-standards) levels. +Specifically, the `audit` label does not prevent the creation of a Pod in the labeled +Namespace which does not meet the requirements outlined in the indicated level, +but adds an this annotation to the Pod. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +### pod-security.kubernetes.io/audit-version + +Type: Label + +Example: `pod-security.kubernetes.io/audit-version: "{{< skew currentVersion >}}"` + +Used on: Namespace + +Value **must** be `latest` or a valid Kubernetes version in the format `v.`. +This determines the version of the +[Pod Security Standard](/docs/concepts/security/pod-security-standards) +policies to apply when validating a Pod. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +### pod-security.kubernetes.io/warn + +Type: Label + +Example: `pod-security.kubernetes.io/warn: "baseline"` + +Used on: Namespace + +Value **must** be one of `privileged`, `baseline`, or `restricted` which correspond to +[Pod Security Standard](/docs/concepts/security/pod-security-standards) levels. +Specifically, the `warn` label does not prevent the creation of a Pod in the labeled +Namespace which does not meet the requirements outlined in the indicated level, +but returns a warning to the user after doing so. +Note that warnings are also displayed when creating or updating objects that contain +Pod templates, such as Deployments, Jobs, StatefulSets, etc. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +### pod-security.kubernetes.io/warn-version + +Type: Label + +Example: `pod-security.kubernetes.io/warn-version: "{{< skew currentVersion >}}"` + +Used on: Namespace + +Value **must** be `latest` or a valid Kubernetes version in the format `v.`. +This determines the version of the [Pod Security Standard](/docs/concepts/security/pod-security-standards) +policies to apply when validating a submitted Pod. +Note that warnings are also displayed when creating or updating objects that contain +Pod templates, such as Deployments, Jobs, StatefulSets, etc. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +### rbac.authorization.kubernetes.io/autoupdate + +Type: Annotation + +Example: `rbac.authorization.kubernetes.io/autoupdate: "false"` + +Used on: ClusterRole, ClusterRoleBinding, Role, RoleBinding + +When this annotation is set to `"true"` on default RBAC objects created by the API server, +they are automatically updated at server start to add missing permissions and subjects +(extra permissions and subjects are left in place). +To prevent autoupdating a particular role or rolebinding, set this annotation to `"false"`. +If you create your own RBAC objects and set this annotation to `"false"`, `kubectl auth reconcile` +(which allows reconciling arbitrary RBAC objects in a {{< glossary_tooltip text="manifest" term_id="manifest" >}}) +respects this annotation and does not automatically add missing permissions and subjects. + +### kubernetes.io/psp (deprecated) {#kubernetes-io-psp} + +Type: Annotation + +Example: `kubernetes.io/psp: restricted` + +Used on: Pod + +This annotation was only relevant if you were using +[PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) objects. +Kubernetes v{{< skew currentVersion >}} does not support the PodSecurityPolicy API. + +When the PodSecurityPolicy admission controller admitted a Pod, the admission controller +modified the Pod to have this annotation. +The value of the annotation was the name of the PodSecurityPolicy that was used for validation. + +### seccomp.security.alpha.kubernetes.io/pod (non-functional) {#seccomp-security-alpha-kubernetes-io-pod} + +Type: Annotation + +Used on: Pod + +Kubernetes before v1.25 allowed you to configure seccomp behavior using this annotation. +See [Restrict a Container's Syscalls with seccomp](/docs/tutorials/security/seccomp/) to +learn the supported way to specify seccomp restrictions for a Pod. + +### container.seccomp.security.alpha.kubernetes.io/[NAME] (non-functional) {#container-seccomp-security-alpha-kubernetes-io} + +Type: Annotation + +Used on: Pod + +Kubernetes before v1.25 allowed you to configure seccomp behavior using this annotation. +See [Restrict a Container's Syscalls with seccomp](/docs/tutorials/security/seccomp/) to +learn the supported way to specify seccomp restrictions for a Pod. + +### snapshot.storage.kubernetes.io/allow-volume-mode-change + +Type: Annotation + +Example: `snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"` + +Used on: VolumeSnapshotContent + +Value can either be `true` or `false`. This determines whether a user can modify +the mode of the source volume when a PersistentVolumeClaim is being created from +a VolumeSnapshot. + +Refer to [Converting the volume mode of a Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) +and the [Kubernetes CSI Developer Documentation](https://kubernetes-csi.github.io/docs/) +for more information. + +### scheduler.alpha.kubernetes.io/critical-pod (deprecated) + +Type: Annotation + +Example: `scheduler.alpha.kubernetes.io/critical-pod: ""` + +Used on: Pod + +This annotation lets Kubernetes control plane know about a Pod being a critical Pod +so that the descheduler will not remove this Pod. + +{{< note >}} +Starting in v1.16, this annotation was removed in favor of +[Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/). +{{< /note >}} + +## Annotations used for audit + + +- [`authorization.k8s.io/decision`](/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-decision) +- [`authorization.k8s.io/reason`](/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-reason) +- [`insecure-sha1.invalid-cert.kubernetes.io/$hostname`](/docs/reference/labels-annotations-taints/audit-annotations/#insecure-sha1-invalid-cert-kubernetes-io-hostname) +- [`missing-san.invalid-cert.kubernetes.io/$hostname`](/docs/reference/labels-annotations-taints/audit-annotations/#missing-san-invalid-cert-kubernetes-io-hostname) +- [`pod-security.kubernetes.io/audit-violations`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations) +- [`pod-security.kubernetes.io/enforce-policy`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy) +- [`pod-security.kubernetes.io/exempt`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt) + +See more details on [Audit Annotations](/docs/reference/labels-annotations-taints/audit-annotations/). + +## kubeadm + +### kubeadm.alpha.kubernetes.io/cri-socket + +Type: Annotation + +Example: `kubeadm.alpha.kubernetes.io/cri-socket: unix:///run/containerd/container.sock` + +Used on: Node + +Annotation that kubeadm uses to preserve the CRI socket information given to kubeadm at +`init`/`join` time for later use. kubeadm annotates the Node object with this information. +The annotation remains "alpha", since ideally this should be a field in KubeletConfiguration +instead. + +### kubeadm.kubernetes.io/etcd.advertise-client-urls + +Type: Annotation + +Example: `kubeadm.kubernetes.io/etcd.advertise-client-urls: https://172.17.0.18:2379` + +Used on: Pod + +Annotation that kubeadm places on locally managed etcd Pods to keep track of +a list of URLs where etcd clients should connect to. +This is used mainly for etcd cluster health check purposes. + +### kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint + +Type: Annotation + +Example: `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https://172.17.0.18:6443` + +Used on: Pod + +Annotation that kubeadm places on locally managed `kube-apiserver` Pods to keep track +of the exposed advertise address/port endpoint for that API server instance. + +### kubeadm.kubernetes.io/component-config.hash + +Type: Annotation + +Example: `kubeadm.kubernetes.io/component-config.hash: 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae` + +Used on: ConfigMap + +Annotation that kubeadm places on ConfigMaps that it manages for configuring components. +It contains a hash (SHA-256) used to determine if the user has applied settings different +from the kubeadm defaults for a particular component. + +### node-role.kubernetes.io/control-plane + +Type: Label + +Used on: Node + +A marker label to indicate that the node is used to run control plane components. +The kubeadm tool applies this label to the control plane nodes that it manages. +Other cluster management tools typically also set this taint. + +You can label control plane nodes with this label to make it easier to schedule Pods +only onto these nodes, or to avoid running Pods on the control plane. +If this label is set, the [EndpointSlice controller](/docs/concepts/services-networking/topology-aware-routing/#implementation-control-plane) +ignores that node while calculating Topology Aware Hints. + +### node-role.kubernetes.io/control-plane {#node-role-kubernetes-io-control-plane-taint} + +Type: Taint + +Example: `node-role.kubernetes.io/control-plane:NoSchedule` + +Used on: Node + +Taint that kubeadm applies on control plane nodes to restrict placing Pods and +allow only specific pods to schedule on them. + +If this Taint is applied, control plane nodes allow only critical workloads to +be scheduled onto them. You can manually remove this taint with the following +command on a specific node. + +```shell +kubectl taint nodes node-role.kubernetes.io/control-plane:NoSchedule- +``` + +### node-role.kubernetes.io/master (deprecated) {#node-role-kubernetes-io-master-taint} + +Type: Taint + +Used on: Node + +Example: `node-role.kubernetes.io/master:NoSchedule` + +Taint that kubeadm previously applied on control plane nodes to allow only critical +workloads to schedule on them. Replaced by the +[`node-role.kubernetes.io/control-plane`](#node-role-kubernetes-io-control-plane-taint) +taint. kubeadm no longer sets or uses this deprecated taint. diff --git a/content/uk/docs/reference/networking/_index.md b/content/uk/docs/reference/networking/_index.md new file mode 100644 index 0000000000000..180896cae5f83 --- /dev/null +++ b/content/uk/docs/reference/networking/_index.md @@ -0,0 +1,10 @@ +--- +title: Довідник з мережі +content_type: reference +weight: 85 +--- + + +Цей розділ документації Kubernetes містить деталі про використання мережі в Kubernetes. + + \ No newline at end of file diff --git a/content/uk/docs/reference/node/_index.md b/content/uk/docs/reference/node/_index.md new file mode 100644 index 0000000000000..1cb892f5c170f --- /dev/null +++ b/content/uk/docs/reference/node/_index.md @@ -0,0 +1,18 @@ +--- +title: Довідкова інформація про вузли +weight: 80 +no_list: true +--- + +У цьому розділі містяться наступні теми про вузли: + +* [checkpoint API](/docs/reference/node/kubelet-checkpoint-api/) kubelet +* Список [статей про видалення dockershim та використання сумісних з CRI виконавчих середовищ](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/) + +* [Інформація про статус вузла `.status`](/docs/reference/node/node-status/) + +Ви також можете ознайомитись з довідкою про вузли в інших розділах документації Kubernetes, зокрема: + +* [Дані метрик вузла](/docs/reference/instrumentation/node-metrics). + +* [Метрики CRI для Podʼів та контейнерів](/docs/reference/instrumentation/cri-pod-container-metrics). diff --git a/content/uk/docs/reference/scheduling/_index.md b/content/uk/docs/reference/scheduling/_index.md new file mode 100644 index 0000000000000..37207381c508e --- /dev/null +++ b/content/uk/docs/reference/scheduling/_index.md @@ -0,0 +1,5 @@ +--- +title: Планування +weight: 140 +toc-hide: true +--- diff --git a/content/uk/docs/reference/setup-tools/_index.md b/content/uk/docs/reference/setup-tools/_index.md new file mode 100644 index 0000000000000..1d4b0a0f8d5ea --- /dev/null +++ b/content/uk/docs/reference/setup-tools/_index.md @@ -0,0 +1,4 @@ +--- +title: Інструменти встановлення +weight: 100 +--- diff --git a/content/uk/docs/reference/tools/_index.md b/content/uk/docs/reference/tools/_index.md new file mode 100644 index 0000000000000..bfba08fa8e766 --- /dev/null +++ b/content/uk/docs/reference/tools/_index.md @@ -0,0 +1,63 @@ +--- +title: Інші інструменти +reviewers: +- janetkuo +content_type: concept +weight: 150 +no_list: true +--- + + + +Kubernetes містить кілька інструментів, які допоможуть вам працювати з системою Kubernetes. + + + +## crictl + +[`crictl`](https://github.com/kubernetes-sigs/cri-tools) — це інтерфейс командного рядка для перегляду та відлагодження оточення виконання контейнерів, сумісних з {{}}. + +## Dashboard + +[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), вебінтерфейс Kubernetes, дозволяє розгортати контейнерні застосунки в кластері Kubernetes, розвʼязувати проблеми з ними та управляти кластером та його ресурсами. + +## Helm + +{{% thirdparty-content single="true" %}} + +[Helm](https://helm.sh/) — це інструмент для управління пакунками наперед сконфігурованих ресурсів Kubernetes. Ці пакунки відомі як _Helm charts_. + +Використовуйте Helm для: + +* Пошуку та використання популярного програмного забезпечення, упакованого як Helm charts для Kubernetes +* Поширення ваших застосунків у вигляді Helm charts +* Створення відтворюваних збірок вашого застосунку Kubernetes +* Управління файлами маніфестів Kubernetes +* Управління випусками пакунків Helm + +## Kompose + +[`Kompose`](https://github.com/kubernetes/kompose) — це інструмент для допомоги користувачам Docker Compose в переході до Kubernetes. + +Використовуйте Kompose для: + +* Перетворення файлу Docker Compose в обʼєкти Kubernetes +* Переходу від локальної розробки Docker до управління вашим застосунком через Kubernetes +* Конвертації файлів Docker Compose `yaml` версій v1 або v2 або [Distributed Application Bundles](https://docs.docker.com/compose/bundles/) + +## Kui + +[`Kui`](https://github.com/kubernetes-sigs/kui) — це графічний інструмент, який обробляє ваші звичайні запити командного рядка `kubectl` та показує вивід в графічному вигляді. + +Kui обробляє звичайні запити командного рядка `kubectl` та показує вивід в графічному вигляді. Замість ASCII-таблиць, Kui надає графічний рендеринг з таблицями, які можна сортувати. + +Kui дозволяє вам: + +* Натискати на довгі, автоматично генеровані назви ресурсів, замість копіювання та вставляння +* Вводити команди `kubectl` і бачити їх виконання, іноді навіть швидше, ніж в `kubectl` +* Запитувати {{< glossary_tooltip text="Job" term_id="job">}} та бачити його виконання у вигляді діаграми водоспаду +* Переходити за ресурсами в вашому кластері за допомогою графічного інтерфейсу користувача + +## Minikube + +[`minikube`](https://minikube.sigs.k8s.io/docs/) — це інструмент, який запускає локальний однокомпонентний кластер Kubernetes безпосередньо на вашому компʼютері для розробки та тестування. diff --git a/content/uk/docs/reference/using-api/_index.md b/content/uk/docs/reference/using-api/_index.md new file mode 100644 index 0000000000000..43547aec87b5b --- /dev/null +++ b/content/uk/docs/reference/using-api/_index.md @@ -0,0 +1,90 @@ +--- +title: Огляд API +reviewers: +- erictune +- lavalamp +- jbeda +content_type: concept +weight: 20 +no_list: true +card: + name: reference + weight: 50 + title: Огляд API +--- + + + +Цей розділ містить довідкову інформацію про API Kubernetes. + +REST API є фундаментальною основою Kubernetes. Усі операції та комунікації між компонентами та зовнішніми командами користувачів є викликами REST API, які обробляє API-сервер. Внаслідок цього все в Kubernetes обробляється як обʼєкти API та має відповідний запис в [API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). + +[Довідник API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) містить список API для версії Kubernetes {{< param "version" >}}. + +Для отримання загальної інформації, читайте [API Kubernetes](/docs/concepts/overview/kubernetes-api/). [Керування доступом до API Kubernetes](/docs/concepts/security/controlling-access/) описує, як клієнти можуть аутентифікуватися до сервера API Kubernetes, та як їхні запити авторизуються. + +## Версіювання API {#api-versioning} + +Схеми серіалізації JSON та Protobuf слідкують однаковими принципами для змін схеми. Наступні описи стосуються обох форматів. + +Версіювання API та версіювання програмного забезпечення непрямо повʼязані. [Пропозиція з версіювання API та релізів](https://git.k8s.io/sig-release/release-engineering/versioning.md) описує відносини між версіюванням API та версіюванням програмного забезпечення. + +Різні версії API вказують на різні рівні стабільності та підтримки. Докладнішу інформацію про критерії кожного рівня можна знайти в [документації API Changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). + +Ось короткий огляд кожного рівня: + +- Alpha: + - Назви версій містять `alpha` (наприклад, `v1alpha1`). + - Вбудовані версії API рівня alpha типово вимкнені та повинні бути явно увімкнені в конфігурації `kube-apiserver` для використання. + - Програмне забезпечення може містити помилки. Увімкнення функції може виявити помилки. + - Підтримка alpha API може бути відключена в будь-який момент без попередження. + - API може змінитися несумісним чином у подальших версіях програмного забезпечення без попередження. + - Рекомендується використовувати програмне забезпечення тільки в тестових кластерах для короткочасного тестування через збільшений ризик помилок та відсутність довгострокової підтримки. + +- Beta: + - Назви версій містять `beta` (наприклад, `v2beta3`). + - Вбудовані версії API рівня beta типово вимкнені та повинні бути явно увімкнені в конфігурації `kube-apiserver` для використання (**за винятком** бета-версій API, представлених до Kubernetes 1.22, які були увімкнені за замовчуванням). + - Вбудовані версії API рівня beta мають максимальний термін служби 9 місяців або 3 мінорні випуски (в залежності, що довше), починаючи від введення до застаріння, і 9 місяців або 3 мінорні випуски (який завдовжки) від застаріння до вилучення. + - Програмне забезпечення добре протестоване. Увімкнення функції вважається безпечним. + - Підтримка функції не буде відключена, хоча можуть змінитися деталі. + + - Схема та/або семантика обʼєктів може змінюватися несумісним чином у подальших версіях API рівня beta або стабільного. Коли це відбувається, надаються інструкції з міграції. Адаптація до наступної версії API рівня beta або стабільного може вимагати редагування чи повторного створення обʼєктів API, і це може бути не простим. Міграція може вимагати перерви у роботі застосунків, які покладаються на цю функцію. + - Програмне забезпечення не рекомендується для використання в промисловій експлуатації. Подальші випуски можуть вносити несумісні зміни. Використання версій API рівня beta обовʼязкове для переходу до наступних версій API рівня beta або стабільного, якщо версія API рівня beta застаріє та більше не буде обслуговуватися. + + {{< note >}} + Спробуйте бета-функції та надавайте відгуки. Після того, як функції вийдуть з бета, може бути непрактично вносити більше змін. + {{< /note >}} + +- Stable: + - Назва версії — `vX`, де `X` – це ціле число. + - Стабільні версії API залишаються доступними для всіх майбутніх випусків в межах основної версії Kubernetes, і немає поточних планів щодо ревізії основної версії Kubernetes, що вилучає стабільні API. + +## Групи API {#api-groups} + +[Групи API](https://git.k8s.io/design-proposals-archive/api-machinery/api-group.md) спрощують розширення API Kubernetes. Група API вказується в REST-шляху та в полі `apiVersion` серіалізованого обʼєкта. + +У Kubernetes існує кілька груп API: + +- *core* (також називається *legacy*) група знаходиться за REST-шляхом `/api/v1`. Основна група не вказується як частина поля `apiVersion`, наприклад, `apiVersion: v1`. +- Названі групи знаходяться за REST-шляхом `/apis/$GROUP_NAME/$VERSION` та використовують `apiVersion: $GROUP_NAME/$VERSION` (наприклад, `apiVersion: batch/v1`). Повний список підтримуваних груп API можна знайти в [довіднику API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#-strong-api-groups-strong-). + +## Увімкнення чи вимкнення груп API {#enabling-or-disabling} + +Деякі ресурси та групи API типово увімкнені. Ви можете увімкнути чи вимкнути їх, встановивши `--runtime-config` на API-сервері. Прапорець `--runtime-config` приймає розділені комами пари `[=]`, що описують конфігурацію запуску API-сервера. Якщо частина `=` пропущена, вона розглядається так, ніби вказано `=true`. Наприклад: + +- для вимкнення `batch/v1` встановіть `--runtime-config=batch/v1=false` +- для увімкнення `batch/v2alpha1` встановіть `--runtime-config=batch/v2alpha1` +- для увімкнення конкретної версії API, наприклад, `storage.k8s.io/v1beta1/csistoragecapacities`, встановіть `--runtime-config=storage.k8s.io/v1beta1/csistoragecapacities` + +{{< note >}} +При увімкненні чи вимкненні груп, чи ресурсів потрібно перезапустити API-сервер та controller manager, щоб внести зміни до `--runtime-config`. +{{< /note >}} + +## Збереження {#persistence} + +Kubernetes зберігає свій серіалізований стан у термінах ресурсів API, записуючи їх в {{< glossary_tooltip term_id="etcd" >}}. + +## {{% heading "whatsnext" %}} + +- Дізнайтеся більше про [домовленості API](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions) +- Прочитайте документацію [агрегатора](https://git.k8s.io/design-proposals-archive/api-machinery/aggregated-api-servers.md) diff --git a/content/uk/docs/setup/_index.md b/content/uk/docs/setup/_index.md index 89bda3862d60f..5db2564b96969 100644 --- a/content/uk/docs/setup/_index.md +++ b/content/uk/docs/setup/_index.md @@ -3,136 +3,52 @@ reviewers: - brendandburns - erictune - mikedanese -no_issue: true title: Початок роботи main_menu: true weight: 20 content_type: concept +no_list: true card: name: setup weight: 20 anchors: - - anchor: "#навчальне-середовище" + - anchor: "#learning-environment" title: Навчальне середовище - - anchor: "#прод-оточення" - title: Прод оточення + - anchor: "#production-environment" + title: Операційне середовище --- - -У цьому розділі розглянуто різні варіанти налаштування і запуску Kubernetes. +У цьому розділі перераховані різні способи налаштування та запуску Kubernetes. Коли ви встановлюєте Kubernetes, виберіть тип встановлення на основі: простоти обслуговування, захищеності, контролю, доступних ресурсів та досвіду, необхідного для роботи та управління кластером. - -Різні рішення Kubernetes відповідають різним вимогам: легкість в експлуатації, безпека, система контролю, наявні ресурси та досвід, необхідний для управління кластером. +Ви можете [завантажити Kubernetes](/releases/download/) для розгортання кластера Kubernetes на локальному компʼютері, у хмарі або у власному дата-центрі. - -Ви можете розгорнути Kubernetes кластер на робочому комп'ютері, у хмарі чи в локальному дата-центрі, або обрати керований Kubernetes кластер. Також можна створити індивідуальні рішення на базі різних провайдерів хмарних сервісів або на звичайних серверах. - - -Простіше кажучи, ви можете створити Kubernetes кластер у навчальному і в прод оточеннях. +Деякі [компоненти Kubernetes](/docs/concepts/overview/components/), такі як {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} або {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}, також можуть бути розгорнуті у вигляді [образів контейнерів](/releases/download/#container-images) всередині кластера. +**Рекомендується** запускати компоненти Kubernetes у вигляді образів контейнерів, де це можливо, та дозволити Kubernetes керувати цими компонентами. Компоненти, які запускають контейнери, зокрема kubelet, не можуть бути включені до цієї категорії. +Якщо ви не хочете самостійно керувати кластером Kubernetes, ви можете вибрати керований сервіс, включаючи [сертифіковані платформи](/docs/setup/production-environment/turnkey-solutions/). Існують також інші стандартизовані та спеціалізовані рішення для широкого спектру хмарних та фізичних середовищ. - - -## Навчальне оточення {#навчальне-оточення} - - -Для вивчення Kubernetes використовуйте рішення на базі Docker: інструменти, підтримувані спільнотою Kubernetes, або інші інструменти з сімейства проектів для налаштування Kubernetes кластера на локальному комп'ютері. - -{{< table caption="Таблиця інструментів для локального розгортання Kubernetes, які підтримуються спільнотою або входять до сімейства проектів Kubernetes." >}} - -|Спільнота |Сімейство проектів | -| ------------ | -------- | -| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| -| | [Minishift](https://docs.okd.io/latest/minishift/)| -| | [MicroK8s](https://microk8s.io/)| -| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | -| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)| -| | [k3s](https://k3s.io)| -{{< /table >}} - - -## Прод оточення {#прод-оточення} - - -Обираючи рішення для проду, визначіться, якими з функціональних складових (або абстракцій) Kubernetes кластера ви хочете керувати самі, а управління якими - доручити провайдеру. - - -У Kubernetes кластері можливі наступні абстракції: {{< glossary_tooltip text="застосунки" term_id="applications" >}}, {{< glossary_tooltip text="площина даних" term_id="data-plane" >}}, {{< glossary_tooltip text="площина управління" term_id="control-plane" >}}, {{< glossary_tooltip text="інфраструктура кластера" term_id="cluster-infrastructure" >}} та {{< glossary_tooltip text="операції з кластером" term_id="cluster-operations" >}}. - - -На діаграмі нижче показані можливі абстракції Kubernetes кластера із зазначенням, які з них потребують самостійного управління, а які можуть бути керовані провайдером. - -Рішення для прод оточення![Рішення для прод оточення](/images/docs/KubernetesSolutions.svg) - -{{< table caption="Таблиця рішень для прод оточення містить перелік провайдерів і їх технологій." >}} - -Таблиця рішень для прод оточення містить перелік провайдерів і технологій, які вони пропонують. - -|Провайдери | Керований сервіс | Хмара "під ключ" | Локальний дата-центр | Під замовлення (хмара) | Під замовлення (локальні ВМ)| Під замовлення (сервери без ОС) | -| --------- | ------ | ------ | ------ | ------ | ------ | ----- | -| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)| | ✔ | ✔ | | | -| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)| | ✔ | | | | -| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | | -| [AppsCode](https://appscode.com/products/pharmer/) | ✔ | | | | | -| [APPUiO](https://appuio.ch/)  | ✔ | ✔ | ✔ | | | | -| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | ✔ | | ✔ | ✔ | ✔ | -| [CenturyLink Cloud](https://www.ctl.io/) | | ✔ | | | | -| [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | | -| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ | -| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔| -| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔ -| [Containership](https://containership.io) | ✔ |✔ | | | | -| [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | -| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔ -| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | | -| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ -| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [Custom Extensions](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) | -| [Giant Swarm](https://www.giantswarm.io/) | ✔ | ✔ | ✔ | | -| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | -| [Hidora](https://hidora.com/) | ✔ | ✔| ✔ | | | | | | | | -| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | -| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | | -| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | -| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ | -| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | | -| [KubeSail](https://kubesail.com/) | ✔ | | | | | -| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ | -| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ | -| [Microsoft Azure](https://azure.microsoft.com) | [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | | | | | -| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | ✔ | | | -| [NetApp Kubernetes Service (NKS)](https://cloud.netapp.com/kubernetes-service) | ✔ | ✔ | ✔ | | | -| [Nirmata](https://www.nirmata.com/) | | ✔ | ✔ | | | -| [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) | -| [OpenNebula](https://www.opennebula.org) |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html) | | | | | -| [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/) -| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | ✔ | ✔ | | | | -| [oVirt](https://www.ovirt.org/) | | | | | ✔ | -| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | | -| [Platform9](https://platform9.com/) | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/) | ✔ | ✔ | ✔ -| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/) -| [Supergiant](https://supergiant.io/) | |✔ | | | | -| [SUSE](https://www.suse.com/) | | ✔ | | | | -| [SysEleven](https://www.syseleven.io/) | ✔ | | | | | -| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ | -| [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | | -| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) -| [Z.A.R.V.I.S.](https://zarvis.ai/) | ✔ | | | | | | -{{< /table >}} +## Навчальне середовище {#learning-environment} + +Якщо ви вивчаєте Kubernetes, використовуйте інструменти, які підтримуються спільнотою Kubernetes або входять до сімейства проєктів Kubernetes для розгортання кластера на локальному компʼютері. Див. [Інструменти розгортання](/docs/tasks/tools/). + +## Операційне середовище {#production-environment} + +При оцінці рішення для [операційного середовища](/docs/setup/production-environment/), враховуйте, якими з аспектів керування кластером Kubernetes (або *абстракцій*) ви хочете керувати самостійно, а які — доручити провайдеру. + +Для кластера, яким ви керуєте самостійно, офіційно підтримуваним інструментом для розгортання Kubernetes є [kubeadm](/docs/setup/production-environment/tools/kubeadm/). + +## {{% heading "whatsnext" %}} + +- [Завантаження Kubernetes](/releases/download/) +- Завантажте та [встановіть інструменти](/docs/tasks/tools/) включаючи `kubectl` +- Оберіть [середовище виконання контейнерів](/docs/setup/production-environment/container-runtimes/) для кластера Kubernetes +- Ознайомтесь з [найкращими практиками](/docs/setup/best-practices/) розгортання Kubernetes +Kubernetes створено так, щоб його {{< glossary_tooltip term_id="control-plane" text="панель управління" >}} працювала на Linux. У вашому кластері ви можете запускати застосунки на Linux чи іншій операційній системі, включаючи Windows. +- Дізнайтеся як [розгорнути кластер з вузлами Windows](/docs/concepts/windows/) diff --git a/content/uk/docs/setup/best-practices/_index.md b/content/uk/docs/setup/best-practices/_index.md index 696ad54d32b88..d2b22e23f828d 100644 --- a/content/uk/docs/setup/best-practices/_index.md +++ b/content/uk/docs/setup/best-practices/_index.md @@ -1,5 +1,4 @@ --- -#title: Best practices title: Найкращі практики weight: 40 --- diff --git a/content/uk/docs/setup/best-practices/certificates.md b/content/uk/docs/setup/best-practices/certificates.md new file mode 100644 index 0000000000000..4dc192a086b92 --- /dev/null +++ b/content/uk/docs/setup/best-practices/certificates.md @@ -0,0 +1,215 @@ +--- +title: Сертифікати PKI та вимоги +reviewers: +- sig-cluster-lifecycle +content_type: concept +weight: 50 +--- + + + +Kubernetes вимагає наявності сертифікатів PKI для автентифікації за допомогою TLS. Якщо ви встановлюєте Kubernetes за допомогою [kubeadm](/docs/reference/setup-tools/kubeadm/), сертифікати, необхідні для вашого кластера, генеруються автоматично. Ви також можете створити свої власні сертифікати, наприклад, щоб зберігати ваші приватні ключі більш безпечно, не зберігаючи їх на сервері API. Ця сторінка пояснює, які сертифікати необхідні для вашого кластера. + + + +## Як кластер використовує сертифікати {#how-certificates-are-used-by-your-cluster} + +Kubernetes вимагає PKI для наступних операцій: + +* Сертифікати клієнта для kubelet для автентифікації на сервері API +* [Сертифікати сервера kubelet](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates) для спілкування сервера API з kubelet +* Сертифікат для кінцевої точки сервера API +* Сертифікати клієнта для адміністраторів кластера для автентифікації на сервері API +* Сертифікати клієнта для сервера API для спілкування з kubelet +* Сертифікат клієнта для сервера API для спілкування з etcd +* Сертифікат клієнта/kubeconfig для менеджера контролера для спілкування з сервером API +* Сертифікат клієнта/kubeconfig для планувальника для спілкування з сервером API. +* Сертифікати клієнта та сервера для [проксі-сервера](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) + +{{< note >}} +Сертифікати `front-proxy` потрібні лише в разі використання kube-proxy для підтримки +[розширеного API-сервера](/docs/tasks/extend-kubernetes/setup-extension-api-server/). +{{< /note >}} + +etcd також реалізує взаємну аутентифікацію TLS для автентифікації клієнтів. + +## Де зберігаються сертифікати {#where-certificates-are-stored} + +Якщо ви встановлюєте Kubernetes за допомогою kubeadm, більшість сертифікатів зберігається в `/etc/kubernetes/pki`. Усі шляхи в цьому документі стосуються цієї теки, за винятком сертифікатів облікових записів користувачів, які kubeadm розміщує в `/etc/kubernetes`. + +## Налаштування сертифікатів вручну {#configuring-certificates-manually} + +Якщо ви не хочете, щоб kubeadm генерував необхідні сертифікати, ви можете створити їх за допомогою одного кореневого ЦС або подавши всі сертифікати. Детальні відомості щодо створення власного центра сертифікації дивіться в [Сертифікати](/docs/tasks/administer-cluster/certificates/). Додаткові відомості знаходяться в розділі [Certificate Management з kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/). + +### Один кореневий ЦС {#single-root-ca} + +Ви можете створити один кореневий ЦС, яким керує адміністратор. Цей кореневий ЦС може створювати кілька проміжних ЦС та делегувати весь подальший процес створення Kubernetes. + +Необхідні ЦС: + +| шлях | Типовий CN | опис | +|------------------------|-----------------------------|-------------------------------| +| ca.crt,key | kubernetes-ca | Загальний ЦС Kubernetes | +| etcd/ca.crt,key | etcd-ca | Для всіх функцій, повʼязаних з etcd | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | Для [проксі-сервера](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) | + +На додачу до цих ЦС також необхідно отримати пару ключ/сертифікат для управління обліковими записами служби, `sa.key` та `sa.pub`. Наведений нижче приклад ілюструє файли ключа та сертифіката ЦС, показані в попередній таблиці: + +``` +/etc/kubernetes/pki/ca.crt +/etc/kubernetes/pki/ca.key +/etc/kubernetes/pki/etcd/ca.crt +/etc/kubernetes/pki/etcd/ca.key +/etc/kubernetes/pki/front-proxy-ca.crt +/etc/kubernetes/pki/front-proxy-ca.key +``` + +### Усі сертифікати {#all-certificates} + +Якщо ви не хочете копіювати приватні ключі ЦС до свого кластера, ви можете створити всі сертифікати самостійно. + +Необхідні сертифікати: + +| Типовий CN | Батьківський ЦС | O (в обʼєкті) | вид | hosts (SAN) | +|----------------------------------------|---------------------------|---------------|------------------|------------------------------------------------------| +| kube-etcd | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | +| kube-etcd-peer | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | +| kube-etcd-healthcheck-client | etcd-ca | | client | | +| kube-apiserver-etcd-client | etcd-ca | | client | | +| kube-apiserver | kubernetes-ca | | server | ``, ``, ``, `[1]` | +| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | +| front-proxy-client | kubernetes-front-proxy-ca | | client | | + +{{< note >}} +Замість використання групи суперкористувача `system:masters` для `kube-apiserver-kubelet-client`, може бути використана менш привілейована група. kubeadm використовує групу `kubeadm:cluster-admins` для цієї мети. +{{< /note >}} + +[1]: будь-яка інша IP-адреса чи DNS-імʼя, за яким ви звертаєтеся до свого кластера (що використовується [kubeadm](/docs/reference/setup-tools/kubeadm/) для стабільної IP-адреси або DNS-імені балансування навантаження, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, `kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`) + +де `kind` посилається на один або кілька ключів x509, які також документовані в `.spec.usages` типу [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1#CertificateSigningRequest): + +| kind | Використання ключа | +|--------|-----------------------------------------------------------------------------------| +| server | цифровий підпис, шифрування ключа, автентифікація сервера | +| client | цифровий підпис, шифрування ключа, автентифікація клієнта | + +{{< note >}} +Hosts/SAN, наведені вище, є рекомендованими для отримання робочого кластера; якщо вимагається для конкретного налаштування, можливе додавання додаткових SAN до всіх сертифікатів сервера. +{{< /note >}} + +{{< note >}} +Лише для користувачів kubeadm: + +* Сценарій, коли ви копіюєте сертифікати ЦС до свого кластера без приватних ключів, називається зовнішнім ЦС у документації kubeadm. +* Якщо ви порівнюєте цей список зі згенерованим kubeadm PKI, слід мати на увазі, що сертифікати `kube-etcd`, `kube-etcd-peer` та `kube-etcd-healthcheck-client` не генеруються в разі зовнішнього etcd. +{{< /note >}} + +### Шляхи до сертифікатів {#certificate-paths} + +Сертифікати повинні бути розміщені в рекомендованому шляху (який використовує [kubeadm](/docs/reference/setup-tools/kubeadm/)). Шляхи повинні бути вказані за вказаним аргументом незалежно від місця розташування. + +| Типовий CN | рекомендований шлях до ключа | рекомендований шлях до сертифіката | команда | аргумент ключа | аргумент сертифіката | +|----------------------------------------|------------------------------------|------------------------------------|-------------------------|---------------------------------|--------------------------------------------------| +| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile | +| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile | +| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file | +| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file | +| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file | +| kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | --kubelet-client-key | --kubelet-client-certificate | +| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file | +| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file | +| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file | +| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file | +| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file | +| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file | +| etcd-ca | | etcd/ca.crt | etcdctl | | --cacert | +| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert | + +Ті ж самі вимоги стосуються пари ключів облікових записів служби: + +| Шлях приватного ключа | Шлях публічного ключа | команда | аргумент | +|------------------------|------------------------|-------------------------|--------------------------------------| +| sa.key | | kube-controller-manager | --service-account-private-key-file | +| | sa.pub | kube-apiserver | --service-account-key-file | + +Наведений нижче приклад ілюструє повні шляхи до файлів, перерахованих в попередній таблиці: + +``` +/etc/kubernetes/pki/etcd/ca.key +/etc/kubernetes/pki/etcd/ca.crt +/etc/kubernetes/pki/apiserver-etcd-client.key +/etc/kubernetes/pki/apiserver-etcd-client.crt +/etc/kubernetes/pki/ca.key +/etc/kubernetes/pki/ca.crt +/etc/kubernetes/pki/apiserver.key +/etc/kubernetes/pki/apiserver.crt +/etc/kubernetes/pki/apiserver-kubelet-client.key +/etc/kubernetes/pki/apiserver-kubelet-client.crt +/etc/kubernetes/pki/front-proxy-ca.key +/etc/kubernetes/pki/front-proxy-ca.crt +/etc/kubernetes/pki/front-proxy-client.key +/etc/kubernetes/pki/front-proxy-client.crt +/etc/kubernetes/pki/etcd/server.key +/etc/kubernetes/pki/etcd/server.crt +/etc/kubernetes/pki/etcd/peer.key +/etc/kubernetes/pki/etcd/peer.crt +/etc/kubernetes/pki/etcd/healthcheck-client.key +/etc/kubernetes/pki/etcd/healthcheck-client.crt +/etc/kubernetes/pki/sa.key +/etc/kubernetes/pki/sa.pub +``` + +## Налаштування сертифікатів для облікових записів користувачів {#configuring-certificates-for-user-accounts} + +Ви повинні вручну налаштувати ці облікові записи адміністратора та службові облікові записи: + +| ім'я файлу | ім'я облікового запису | Типовий CN | O (в обʼєкті) | +|-------------------------|-----------------------------|-----------------------------------|------------------------| +| admin.conf | default-admin | kubernetes-admin | `` | +| super-admin.conf | default-super-admin | kubernetes-super-admin | system:masters | +| kubelet.conf | default-auth | system:node:`` (див. примітку) | system:nodes | +| controller-manager.conf | default-controller-manager | system:kube-controller-manager | | +| scheduler.conf | default-scheduler | system:kube-scheduler | | + +{{< note >}} +Значення `` для `kubelet.conf` **має** точно відповідати значенню імені вузла, наданому [kubeadm](/docs/reference/setup-tools/kubeadm/), оскільки він реєструється з apiserver. Докладніше див. [Авторизація вузлів](/docs/reference/access-authn-authz/node/). +{{< /note >}} + +{{< note >}} +В вищенаведеному прикладі `` є специфічним для реалізації. Деякі інструменти підписують сертифікат у типовий конфігурації `admin.conf`, щоб він став частиною групи `system:masters`. `system:masters` — це привілейована група, яка може обходити рівень авторизації Kubernetes, такий як RBAC. Також деякі інструменти не генерують окремий `super-admin.conf` із сертифікатом, повʼязаним із цією групою суперкористувачів. + +kubeadm генерує два окремих сертифікати адміністратора у файлах kubeconfig. Один у файлі `admin.conf` і має `Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin`. `kubeadm:cluster-admins` — це власна група, повʼязана з роллю кластера `cluster-admin`. Цей файл генерується на всіх машинах панелі управління під контролем kubeadm. + +Інший у файлі `super-admin.conf` із `Subject: O = system:masters, CN = kubernetes-super-admin`. Цей файл генерується лише на вузлі, де було викликано `kubeadm init`. +{{< /note >}} + +1. Для кожної конфігурації створіть пару ключ/сертифікат x509 із зазначеними CN та O. + +2. Виконайте команду `kubectl` для кожної конфігурації наступним чином: + +```bash +KUBECONFIG= kubectl config set-cluster default-cluster --server=https://:6443 --certificate-authority --embed-certs +KUBECONFIG= kubectl config set-credentials --client-key .pem --client-certificate .pem --embed-certs +KUBECONFIG= kubectl config set-context default-system --cluster default-cluster --user +KUBECONFIG= kubectl config use-context default-system +``` + +Ці файли використовуються наступним чином: + +| Ім'я файлу | Команда | Коментар | +|------------------------|-------------------------|----------------------------------------| +| admin.conf | kubectl | Налаштовує користувача-адміністратора для кластера | +| super-admin.conf | kubectl | Налаштовує користувача-суперадміністратора для кластера | +| kubelet.conf | kubelet | Один обовʼязковий для кожного вузла в кластері | +| controller-manager.conf | kube-controller-manager | Має бути доданий до `manifests/kube-controller-manager.yaml` | +| scheduler.conf | kube-scheduler | Має бути доданий до `manifests/kube-scheduler.yaml` | + +Наведені нижче файли ілюструють повні шляхи до файлів, перерахованих у попередній таблиці: + +```bash +/etc/kubernetes/admin.conf +/etc/kubernetes/super-admin.conf +/etc/kubernetes/kubelet.conf +/etc/kubernetes/controller-manager.conf +/etc/kubernetes/scheduler.conf +``` diff --git a/content/uk/docs/setup/best-practices/cluster-large.md b/content/uk/docs/setup/best-practices/cluster-large.md new file mode 100644 index 0000000000000..e49db9e44eeb3 --- /dev/null +++ b/content/uk/docs/setup/best-practices/cluster-large.md @@ -0,0 +1,87 @@ +--- +reviewers: +- davidopp +- lavalamp +title: Міркування щодо великих кластерів +weight: 10 +--- + +Кластер — це набір {{< glossary_tooltip text="вузлів" term_id="node" >}} (фізичних або віртуальних +машин), на яких працюють агенти Kubernetes, керовані через {{< glossary_tooltip text="панель управління" term_id="control-plane" >}}. Kubernetes {{< param "version" >}} підтримує кластери розміром до 5,000 вузлів. Зокрема, Kubernetes розроблений для роботи з конфігураціями, які відповідають *всім* наступним критеріям: + +* Не більше 110 Podʼів на вузол +* Не більше 5,000 вузлів +* Не більше 150,000 Podʼів загалом +* Не більше 300,000 контейнерів загалом + +Ви можете масштабувати свій кластер, додаючи чи видаляючи вузли. Спосіб залежить від того, як ваш кластер розгорнутий. + +## Обмеження ресурсів у хмарних постачальників {#quota-issues} + +Щоб уникнути проблем із квотами хмарного постачальника при створенні кластера із багатьма вузлами, розгляньте наступне: + +* Запит на збільшення квоти ресурсів хмари, таких як: + * Кількість компʼютерів + * Центральні процесори (CPU) + * Томи зберігання + * Використані IP-адреси + * Набори правил фільтрації пакетів + * Кількість балансерів навантаження + * Підмережі + * Потоки логів +* Керування діями масштабування кластера для введення нових вузлів партіями, з паузою між партіями, оскільки деякі хмарні постачальники обмежують швидкість створення нових екземплярів. + +## Компоненти панелі управління + +Для великого кластера вам потрібна панель управління з достатнім обчислювальними та іншими ресурсами. + +Зазвичай ви запускаєте один чи два екземпляри панелі управління на кожній зоні відмов, спочатку масштабуючи ці екземпляри вертикально, а потім горизонтально після досягнення точки спаду ефективності вертикального масштабування. + +Вам слід запускати принаймні один екземпляр на кожній зоні відмов для забезпечення стійкості до відмов. Вузли Kubernetes автоматично не направляють трафік до панелі управління, які знаходяться в тій же зоні відмов; однак ваш постачальник хмари може мати власні механізми для цього. + +Наприклад, використовуючи керований балансувальник навантаження, ви налаштовуєте його на надсилання трафіку, який походить з kubelet та Podʼів у зоні відмови *A*, і направляєте цей трафік лише до хостів панелі управління, які також знаходяться в зоні *A*. Якщо один хост панелі управління або зона відмови кінцевої точки *А* виходить з мережі, це означає, що весь трафік панелі управління для вузлів у зоні *А* тепер надсилається між зонами. Запуск декількох хостів панелі управління в кожній зоні зменшує ймовірність цього результату. + +### Сховище etcd {#etcd-storage} + +Для покращення продуктивності великих кластерів ви можете зберігати обʼєкти подій в окремому відділеному екземплярі etcd. + +При створенні кластера ви можете (за допомогою власних інструментів): + +* запускати та налаштовувати додаткові екземплярти etcd +* налаштовувати {{< glossary_tooltip term_id="kube-apiserver" text="API сервер" >}} для використання його для зберігання подій + +Деталі з налаштування та управління etcd для великого кластера наведено в розділах +[Управління кластерами etcd для Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) та [Налаштування високодоступного кластера etcd за допомогою kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/). + +## Ресурси надбудов {#addon-resources} + +Обмеження ресурсів Kubernetes допомагають мінімізувати вплив витоків памʼяті та інших способів, якими можуть впливати капсули та контейнери на інші компоненти. Ці обмеження ресурсів стосуються ресурсів {{< glossary_tooltip text="надбудов" term_id="addons" >}} так само як вони стосуються робочих навантажень застосунків. + +Наприклад, ви можете встановити обмеження CPU та памʼяті для компонента логування: + +```yaml + ... + containers: + - name: fluentd-cloud-logging + image: fluent/fluentd-kubernetes-daemonset:v1 + resources: + limits: + cpu: 100m + memory: 200Mi +``` + +Типові обмеження для надбудов, як правило, базуються на даних, зібраних з досвіду роботи кожної надбудови на невеликих або середніх кластерах Kubernetes. При роботі на великих кластерах надбудови часто споживають більше деяких ресурсів, ніж встановлено типовими обмеженими. Якщо великий кластер розгортати без налаштування цих значень, надбудови можуть постійно не штатно завершувати роботу через досягнення обмеження памʼяті. З іншого боку, надбудова може працювати, але з поганою продуктивністю через обмеження часу CPU. + +Щоб уникнути проблем з ресурсами надбудов у кластері з багатьма вузлами, розгляньте наступне: + +* Деякі надбудови масштабуються вертикально — є одна репліка надбудови для кластера чи обслуговування всієї зони відмов. Для таких надбудов збільшуйте запити та обмеження при масштабуванні вашого кластера. +* Багато надбудов масштабуються горизонтально — ви додаєте можливості, запускаючи більше Podʼів, але з дуже великим кластером вам може також знадобитися трошки збільшити обмеження CPU чи памʼяті. VerticalPodAutoscaler може працювати в режимі _recommender_, щоб надати запропоновані цифри для запитів та обмежень. +* Деякі надбудови працюють як одна копія на вузол, керована {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}: наприклад, агрегатор логів рівня вузла. Так само як і у випадку горизонтально масштабованих надбудов, вам може також знадобитися трошки збільшити обмеження CPU чи памʼяті. + +## {{% heading "whatsnext" %}} + +* `VerticalPodAutoscaler` — це власний ресурс, який ви можете розгортати у свій кластер, щоб допомогти управляти запитами та обмеженнями ресурсів для Podʼів. Дізнайтеся більше про [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) та як ви можете використовувати його для масштабування компонентів кластера, включаючи критичні для кластера надбудови. + +* [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) інтегрується з рядом хмарних постачальників, щоб допомогти вам запускати правильну кількість вузлів для ресурсів у вашому кластері, відповідно до вимого. + +* [Addon Resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme) допомагає автоматично змінювати розміри надбудов при зміні масштабу вашого кластера. diff --git a/content/uk/docs/setup/best-practices/enforcing-pod-security-standards.md b/content/uk/docs/setup/best-practices/enforcing-pod-security-standards.md new file mode 100644 index 0000000000000..69514f9b78f7e --- /dev/null +++ b/content/uk/docs/setup/best-practices/enforcing-pod-security-standards.md @@ -0,0 +1,55 @@ +--- +reviewers: +- tallclair +- liggitt +title: Запровадження стандартів безпеки для Podʼів +weight: 40 +--- + + + +Ця сторінка надає огляд найкращих практик щодо впровадження [стандартів безпеки для Podʼів](/docs/concepts/security/pod-security-standards). + + + +## Використання вбудованого контролера допуску безпеки Podʼів {#using-the-built-in-pod-security-admission-controller} + +{{< feature-state for_k8s_version="v1.25" state="stable" >}} + +[Контролер допуску безпеки Podʼів](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) має на меті замінити застарілі політики безпеки Podʼів (PodSecurityPolicies). + +### Налаштування для всіх просторів імен кластера {#configure-all-cluster-namespaces} + +Простори імен, які абсолютно не мають жодної конфігурації, повинні розглядатися як значущі прогалини в безпеці вашого кластера. Ми рекомендуємо приділити час аналізу типів робочих навантажень в кожному просторі імен і, посилаючись на стандарти безпеки Podʼів, визначити відповідний рівень для кожного з них. Простори імен без міток повинні вказувати лише на те, що їх ще не оцінено. + +У сценарії, коли всі робочі навантаження у всіх просторах імен мають однакові вимоги до безпеки, ми надаємо [приклад](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/#applying-to-all-namespaces) який показує, як можна застосовувати мітки безпеки для Podʼів гуртом. + +### Принципу найменшого доступу {#embrace-the-principle-of-least-privilege} + +У ідеальному світі кожен Pod в кожному просторі імен повинен відповідати вимогам політики `restricted`. Однак це або не можливо, або не практично, оскільки деякі робочі навантаження будуть вимагати підняття привілеїв з певних причин. + +- Простори імен, які дозволяють робочі навантаження з піднятими привілеями, повинні встановлювати та здійснювати відповідні рівні контролю доступу. +- Для робочих навантажень, які працюють в цих дозвільних просторах імен, важливо зберігати документацію щодо їх унікальних вимог до безпеки. Якщо це можливо, розгляньте можливість подальшого обмеження цих вимог. + +### Використання стратегії мультимодальності {#adopt-a-multi-mode-strategy} + +Режими `audit` та `warn` контролера впровадження стандартів безпеки Podʼів дозволяють легко збирати важливі відомості щодо безпеки ваших Podʼів без порушення поточних робочих навантажень. + +Доброю практикою є включення цих режимів для всіх просторів імен, встановлюючи їх на _бажаний_ рівень і версію, яку ви в кінцевому підсумку хочете `застосувати`. Попередження та аудит-анотації, створені на цьому етапі, можуть направляти вас до цього стану. Якщо ви очікуєте, що автори робочих навантажень внесуть зміни для відповідності бажаному рівню, увімкніть режим `warn`. Якщо ви очікуєте використання логів аудиту для моніторингу та виклику змін для відповідності бажаному рівню, включіть режим `audit`. + +Коли режим `enforce` встановлено як бажаний рівень, ці режими все ще можуть бути корисними декількома різними способами: + +- Встановивши `warn` на той самий рівень, що й `enforce`, клієнти отримають попередження при спробі створення Podʼів (або ресурсів, які мають шаблони Podʼів), які не проходять валідацію. Це допоможе їм оновити ці ресурси, щоб вони стали сумісними. +- В просторах імен, які закріплюють `enforce` за конкретною не-останньою версією, встановлення режимів `audit` та `warn` на той самий рівень, що й `enforce`, але на `latest` версію, надає видимість налаштувань, які були дозволені попередніми версіями, але не дозволяються за поточними найкращими практиками. + +## Альтернативи від сторонніх постачальників {#third-party-alternatives} + +{{% thirdparty-content %}} + +В екосистемі Kubernetes розробляються інші альтернативи для впровадження профілів безпеки: + +- [Kubewarden](https://github.com/kubewarden). +- [Kyverno](https://kyverno.io/policies/). +- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper). + +Вирішення вибору _вбудованого_ рішення (наприклад, контролера допуску безпеки Podʼів) або інструменту від сторонніх постачальників цілком залежить від вашої конкретної ситуації. При оцінці будь-якого рішення довіра до вашого ланцюга постачання є критичною. В решті решт використання _будь-якого_ з зазначених підходів буде кращим, ніж нічого. diff --git a/content/uk/docs/setup/best-practices/multiple-zones.md b/content/uk/docs/setup/best-practices/multiple-zones.md new file mode 100644 index 0000000000000..baf3225541fb7 --- /dev/null +++ b/content/uk/docs/setup/best-practices/multiple-zones.md @@ -0,0 +1,74 @@ +--- +reviewers: +- jlowdermilk +- justinsb +- quinton-hoole +title: Запуск у кількох зонах +weight: 20 +content_type: concept +--- + + + +Ця сторінка описує запуск Kubernetes у кількох зонах. + + + +## Контекст {#background} + +Kubernetes створено так, що один кластер Kubernetes може працювати у кількох зонах відмов, зазвичай там, де ці зони вписуються в логічну групу, яку називають _регіоном_. Основні постачальники хмар визначають регіон як набір зон відмов (також називають _зонами доступності_), які надають однаковий набір функцій: в межах регіону кожна зона пропонує ті самі API та служби. + +Типові хмарні архітектури спрямовані на мінімізацію ймовірності того, що відмова в одній зоні також призведе до порушення роботи служб в іншій зоні. + +## Поведінка панелі управління {#control-plane-behavior} + +Усі [компоненти панелі управління](/docs/concepts/overview/components/#control-plane-components) підтримують роботу як пул взаємозамінних ресурсів, реплікованих для кожного компонента. + +При розгортанні панелі управління кластера розміщуйте репліки компонентів панелі управління в різних зонах відмов. Якщо доступність важлива, виберіть принаймні три зони відмов і реплікуйте кожен окремий компонент панелі управління (API-сервер, планувальник, etcd, менеджер контролерів кластера) принаймні в трьох зонах відмов. Якщо ви використовуєте менеджер хмарного контролера, вам також слід повторити це у всіх вибраних вами зонах відмови. + +{{< note >}} +Kubernetes не забезпечує міжзонну стійкість для кінцевих точок сервера API. Ви можете використовувати різні методи для підвищення доступності сервера API кластера, включаючи круговий огляд DNS, записи SRV або стороннє рішення для балансування навантаження з перевіркою працездатності. +{{< /note >}} + +## Поведінка вузла {#node-behavior} + +Kubernetes автоматично розподіляє Podʼи для робочих ресурсів (таких як {{< glossary_tooltip text="Deployment" term_id="deployment" >}} чи {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}) по різних вузлах кластера. Це розподілення допомагає зменшити вплив відмов. + +При запуску вузлів kubelet на кожному вузлі автоматично додає {{< glossary_tooltip text="мітки" term_id="label" >}} до обʼєкта вузла який представляє цей конкретний kubelet в API Kubernetes. Ці мітки можуть включати [інформацію про зону](/docs/reference/labels-annotations-taints/#topologykubernetesiozone). + +Якщо ваш кластер охоплює кілька зон або регіонів, ви можете використовувати мітки вузла разом з [обмеженнями розподілу топології для Podʼів](/docs/concepts/scheduling-eviction/topology-spread-constraints/), щоб керувати тим, як Podʼи розподіляються по вашому кластеру серед доменів відмови: регіони, зони, і навіть конкретні вузли. Ці підказки дозволяють {{< glossary_tooltip text="планувальнику" term_id="kube-scheduler" >}} розміщувати Podʼи для забезпечення кращої очікуваної доступності, зменшуючи ризик того, що пошкодження вашого навантаження вплине на весь робочий процес. + +Наприклад, ви можете встановити обмеження, щоб забезпечити, що 3 репліки StatefulSet працюють у різних зонах, коли це є можливим. Ви можете визначити це декларативно не вказуючи явно, які зони доступності використовуються для кожного робочого навантаження. + +### Розподіл вузлів по зонах {#distributing-nodes-across-zones} + +Ядро Kubernetes не створює вузли за вас; вам потрібно це зробити самостійно, або використовувати інструмент, такий як [Cluster API](https://cluster-api.sigs.k8s.io/), щоб керувати вузлами від вашого імені. + +Використовуючи інструменти, такі як Cluster API, ви можете визначити набори машин, які працюватимуть як робочі вузли для вашого кластера в різних областях відмови, і правила для автоматичного відновлення кластера у разі порушення обслуговування всієї зони. + +## Ручне призначення зон для Podʼів {#manually-zone-assignment-for-pods} + +Ви можете застосовувати [обмеження селектора вузла](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) до Podʼів, які ви створюєте, а також до шаблонів Podʼів в робочих ресурсах таких як Deployment, StatefulSet або Job. + +## Доступ до ресурсів зберігання для зон {#storage-access-for-zones} + +При створенні постійних томів, [контролер доступу](/docs/reference/access-authn-authz/admission-controllers/) `PersistentVolumeLabel` автоматично додає мітки зони до будь-яких PersistentVolumes, які повʼязані з конкретним зони. Потім {{< glossary_tooltip text="планувальник" term_id="kube-scheduler" >}} переконується, через свій предикат `NoVolumeZoneConflict`, що Podʼи, які вимагають певного постійного тому, розміщуються тільки в тій самій зоні, що й цей том. + +Ви можете вказати {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} для PersistentVolumeClaims, який вказує домени відмов (зони), які може використовувати сховище в цьому класі. Щоб дізнатися, як налаштувати StorageClass, який опікується доменами відмов або зонами, див. [Дозволені топології](/docs/concepts/storage/storage-classes/#allowed-topologies). + +## Мережа {#networking} + +Сам по собі Kubernetes не містить мережі, які знається на зонах. Ви можете використовувати [мережевий втулок](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) для налаштування мережі кластера, і це мережеве рішення може мати елементи, специфічні для зони. Наприклад, якщо ваш постачальник хмари підтримує служби з `type=LoadBalancer`, балансир може відправляти трафік лише до Podʼів, які працюють в тій же зоні, що й елемент балансування навантаження, який обробляє ці зʼєднання. Перевірте документацію вашого постачальника хмари для отримання деталей. + +Для власних або для розгортань на локальних обчислювальних ресурсах застосовуються подібні міркування. Поведінка {{< glossary_tooltip text="Service" term_id="service" >}} та {{< glossary_tooltip text="Ingress" term_id="ingress" >}}, включаючи обробку +різних зон відмов, різняться залежно від того, як саме налаштований ваш кластер. + +## Відновлення після відмов {#fault-recovery} + +При налаштуванні кластера можливо вам також доведеться розглядати можливість та способи відновлення обслуговування, якщо всі зони відмов у регіоні вийдуть з ладу одночасно. Наприклад, чи ви покладаєтесь на те, що принаймні один вузол може виконувати Podʼи в зоні? Переконайтеся, що будь-які роботи з ремонту, критичні для кластера, не покладаються на те, що у вашому кластері є принаймні один справний вузол. Наприклад: якщо всі вузли несправні, вам може знадобитися запустити роботу з ремонту з особливим {{< glossary_tooltip text="Toleration" term_id="toleration" >}}, щоб ремонт міг завершити роботу, щоб принаймні один вузол був в робочому стані. + +Kubernetes не має відповіді на це виклик; однак це щось, що варто враховувати. + +## {{% heading "whatsnext" %}} + +Щоб дізнатися, як планувальник розміщує Podʼи в кластері, дотримуючись налаштованих обмежень, відвідайте [Планування та вивільнення ресурсів](/docs/concepts/scheduling-eviction/). diff --git a/content/uk/docs/setup/best-practices/node-conformance.md b/content/uk/docs/setup/best-practices/node-conformance.md new file mode 100644 index 0000000000000..923dfc24052f4 --- /dev/null +++ b/content/uk/docs/setup/best-practices/node-conformance.md @@ -0,0 +1,75 @@ +--- +reviewers: +- Random-Liu +title: Перевірка налаштувань вузла +weight: 30 +--- + +## Тест відповідності вузла {#node-conformance-test} + +*Тест відповідності вузла* — це контейнеризований тестовий фреймворк, який надає системну перевірку та тестування функціональності для вузла. Тест перевіряє, чи вузол відповідає мінімальним вимогам Kubernetes; вузол, який успішно проходить тест, має відповідати вимогам для приєднання до кластера Kubernetes. + +## Передумови вузла {#node-prerequisite} + +Для запуску тесту відповідності вузла вузол повинен відповідати тим же передумовам, що й стандартний вузол Kubernetes. Принаймні, на вузлі повинні бути встановлені наступні служби: + +* Сумісні з CRI середовища виконання контейнерів, такі як Docker, Containerd та CRI-O +* Kubelet + +## Запуск тесту відповідності вузла {#running-node-conformance-test} + +Для запуску тесту відповідності вузла виконайте наступні кроки: + +1. Визначте значення параметра `--kubeconfig` для kubelet, наприклад: `--kubeconfig=/var/lib/kubelet/config.yaml`. Оскільки тестовий фреймворк запускає локальну панель управління для тестування kubelet, використовуйте `http://localhost:8080` як URL API-сервера. Є ще деякі інші параметри командного рядка kubelet, які можна використовувати: + * `--cloud-provider`: Якщо ви використовуєте `--cloud-provider=gce`, ви повинні видалити прапорець для запуску тесту. + +2. Запустіть тест відповідності вузла за допомогою команди: + +```shell +# $CONFIG_DIR — це шлях до файлу маніфеста под вашого Kubelet. +# $LOG_DIR — це шлях для виведення результатів тесту. +sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + registry.k8s.io/node-test:0.2 +``` + +## Запуск тесту відповідності вузла для інших архітектур {#running-node-conformance-test-for-other-architectures} + +Kubernetes також надає образи Docker для тестування відповідності вузлів для інших архітектур: + + Архітектура | Образи | +---------------|:------------------------:| + amd64 | node-test-amd64 | + arm | node-test-arm | + arm64 | node-test-arm64 | + +## Запуск конкретних тестів {#running-selected-test} + +Щоб запустити конкретні тести, перезапишіть змінну середовища `FOCUS` регулярним виразом тестів, які ви хочете запустити. + +```shell +sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + -e FOCUS=MirrorPod \ # Запустити тільки тест MirrorPod + registry.k8s.io/node-test:0.2 +``` + +Щоб пропустити певні тести, перезапишіть змінну середовища `SKIP` регулярним виразом тестів, які ви хочете пропустити. + +```shell +sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + -e SKIP=MirrorPod \ + + # Запустити всі тести відповідності, але пропустити тест MirrorPod + registry.k8s.io/node-test:0.2 +``` + +Тест відповідності вузла — це контейнеризована версія [e2e тесту вузла](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md). Стандартно запускаються всі тести відповідності. + +Теоретично ви можете запустити будь-який e2e тест вузла, якщо налаштуєте контейнер та правильно змонтуєте необхідні томи. Але **настійно рекомендується виключно використовувати тести відповідності**, оскільки для запуску тестів, що не є тестами відповідності, потрібна набагато складніша конфігурація. + +## Обмеження {#caveats} + +* Тест залишає на вузлі деякі образи Docker, включаючи образ тесту відповідності вузла та образи контейнерів, що використовуються у функціональному тесту. +* Тест залишає на вузлі мертві контейнери. Ці контейнери створюються під час функціонального тесту. diff --git a/content/uk/docs/setup/learning-environment/_index.md b/content/uk/docs/setup/learning-environment/_index.md index 879c4eb9f6c7f..d933051e4d857 100644 --- a/content/uk/docs/setup/learning-environment/_index.md +++ b/content/uk/docs/setup/learning-environment/_index.md @@ -1,5 +1,34 @@ --- -# title: Learning environment -title: Навчальне оточення +title: Навчальне середовище weight: 20 --- + + + \ No newline at end of file diff --git a/content/uk/docs/setup/production-environment/_index.md b/content/uk/docs/setup/production-environment/_index.md index 019f4676b7bf6..cf591b2e683f7 100644 --- a/content/uk/docs/setup/production-environment/_index.md +++ b/content/uk/docs/setup/production-environment/_index.md @@ -1,7 +1,122 @@ --- # title: Production environment # description: Create a production-quality Kubernetes cluster -title: Прод оточення +title: Операційне середовище weight: 30 no_list: true --- + + + +Кластер Kubernetes виробничої якості вимагає планування та підготовки. Якщо ваш кластер Kubernetes повинен запускати критичні робочі навантаження, він повинен бути налаштований, щоб бути стійким та витривалим. На цій сторінці пояснюються кроки, які ви можете зробити для створення готового до промислової експлуатації кластера або для переведення наявного кластера в операційне середовище. Якщо ви вже знайомі з налаштуванням операційного середовища та хочете отримати посилання, перейдіть до розділу [Що далі](#what-s-next). + + + +## Аспекти промислової експлуатації {#production-considerations} + +Зазвичай операційне середовище кластера Kubernetes накладає суворіші вимоги, ніж навчальне середовище, середовище для розробки та тестування. Операційне середовище може вимагати захищеного доступу для багатьох користувачів, високого рівня доступності та ресурсів для пристосування до змін вимог. + +Коли ви визначаєте, де ви хочете розмістити ваше операційне середовище Kubernetes (у себе чи в хмарі) та рівень управління, який ви хочете взяти на себе або передати іншим, розгляньте, як ваші вимоги до кластера Kubernetes впливають на такі питання: + +- *Доступність*: Одномашинне [навчальне середовище](/docs/setup/#learning-environment) Kubernetes має один точку відмови. Створення високодоступного кластера передбачає: + - Відділення панелі управління від робочих вузлів. + - Реплікація компонентів панелі управління на кілька вузлів. + - Балансування трафіку до {{< glossary_tooltip term_id="kube-apiserver" text="API-сервера" >}} кластера. + - Наявність достатньої кількості робочих вузлів або можливість швидкої їх швидкого введення в експлуатацію залежно від змін в робочому навантажені. + +- *Масштабування*: Якщо ви очікуєте, що ваше операційне середовище Kubernetes отримає стабільний обсяг запитів, ви, можливо, зможете налаштувати потрібну потужність і на цьому зупинитись. Однак, якщо ви очікуєте, що попит зростатиме з часом або раптово змінюватиметься на основі таких чинників, як сезонність чи спеціальні події, вам потрібно розробити план щодо масштабування для обробки зростаючого навантаження від збільшення запитів до панелі управління та робочих вузлів або масштабування вниз для зменшення простою ресурсів, які більше не потрібні. + +- *Безпека та управління доступом*: У вас є повні привілеї адміністратора на власному навчальному кластері Kubernetes. Але спільні кластери з важливими навантаженнями та більше ніж одним або двома користувачами вимагають більш витонченого підходу до того, хто і що може отримати доступ до ресурсів кластера. Ви можете використовувати систему управління доступом на основі ролей ([RBAC](/docs/reference/access-authn-authz/rbac/)) та інші механізми безпеки, щоб переконатися, що користувачі та завдання можуть отримати доступ до необхідних ресурсів, підтримуючи завдання та сам кластер у безпеці. Ви можете встановлювати обмеження на ресурси, до яких користувачі та завдання мають доступ, керуючи [політиками](/docs/concepts/policy/) та [ресурсами контейнерів](/docs/concepts/configuration/manage-resources-containers/). + +Перш ніж створювати власне операційне середовище Kubernetes, розгляньте можливість передачі деяких частин або всієї цієї роботи [постачальникам "хмарних рішень під ключ"](https://kubernetes.io/docs/setup/production-environment/turnkey-solutions/) або іншим [партнерам Kubernetes](https://kubernetes.io/partners/). Серед варіантів: + +- *Serverless*: Просто виконуйте робочі завдання на обладнанні сторонніх постачальників без управління кластером взагалі. Вам доведеться платити за такі речі, як використання процесора, памʼяті та дискові запити. +- *Керування панеллю управління*: Дозвольте постачальнику управляти масштабуванням та доступністю панелі управління кластера, а також розвʼязувати питання щодо застосування латок та встановлення оновлень. +- *Керування робочими вузлами*: Налаштуйте пули вузлів для задоволення ваших потреб, а потім постачальник забезпечить наявність цих вузлів та готовність виконувати оновлення за необхідності. +- *Інтеграція*: Є постачальники, які інтегрують Kubernetes з іншими сервісами, які вам можуть знадобитися, такими як сховища, реєстри контейнерів, методи автентифікаційні та інструменти розробки. + +Чи ви будуєте виробничий кластер Kubernetes самостійно чи співпрацюєте з партнерами, перегляньте наступні розділи, щоб оцінити ваші потреби стосовно *панелі управління кластером*, *робочих вузлів*, *доступу користувачів* та *ресурсів для виконання робочих навантажень*. + +## Налаштування промислового кластера {#production-cluster-setup} + +У виробничому кластері Kubernetes, панель управління управляє кластером за допомогою служб, які можуть бути розподілені по різних компʼютерах різними способами. Кожен робочий вузол являти собою окремий обʼєкт, який налаштований для запуску Podʼів Kubernetes. + +### Панель управління промислового кластера {#production-control-plane} + +Найпростіший кластер Kubernetes має панель управління та всі робочі вузли на одному компʼютері. Ви можете розширювати це оточення додаючи робочі вузли, як показано на схемі [Компоненти Kubernetes](/docs/concepts/overview/components/). Якщо передбачається, що кластер має бути доступним впродовж короткого проміжку часу, або може бути знехтуваним у разі збою, це має відповідати вашим потребам. + +Якщо вам потрібен постійний та високодоступний кластер, розгляньте способи розширення панелі управління. За проєктом, служби управління на одному вузлі, який працює на одній машині, не є високодоступними. Якщо важливо, щоб кластер працював переконатися, що його можна відновити у випадку проблем, розгляньте наступні кроки: + +- *Оберіть інструменти розгортання*: + Ви можете розгорнути панель управління використовуючи інструменти, такі як: kubeadm, kops, kubespray. Перегляньте [Встановлення Kubernetes за допомогою інструментів розгортання](/docs/setup/production-environment/tools/), щоб дізнатись порад щодо розгортання промислового кластера за допомогою цих методів. Різні [середовища виконання контейнерів](/docs/setup/production-environment/container-runtimes/) доступні для використання у вашому розгортанні. +- *Керування сертифікатами*: + Безпечний звʼязок між службами панелі управління реалізується за допомогою сертифікатів. Сертифікати автоматично генеруються під час розгортання, або ви можете генерувати їх за допомогою власного центру сертифікації. Дивіться [Вимоги та сертифікати PKI](/docs/setup/best-practices/certificates/). +- *Налаштування балансування навантаженням apiserverʼа*: + Налаштуйте балансувальник навантаження, щоб розподілити зовнішні запити до екземплярів apiserver, що працюють на різних вузлах. Дивіться [Створення зовнішнього балансувальника навантаження](/docs/tasks/access-application-cluster/create-external-load-balancer/). +- *Відділіть та робіть резервні копії служби etcd*: + Служба etcd може або працювати на тій же машині, що і панель управління, або працювати на окремих вузлах, для підвищення захищеності та доступності. Оскільки etcd зберігає дані конфігурації кластера, важливо робити резервні копії цих даних регулярно, щоб переконатись, що вони можуть бути відновлені в разі потреби. Дивіться [ЧаПи etcd](https://etcd.io/docs/v3.5/faq/) щодо налаштування та використання etcd. Дивіться [Керування кластерами etcd Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) та [Налаштування високої доступності кластера etcd з kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/). +- *Створення множинної панелі управління*: + Для забезпечення високої доступності панелі управління, необхідно відмовитися від обмеження щодо її знаходження на одні машині. Якщо служби панелі управління запускаються службою init (такої як systemd), кожна служба повинна працювати як мінімум на трьох машинах. Однак запуск служб панелі управління як Podʼів в Kubernetes гарантує, що реплікована кількість служб, яку ви вказуєте, завжди буде доступною. Планувальник повинен бути стійким до помилок, але не високодоступним. Деякі засоби розгортання налаштовують алгоритм консенсусу [Raft](https://raft.github.io/) для вибору лідера служб Kubernetes. Якщо основна служба відмовляється, інша служба обирає себе лідером і перебирає контроль на себе. +- *Охоплюйте кілька зон*: + Якщо важливо, щоб ваш кластер був доступним у будь-який час, розгляньте можливість створення кластера, який працює у кількох центрах обробки даних, відомих як зони в хмарних середовищах. Групи зон називаються регіонами. Розподіливши кластер по кількох зонах в одному регіоні, ви можете покращити ймовірність того, що ваш кластер продовжуватиме працювати, навіть якщо одна зона стане недоступною. Дивіться [Робота у кількох зонах](/docs/setup/best-practices/multiple-zones/). +- *Керуйте тривалими функціями*: + Якщо ви плануєте тримати свій кластер протягом тривалого часу, є завдання, які вам потрібно виконати для забезпечення його самовідновлення та безпеки. Наприклад, якщо ви встановили кластер за допомогою kubeadm, є інструкції, які допоможуть вам з [керуванням сертифікатами](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) та [оновленням кластерів kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). Дивіться [Адміністрування кластера](/docs/tasks/administer-cluster/) для отримання більш докладного списку адміністративних завдань Kubernetes. + +Щоб дізнатися про доступні опції при запуску служб панелі управління, дивіться сторінки компонентів [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/), [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) та [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). Для прикладів конфігурації високої доступності панелі управління дивіться [Варіанти високодоступної топології](/docs/setup/production-environment/tools/kubeadm/ha-topology/), [Створення високодоступних кластерів за допомогою kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) та [Експлуатація кластерів etcd для Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/). Для інформації щодо плану створення резервних копій etcd дивіться [Резервне копіювання кластера etcd](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster). + +### Робочі вузли промислового кластера {#production-worker-nodes} + +Робочі навантаження повинні бути стійкими, і все, на що вони покладаються, має бути стійким (наприклад, CoreDNS). Незалежно від того, чи керуєте ви власною панеллю управління, чи хмарний провайдер робить це за вас, вам все одно потрібно подумати, як ви хочете керувати своїми робочими вузлами (також їх просто називають вузлами). + +- *Налаштування вузлів*: Вузли можуть бути фізичними або віртуальними машинами. Якщо ви хочете створювати та управляти власними вузлами, ви можете встановити підтримувану операційну систему, додати та запустити відповідні [Служби вузлів](/docs/concepts/overview/components/#node-components). Розгляньте такі питання: + - Вимоги вашого робочого навантаження при налаштуванні вузлів, маючи відповідну кількість памʼяті, процесора та швидкості дискових операцій та обʼєму сховища. + - Чи підійдуть загальні компʼютерні системи, чи у вас є завдання, які потребують процесорів GPU, вузлів з операційною системою Windows або ізоляції віртуальних машин. +- *Підтвердження вузлів*: Дивіться [Правильне налаштування вузлів](/docs/setup/best-practices/node-conformance/) для інформації про те, як переконатися, що вузол відповідає вимогам для приєднання до кластера Kubernetes. +- *Додавання вузлів до кластера*: Якщо ви керуєте своїм власним кластером, ви можете додавати вузли, налаштовуючи свої власні машини та додаючи їх вручну або реєструючи їх в службі apiserver кластера. Диввться розділ [Вузли](/docs/concepts/architecture/nodes/) для інформації щодо того, як налаштувати Kubernetes для додавання вузлів цими способами. +- *Масштабування вузлів*: Майте план розширення потужності вашого кластера на майбутнє. Дивіться [Рекомендації для великих кластерів](/docs/setup/best-practices/cluster-large/), щоб визначити, скільки вузлів вам потрібно, виходячи з кількості подів і контейнерів, які вам потрібно запустити. Якщо ви керуєте вузлами самостійно, це може означати придбання та встановлення власного фізичного обладнання. +- *Автомасштаб вузлів*: Більшість хмарних провайдерів підтримують [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) для заміни непрацюючих вузлів або збільшення та зменшення кількості вузлів за потреби. Див. [Часті питання](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) щодо роботи автомасштабування та [Розгортання](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) щодо його реалізації різними хмарними провайдерами. Для внутрішньохмарних рішень існують деякі віртуалізаційні платформи, які можна скриптувати для запуску нових вузлів за потреби. +- *Налаштування перевірок стану вузлів*: Для важливих завдань важливо переконатися, що Nodeʼи та Podʼи, які працюють на цих вузлах, є працездатними. За допомогою демона [Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) ви можете забезпечити працездатність своїх вузлів. + +### Доступ користувачів до промислового кластера {#production-user-management} + +У промисловій експлуатації ви можете перейти від моделі, де ви невелика група людей, що має доступ до кластера, до, де потенційно можуть бути десятки або сотні людей. У навчальному середовищі або прототипі платформи у вас може бути єдиний адміністративний обліковий запис для всього, що ви робите. У промисловій експлуатації вам знадобиться більше облікових записів з різними рівнями доступу до різних просторів імен. + +Беручи до уваги кластер промислової експлуатації, вирішуючи, як ви хочете дозволити вибірковий доступ іншим користувачам. Зокрема, вам потрібно вибрати стратегії для перевірки ідентичності тих, хто намагається отримати доступ до вашого кластера (автентифікація) та вирішити, чи мають вони дозволи робити те, що вони просять (авторизація): + +- *Автентифікація*: apiserver може автентифікувати користувачів за допомогою клієнтських сертифікатів, маркерів доступу, проксі автентифікації або базової HTTP-автентифікації. Ви можете вибрати методи автентифікації, які ви хочете використовувати. За допомогою втулків apiserver може використовувати наявні методи автентифікації вашої організації, такі як LDAP або Kerberos. Див. [Автентифікація](/docs/reference/access-authn-authz/authentication/) для опису різних методів автентифікації користувачів Kubernetes. + +- *Авторизація*: Коли ви починаєте авторизовувати звичайних користувачів, ви, ймовірно, вибератиме між авторизацією RBAC та ABAC. Див. [Огляд авторизації](/docs/reference/access-authn-authz/authorization/) для ознайомлення з різними режимами авторизації облікових записів користувачів (а також доступу облікових записів служб до вашого кластера): + + - *Контроль доступу на основі ролей* ([RBAC](/docs/reference/access-authn-authz/rbac/)): Дозволяє вам призначати доступ до вашого кластера, виставляючи конкретні набори дозволів автентифікованим користувачам. Дозволи можуть бути призначені для конкретного простору імен (Role) або по всьому кластеру (ClusterRole). Потім, використовуючи RoleBindings та ClusterRoleBindings, ці дозволи можна призначити певним користувачам. + - *Контроль доступу на основі атрибутів* ([ABAC](/docs/reference/access-authn-authz/abac/)): Дозволяє вам створювати політики на основі атрибутів ресурсів у кластері та дозволяти чи відмовляти у доступі на основі цих атрибутів. Кожен рядок файлу політики ідентифікує властивості версії (apiVersion та kind) та вказувати у властивостях spec збіг з субʼєктом (користувачем або групою), властивістю ресурсу, властивості не-ресурсу (/version або /apis) або readonly. Дивіться [Приклади](/docs/reference/access-authn-authz/abac/#examples) для отримання деталей. + +Якщо ви налаштовуєте автентифікацію та авторизацію на своєму промисловому кластері Kubernetes, ось кілька речей, які варто врахувати: + +- *Встановлення режиму авторизації*: + Коли сервер API Kubernetes ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)) запускається, підтримувані режими автентифікації повинні бути встановлені за допомогою прапорця *--authorization-mode*. Наприклад, цей прапорець у файлі *kube-adminserver.yaml* (в */etc/kubernetes/manifests*) може бути встановлений у значення Node, RBAC. Це дозволить авторизацію Node та RBAC для автентифікованих запитів. +- *Створення сертифікатів користувача та привʼязка ролей (RBAC)*: + Якщо ви використовуєте авторизацію RBAC, користувачі можуть створювати CertificateSigningRequest (CSR), які можуть бути підписати CA кластера. Потім ви можете привʼязувати Roles та ClusterRoles до кожного користувача. Дивіться [Запити на підпис сертифікатів](/docs/reference/access-authn-authz/certificate-signing-requests/) для отримання деталей. +- *Створення політик, що комбінують атрибути (ABAC)*: + Якщо ви використовуєте авторизацію ABAC, ви можете призначати комбінації атрибутів для формування політик для авторизації обраних користувачів або груп для доступу до певних ресурсів (наприклад, Podʼів), просторів імен або apiGroup. Докладніше дивіться [Приклади](/docs/reference/access-authn-authz/abac/#examples). +- *Використання контролерів вхідних даних*: Додаткові форми авторизації для запитів, які можуть надходити через сервер API, включають [Автентифікацію токенів за допомогою вебхуків](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication). Вебхуки та інші спеціальні типи авторизації повинні бути увімкнені додаванням [Контролерів вхідних даних (Admission Controllers)](/docs/reference/access-authn-authz/admission-controllers/) до сервера API. + +## Встановлення лімітів для робочих навантажень {#set-limits-on-workloads-resources} + +Вимоги від виробничих навантажень можуть створювати тиск як всередині, так і поза панеллю управління Kubernetes. Розгляньте ці пункти при налаштуванні лімітів для робочого навантаження вашого кластера: + +- *Встановіть обмеження простору імен*: + Встановіть квоти в кожному просторі імен для речей, таких як памʼять та ЦП. Дивіться [Керування памʼяттю, ЦП та ресурсами API](/docs/tasks/administer-cluster/manage-resources/) для отримання деталей. Ви також можете встановити [Ієрархічні простори імен](/blog/2020/08/14/introducing-hierarchical-namespaces/) для успадкування обмежень. +- *Підготуйтесь до вимог DNS*: + Якщо ви очікуєте, що робочі навантаження масштабуються, ваша служба DNS повинна бути готовою масштабуватися також. Дивіться [Масштабування служби DNS в кластері](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). +- *Створюйте додаткові облікові записи служб*: + Облікові записи користувачів визначають, що користувачі можуть робити в кластері, тоді як обліковий запис служби визначає доступ до Podʼів у межах певного простору імен. Стандартно Pod приймає обліковий запис типової служби у своєму просторі імен. Дивіться [Керування обліковими записами служб](/docs/reference/access-authn-authz/service-accounts-admin/) для інформації про створення нового облікового запису служби. Наприклад, ви можете: + - Додати секрети, які Pod може використовувати для витягування образів з вказаного реєстру контейнерів. Дивіться [Налаштування облікових записів служби для подів](/docs/tasks/configure-pod-container/configure-service-account/) для прикладу. + - Призначте дозволи RBAC обліковому запису служби. Дивіться [Дозволи облікового запису служби](/docs/reference/access-authn-authz/rbac/#service-account-permissions) для отримання деталей. + +## {{% heading "whatsnext" %}} + +- Вирішить, чи хочете ви будувати свій власний промисловий кластер Kubernetes чи отримати його від доступних [хмарних рішень під ключ](/docs/setup/production-environment/turnkey-solutions/) чи [партнерів Kubernetes](/partners/). +- Якщо ви вибираєте створення власного кластера, сплануйте, як ви хочете розвʼязувати питання [сертифікатів](/docs/setup/best-practices/certificates/) та налаштувати високу доступність для функцій, таких як [etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) та [API сервера](/docs/setup/production-environment/tools/kubeadm/ha-topology/). +- Виберіть методи розгортання з [kubeadm](/docs/setup/production-environment/tools/kubeadm/), [kops](https://kops.sigs.k8s.io/) чи [Kubespray](https://kubespray.io/). +- Налаштуйте управління користувачами, визначивши свої методи [автентифікації](/docs/reference/access-authn-authz/authentication/) та [авторизації](/docs/reference/access-authn-authz/authorization/). +- Підготуйтеся до робочих навантажень застосунків, налаштувавши [обмеження ресурсів](/docs/tasks/administer-cluster/manage-resources/), [автомасштабування DNS](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) та [облікові записи служб](/docs/reference/access-authn-authz/service-accounts-admin/). diff --git a/content/uk/docs/setup/production-environment/container-runtimes.md b/content/uk/docs/setup/production-environment/container-runtimes.md new file mode 100644 index 0000000000000..140573be1d0ec --- /dev/null +++ b/content/uk/docs/setup/production-environment/container-runtimes.md @@ -0,0 +1,277 @@ +--- +reviewers: +- vincepri +- bart0sh +title: Середовище виконання контейнерів +content_type: concept +weight: 20 +--- + + +{{% dockershim-removal %}} + +Для того, щоб запускати Podʼи на кожному вузлі кластера, потрібно встановити +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. Ця сторінка надає огляд того, які компоненти беруть в цьому участь, та описує повʼязані завдання для налаштування вузлів. + +Kubernetes {{< skew currentVersion >}} вимагає використання runtime, який відповідає +специфікації {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI). + +Дивіться [Підтримка версій CRI](#cri-versions) для отримання додаткової інформації. + +Ця сторінка містить огляд того, як використовувати кілька поширених середовищ виконання контейнерів з Kubernetes. + +- [containerd](#containerd) +- [CRI-O](#cri-o) +- [Docker Engine](#docker) +- [Mirantis Container Runtime](#mcr) + +{{< note >}} +Релізи Kubernetes до v1.24 включно мали безпосередню інтеграцію з Docker Engine, використовуючи компонент під назвою _dockershim_. Ця безпосередня інтеграція більше не є частиною Kubernetes (про що було [оголошено](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) у випуску v1.20). Ви можете ознайомитись з матеріалами статті [Перевірте, чи вас стосується видалення Dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/), щоб зрозуміти, як це видалення може вплинути на вас. Щоб дізнатися про міграцію з dockershim, перегляньте +[Міграція з dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/). + +Якщо ви використовуєте версію Kubernetes іншу, ніж v{{< skew currentVersion >}}, перевірте документацію для цієї версії. +{{< /note >}} + + + +## Встановлення та налаштування передумов {#install-and-configure-prerequisites} + +Наведені нижче кроки застосовують загальні налаштування для вузлів Kubernetes у Linux. + +Ви можете пропустити певні налаштування, якщо ви впевнені, що вони вам не потрібні. + +Для отримання додаткової інформації дивіться [Вимоги мережевих втулків](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) або документацію для вашого конкретного середовища виконання контейнерів. + +### Переспрямування IPv4 трафіку та надання дозволів iptables бачити трафік, що проходить через міст {#forward-ipv4-and-letting-iptables-see-bridged-traffic} + +Виконайте наведені нижче інструкції: + +```bash +cat <}} для обмеження ресурсів, які виділяються процесам. + +І {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, і відповідні середовища виконання контейнерів потребують взаємодії з cgroup для [управління ресурсами для Podʼів та контейнерів](/docs/concepts/configuration/manage-resources-containers/) та встановлення ресурсів, таких як обсяг памʼяті та обчислювальних ресурсів центрального процесора, а також їх обмежень. Щоб взаємодіяти з cgroup, kubelet та середовище виконання контейнерів повинні використовувати _драйвер cgroup_. Важливо, щоб kubelet та середовище виконання контейнерів використовували один і той самий драйвер cgroup та були налаштовані однаково. + +Існують два доступні драйвери cgroup: + +- [`cgroupfs`](#cgroupfs-cgroup-driver) +- [`systemd`](#systemd-cgroup-driver) + +### Драйвер cgroupfs {#cgroupfs-cgroup-driver} + +Драйвер `cgroupfs` є [стандартним драйвером cgroup в kubelet](/docs/reference/config-api/kubelet-config.v1beta1). Коли використовується драйвер `cgroupfs`, kubelet та середовище виконання контейнерів безпосередньо взаємодіють +з файловою системою cgroup для їх налаштування. + +Драйвер `cgroupfs` **не** рекомендується використовувати, коли [systemd](https://www.freedesktop.org/wiki/Software/systemd/) є системою ініціалізації, оскільки systemd очікує наявності єдиного менеджера cgroup в системі. Крім того, якщо використовуєте [cgroup v2](/docs/concepts/architecture/cgroups), використовуйте драйвер `systemd` cgroup замість `cgroupfs`. + +### Драйвер cgroup системи systemd {#systemd-cgroup-driver} + +Коли [systemd](https://www.freedesktop.org/wiki/Software/systemd/) вибрано як систему ініціалізації в дистрибутиві Linux, процес ініціалізації створює і використовує кореневу групу cgroup (`cgroup`) та діє як менеджер cgroup. + +systemd тісно інтегрований з cgroup та розміщує по одній cgroup на кожному юніті systemd. В результаті, якщо ви використовуєте `systemd` як систему ініціалізації з драйвером `cgroupfs`, система отримує два різних менеджери cgroup. + +Наявність двох менеджерів cgroup призводить до двох видів доступних та використаних ресурсів в системі. У деяких випадках вузли, які налаштовані на використання `cgroupfs` для kubelet та середовище виконання контейнерів, але використовують `systemd` для інших процесів, стають нестійкими при зростанні тиску на ресурси. + +Підхід до помʼякшення цієї нестійкості — використовувати `systemd` як драйвер cgroup для kubelet та середовище виконання контейнерів, коли `systemd` вибрано системою ініціалізації. + +Щоб встановити `systemd` як драйвер cgroup, відредагуйте в [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) опцію `cgroupDriver` та встановіть її в `systemd`. Наприклад: + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +... +cgroupDriver: systemd +``` + +{{< note >}} +Починаючи з v1.22 і пізніше, при створенні кластера за допомогою kubeadm, якщо користувач не встановить поле `cgroupDriver` в `KubeletConfiguration`, kubeadm встановлює типове значення — `systemd`. +{{< /note >}} + +У Kubernetes v1.28, з увімкненою функцією `KubeletCgroupDriverFromCRI` у [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) і середовищем виконання контейнерів, яке підтримує `RuntimeConfig` CRI RPC, kubelet автоматично визначає відповідний драйвер cgroup з runtime, та ігнорує налаштування `cgroupDriver` у конфігурації kubelet. + +Якщо ви конфігуруєте `systemd` як драйвер cgroup для kubelet, вам також слід налаштувати `systemd` як драйвер cgroup для середовища виконання контейнерів. Дивіться документацію для вашого середовища виконання контейнерів для отримання докладних інструкцій. Наприклад: + +- [containerd](#containerd-systemd) +- [CRI-O](#cri-o) + +{{< caution >}} +Зміна драйвера cgroup вузла, який приєднався до кластера, — це чутлива операція. Якщо kubelet створював Podʼи, використовуючи семантику одного драйвера cgroup, зміна середовища виконання контейнерів на інший драйвер cgroup може спричинити помилки при спробі повторного створення пісочниці Pod для таких наявних Podʼів. Перезапуск kubelet може не вирішити таких помилок. + +Якщо у вас є автоматизація, яка дозволяє це зробити, замініть вузол іншим з оновленою конфігурацією, або перевстановіть його за допомогою автоматизації. +{{< /caution >}} + +### Міграція на драйвер `systemd` в кластерах, що керуються kubeadm {#migrating-to-systemd-driver-in-kubeadm-managed-clusters} + +Якщо ви хочете мігрувати на драйвер `systemd` cgroup в кластерах, що керуються kubeadm, дотримуйтеся рекомендацій [налаштування драйвера cgroup](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/). + +## Підтримка версій CRI {#cri-versions} + +Ваше середовище виконання контейнерів повинне підтримувати принаймні версію v1alpha2 інтерфейсу контейнера. + +Kubernetes [починаючи з v1.26](/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal) працює _тільки_ з v1 CRI API. Попередні версії типово +використовують версію v1, проте, якщо середовище виконання контейнерів не підтримує v1 API, kubelet перемкнеться на використання (застарілої) версії API v1alpha2. + +## Середовища виконання контейнерів {#container-runtimes} + +{{% thirdparty-content %}} + +### containerd + +У цьому розділі описані необхідні кроки для використання containerd як середовища виконання контейнерів (CRI). + +Щоб встановити containerd на вашу систему, дотримуйтеся інструкцій з +[Початок роботи з containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md). Поверніться до цього кроку, якщо ви створили файл конфігурації `config.toml`. + +{{< tabs name="Finding your config.toml file" >}} +{{% tab name="Linux" %}} +Ви можете знайти цей файл тут: `/etc/containerd/config.toml`. +{{% /tab %}} +{{% tab name="Windows" %}} +Ви можете знайти цей файл тут: `C:\Program Files\containerd\config.toml`. +{{% /tab %}} +{{< /tabs >}} + +У Linux, типовий CRI-socket для containerd — `/run/containerd/containerd.sock`. У Windows, типова CRI-кінцева точка — `npipe://./pipe/containerd-containerd`. + +#### Налаштування драйвера cgroup `systemd` {#containerd-systemd} + +Щоб використовувати драйвер cgroup `systemd` в `/etc/containerd/config.toml` з `runc`, встановіть + +``` +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] + ... + [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] + + + SystemdCgroup = true +``` + +Драйвер cgroup `systemd` є рекомендованим, якщо ви використовуєте [cgroup v2](/docs/concepts/architecture/cgroups). + +{{< note >}} +Якщо ви встановили containerd за допомогою менеджера пакунків (наприклад, RPM або `.deb`, ви можете знайти, що втулок інтеграції CRI є типово вимкненим. + +Вам потрібно увімкнути підтримку CRI для того, щоб мати можливість використовувати containerd в Kubernetes. Переконайтеся, що `cri` немає в `disabled_plugins` у файлі `/etc/containerd/config.toml`; якщо вносили зміни до цього файлу, перезапустіть `containerd`. + +Якщо ви стикаєтесь з постійними збоями після початкового встановлення кластера або після встановлення CNI, скоріш за все конфігурація containerd отримана з пакунка містить несумісні налаштування. Зважте на перевстановлення налаштувань containerd, командою `containerd config default > /etc/containerd/config.toml` (див. [getting-strated.md](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#advanced-topics) і потім внесіть зміни в налаштування, як вказано вище. +{{< /note >}} + +Після внесення змін в перезавантажте containerd. + +```shell +sudo systemctl restart containerd +``` + +Використовуючи kubeadm, вручну налаштуйте [cgroup драйвер для kubelet](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configure-the-kubelet-cgroup-driver). + +У Kubernetes v1.28 ви можете увімкнути alpha-функцію автоматичного виявлення драйвера cgroup. Дивіться [systemd cgroup driver](#systemd-cgroup-driver) для отримання додаткової інформації. + +#### Перевизначення образу пісочниці (pause) {#override-pause-image-containerd} + +У вашій [конфігурації containerd](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) ви можете перевизначити образ, встановивши наступну конфігурацію: + +```toml +[plugins."io.containerd.grpc.v1.cri"] + sandbox_image = "registry.k8s.io/pause:3.2" +``` + +Можливо, вам доведеться також перезапустити `containerd`, якщо ви оновили файл конфігурації: `systemctl restart containerd`. + +Зверніть увагу, що це найкраща практика для `kubelet` оголошувати відповідний `pod-infra-container-image`. Якщо це не налаштовано, `kubelet` може намагатися прибрати образ `pause`. Триває робота над [закріпленням образу pause в containerd](https://github.com/containerd/containerd/issues/6352), щоб більше не вимагати цього налаштування в `kubelet`. + +### CRI-O + +У цьому розділі наведено необхідні кроки для встановлення CRI-O як середовища виконання контейнерів. + +Для встановлення CRI-O слід дотримуватися [Інструкцій з встановлення CRI-O](https://github.com/cri-o/cri-o/blob/main/install.md#readme). + +#### Драйвер cgroup {#cgroup-driver} + +CRI-O використовує стандартний драйвер cgroup, який ймовірно буде працювати добре для вас. Для перемикання на драйвер cgroupfs, відредагуйте `/etc/crio/crio.conf` або розмістіть конфігурацію у вигляді окремого файлу в `/etc/crio/crio.conf.d/02-cgroup-manager.conf`, наприклад: + +```toml +[crio.runtime] +conmon_cgroup = "pod" +cgroup_manager = "cgroupfs" +``` + +Важливо відзначити змінений `conmon_cgroup`, який повинен бути встановлений в значення `pod` при використанні CRI-O з `cgroupfs`. Зазвичай необхідно синхронізувати конфігурацію драйвера cgroup kubelet (зазвичай встановлюється за допомогою kubeadm) та CRI-O. + +У Kubernetes v1.28 можна ввімкнути автоматичне виявлення драйвера cgroup як альфа-функцію. Див. [драйвер cgroup systemd](#systemd-cgroup-driver) докладніше. + +Для CRI-O типовий сокет CRI — `/var/run/crio/crio.sock`. + +#### Перевизначення образу пісочниці (pause) {#override-pause-image-cri-o} + +У вашій [конфігурації CRI-O](https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md) ви можете встановити наступне значення конфігурації: + +```toml +[crio.image] +pause_image="registry.k8s.io/pause:3.6" +``` + +Цей параметр конфігурації підтримує перезавантаження конфігурації в реальному часі для застосування цих змін: `systemctl reload crio` або відсилання сигналу `SIGHUP` процесу `crio`. + +### Docker Engine {#docker} + +{{< note >}} +Ці інструкції передбачають, що ви використовуєте адаптер [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) для інтеграції Docker Engine з Kubernetes. +{{< /note >}} + +1. На кожному з ваших вузлів встановіть Docker для вашого дистрибутиву Linux; дивіться [Інсталяція Docker Engine](https://docs.docker.com/engine/install/#server). + +2. Встановіть [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd), дотримуючись інструкцій у репозиторій з вихідним кодом. + +Для `cri-dockerd` типовий сокет CRI — `/run/cri-dockerd.sock`. + +### Mirantis Container Runtime {#mcr} + +[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) є комерційно доступною реалізацією середовища виконання контейнерів, яка була раніше відома як Docker Enterprise Edition. + +Ви можете використовувати Mirantis Container Runtime з Kubernetes за допомогою відкритої реалізації компонента [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd), який входить до складу MCR. + +Для отримання докладнішої інформації щодо встановлення Mirantis Container Runtime +дивіться [посібник з розгортання MCR](https://docs.mirantis.com/mcr/20.10/install.html). + +Перевірте юніт systemd із назвою `cri-docker.socket`, щоб дізнатися шлях до сокета CRI. + +#### Перевизначення образу пісочниці (pause) {#override-pause-image-cri-dockerd-mcr} + +Адаптер `cri-dockerd` приймає аргумент командного рядка для зазначення образу контейнера, який слід використовувати як інфраструктурний контейнер для Podʼу («pause image»). Аргумент командного рядка, який слід використовувати — `--pod-infra-container-image`. + +## {{% heading "whatsnext" %}} + +Так само як і середовище виконання контейнерів, вашому кластеру знадобиться [втулок мережі](/docs/concepts/extend-kubernetes/networking/#how-to-implement-the-kubernetes-networking-model). diff --git a/content/uk/docs/setup/production-environment/tools/_index.md b/content/uk/docs/setup/production-environment/tools/_index.md index 8891b3ef4f3ed..909b1cd990684 100644 --- a/content/uk/docs/setup/production-environment/tools/_index.md +++ b/content/uk/docs/setup/production-environment/tools/_index.md @@ -1,5 +1,11 @@ --- -# title: Installing Kubernetes with deployment tools title: Встановлення Kubernetes за допомогою інструментів розгортання weight: 30 +no_list: true --- + +Існує багато методів та інструментів для встановлення власного промислового кластера Kubernetes. Наприклад: + +- [kubeadm](/docs/setup/production-environment/tools/kubeadm/) +- [kops](https://kops.sigs.k8s.io/): автоматизований інструмент для розгортання кластера. За навчальними матеріалами, найкращими практиками, параметрами конфігурації та інформацією про спільноту звертайтесь до [вебсайту `kOps`](https://kops.sigs.k8s.io/). +- [kubespray](https://kubespray.io/): набір плейбуків [Ansible](https://docs.ansible.com/), [інвентарю](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md#inventory), інструментів керування та знання про загальні завдання з конфігурації OS/Kubernetes. Ви можете звертатися до спільноти на каналі Slack [#kubespray](https://kubernetes.slack.com/messages/kubespray/). diff --git a/content/uk/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/uk/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md new file mode 100644 index 0000000000000..aa262666222ec --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -0,0 +1,164 @@ +--- +reviewers: +- sig-cluster-lifecycle +title: Налаштування компонентів за допомогою kubeadm API +content_type: concept +weight: 40 +--- + + + +Ця сторінка охоплює способи налаштування компонентів, які розгортаються за допомогою kubeadm. Для компонентів панелі управління можна використовувати прапорці у структурі `ClusterConfiguration` або патчі на рівні вузла. Для kubelet і kube-proxy ви можете використовувати `KubeletConfiguration` та `KubeProxyConfiguration`, відповідно. + +Всі ці опції можливі за допомогою конфігураційного API kubeadm. Докладніше про кожне поле в конфігурації ви можете дізнатися на наших [довідкових сторінках API](/docs/reference/config-api/kubeadm-config.v1beta3/). + +{{< note >}} +На жаль, наразі не підтримується налаштування розгортання CoreDNS за допомогою kubeadm. Вам слід вручну патчити {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} `kube-system/coredns` та перестворити {{< glossary_tooltip text="Pods" term_id="pod" >}} CoreDNS після цього. Альтернативно, ви можете пропустити типове розгортання CoreDNS та розгорнути свій варіант. Докладніше про це читайте у [Використання фаз ініціалізації з kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases). +{{< /note >}} + +{{< note >}} +Щоб переконфігурувати кластер, який вже був створений, дивіться [Переконфігурація кластера з kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure). +{{< /note >}} + + + +## Налаштовування панелі управління за допомогою прапорців у `ClusterConfiguration` {#customizing-the-control-plane-with-flags-in-clusterconfiguration} + +Обʼєкт конфігурації панелі управління kubeadm надає можливість користувачам перевизначати типові прапорці, що передаються компонентам панелі управління, таким як APIServer, ControllerManager, Scheduler та Etcd. Компоненти визначаються за допомогою наступних структур: + +- `apiServer` +- `controllerManager` +- `scheduler` +- `etcd` + +Ці структури містять спільне поле `extraArgs`, яке складається з пар `ключ: значення`. Щоб перевизначити прапорець для компонента панелі управління: + +1. Додайте відповідні `extraArgs` до вашої конфігурації. +2. Додайте прапорці до поля `extraArgs`. +3. Запустіть `kubeadm init` з `--config <ВАШ КОНФІГ YAML>`. + +{{< note >}} +Ви можете згенерувати обʼєкт `ClusterConfiguration` з типовими значеннями, використовуючи `kubeadm config print init-defaults` і зберігши вивід у файл на ваш вибір. +{{< /note >}} + +{{< note >}} +Обʼєкт `ClusterConfiguration` наразі є глобальним у кластерах kubeadm. Це означає, що будь-які прапорці, які ви додаєте, будуть застосовуватися до всіх екземплярів того самого компонента на різних вузлах. Щоб застосовувати індивідуальну конфігурацію для кожного компонента на різних вузлах, ви можете використовувати [патчі](#patches). +{{< /note >}} + +{{< note >}} +Дублювання прапорців (ключів) або передача одного й того ж прапорця `--foo` кілька разів наразі не підтримується. Для обходу цього обмеження слід використовувати [патчі](#patches). +{{< /note >}} + +### Прапорці APIServer {#apiserver-flags} + +Докладну інформацію див. у [довідковій документації для kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/). + +Приклад використання: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +kubernetesVersion: v1.16.0 +apiServer: + extraArgs: + anonymous-auth: "false" + enable-admission-plugins: AlwaysPullImages,DefaultStorageClass + audit-log-path: /home/johndoe/audit.log +``` + +### Прапорці планувальника {#scheduler-flags} + +Докладну інформацію див. у [довідковій документації для kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). + +Приклад використання: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +kubernetesVersion: v1.16.0 +scheduler: + extraArgs: + config: /etc/kubernetes/scheduler-config.yaml + extraVolumes: + - name: schedulerconfig + hostPath: /home/johndoe/schedconfig.yaml + mountPath: /etc/kubernetes/scheduler-config.yaml + readOnly: true + pathType: "File" +``` + +### Прапорці etcd {#etcd-flags} + +Докладну інформацію див. у [документації сервера etcd](https://etcd.io/docs/). + +Приклад використання: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +etcd: + local: + extraArgs: + election-timeout: 1000 +``` + +### Налаштування за допомогою патчів {#patches} + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +Kubeadm дозволяє передавати теку з файлами патчів в `InitConfiguration` та `JoinConfiguration` на окремих вузлах. Ці патчі можна використовувати як останній крок налаштування перед записом конфігурації компонента на диск. + +Ви можете передати цей файл в `kubeadm init` за допомогою `--config <ВАШ КОНФІГ YAML>`: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: InitConfiguration +patches: + directory: /home/user/somedir +``` + +{{< note >}} +Для `kubeadm init` ви можете передати файл, який містить як `ClusterConfiguration`, так і `InitConfiguration` розділені `---`. +{{< /note >}} + +Ви можете передати цей файл в `kubeadm join` за допомогою `--config <ВАШ КОНФІГ YAML>`: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: JoinConfiguration +patches: + directory: /home/user/somedir +``` + +Тека має містити файли з назвами `target[suffix][+patchtype].extension`. +Наприклад, `kube-apiserver0+merge.yaml` або просто `etcd.json`. + +- `target` може бути одним із `kube-apiserver`, `kube-controller-manager`, `kube-scheduler`, `etcd` та `kubeletconfiguration`. +- `patchtype` може бути одним із `strategic`, `merge` або `json` і вони повинні відповідати форматам патчів, [підтримуваним kubectl](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch). Типово `patchtype` — `strategic`. +- `extension` повинен бути або `json`, або `yaml`. +- `suffix` — це необовʼязковий рядок, який можна використовувати для визначення порядку застосування патчів за алфавітною послідовністю. + +{{< note >}} +Якщо ви використовуєте `kubeadm upgrade` для оновлення ваших вузлів kubeadm, вам слід знову надати ті самі патчі, щоб налаштування залишалося після оновлення. Для цього ви можете використовувати прапорець `--patches`, який повинен вказувати на той самий каталог. `kubeadm upgrade` зараз не підтримує структуру конфігурації API, +яка може бути використана для того самого. +{{< /note >}} + +## Налаштування kubelet {#kubelet} + +Щоб налаштувати kubelet, ви можете додати [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) поруч із `ClusterConfiguration` або `InitConfiguration`, розділеними `---` у тому самому файлі конфігурації. Цей файл потім можна передати до `kubeadm init`, і kubeadm застосує ту ж саму базову `KubeletConfiguration` для всіх вузлів у кластері. + +Для застосування конфігурації, специфічної для екземпляра, понад базовою `KubeletConfiguration`, ви можете використовувати ціль патчу [`kubeletconfiguration`](#patches). + +Також ви можете використовувати прапорці kubelet як перевизначення, передаючи їх у поле `nodeRegistration.kubeletExtraArgs`, яке підтримується як `InitConfiguration`, так і `JoinConfiguration`. Деякі прапорці kubelet є застарілими, тому перевірте їх статус у [довідковій документації kubelet](/docs/reference/command-line-tools-reference/kubelet), перш ніж їх використовувати. + +Додаткові деталі дивіться в розділі [Налаштування кожного kubelet у вашому кластері за допомогою kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration) + +## Налаштування kube-proxy {#customizing-kube-proxy} + +Щоб налаштувати kube-proxy, ви можете передати `KubeProxyConfiguration` поруч з `ClusterConfiguration` або `InitConfiguration` до `kubeadm init`, розділені `---`. + +Для отримання докладнішої інформації ви можете перейти на наші [сторінки API-посилань](/docs/reference/config-api/kubeadm-config.v1beta3/). + +{{< note >}} +kubeadm розгортає kube-proxy як {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}, що означає, що `KubeProxyConfiguration` буде застосовуватися до всіх екземплярів kube-proxy в кластері. +{{< /note >}} diff --git a/content/uk/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/uk/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md new file mode 100644 index 0000000000000..e7a1b9b5c1def --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -0,0 +1,505 @@ +--- +reviewers: +- sig-cluster-lifecycle +title: Створення кластера за допомогою kubeadm +content_type: task +weight: 30 +--- + + + + + +За допомогою `kubeadm` ви можете створити мінімальний кластер Kubernetes, який відповідає найкращим практикам. Фактично, ви можете використовувати `kubeadm` для налаштування кластерf, який успішно пройде [тести відповідності Kubernetes](/blog/2017/10/software-conformance-certification/). `kubeadm` також підтримує інші функції життєвого циклу кластера, такі як [bootstrap-токени](/docs/reference/access-authn-authz/bootstrap-tokens/) nf оновлення кластера. + +Інструмент `kubeadm` корисний у випадках, коли вам потрібен: + +- Простий спосіб спробувати Kubernetes, можливо, вперше. +- Спосіб для поточних користувачів автоматизувати налаштування кластера та протестувати свій застосунок. +- Компонент в інших екосистемах та/або інсталяторах із більшим + функціоналом. + +Ви можете встановлювати та використовувати `kubeadm` на різних машинах: на вашому ноутбуці, хмарних серверах, Raspberry Pi та інших. Незалежно від того, чи ви розгортаєте у хмарі, чи на власних серверах, ви можете інтегрувати `kubeadm` у системи постачання, такі як Ansible або Terraform. + +## {{% heading "prerequisites" %}} + +Для виконання цього керівництва вам потрібно мати: + +- Одну чи кілька машин з операційною системою, сумісною з deb/rpm, наприклад: Ubuntu чи CentOS. +- 2 ГБ або більше оперативної памʼяті на кожній машині — менше може призвести до обмежень для вашого застосунку. +- Принаймні 2 процесори на машині, яку ви використовуєте як вузол панелі управління. +- Повну мережеву доступність між усіма машинами в кластері. Ви можете використовувати як публічні, так і приватні мережі. + +Також вам потрібно використовувати версію `kubeadm`, яка може розгортати ту версію +Kubernetes, яку ви хочете використовувати у своєму новому кластері. + +[Політика підтримки версій та їх розбіжностей в Kubernetes](/docs/setup/release/version-skew-policy/#supported-versions) розповсюджується на `kubeadm` так само як і на Kubernetes в цілому. Перевірте цю політику, щоб дізнатися, які версії Kubernetes та `kubeadm` підтримуються. Ця сторінка написана для Kubernetes {{< param "version" >}}. + +Загальний стан функцій інструменту `kubeadm` — Загальна Доступність (GA). Деякі підфункції ще перебувають на стадії активної розробки. Реалізація створення кластера може трохи змінитися, в міру розвитку інструменту, але загальна реалізація повинна бути досить стабільною. + +{{< note >}} +Будь-які команди під `kubeadm alpha` за визначенням підтримуються на рівні альфа-версії. +{{< /note >}} + + + +## Мета {#Objectives} + +- Встановити Kubernetes з одною панеллю управління +- Встановити мережу для Podʼів в кластері, так щоб вони могли спілкуватися один з одним + +## Інструкції {#instructions} + +### Підготовка хостів {#preparing-the-hosts} + +#### Встановлення компонентів {#component-installation} + +Встановіть {{< glossary_tooltip term_id="container-runtime" text="середовище виконання контейнерів" >}} та `kubeadm` на всіх хостах. За докладними інструкціями та іншими вимогами звертайтесь до [Встановлення kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). + +{{< note >}} +Якщо ви вже встановили `kubeadm`, перегляньте перші два кроки документації +[Оновлення вузлів Linux](/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes) для отримання інструкцій щодо оновлення `kubeadm`. + +Під час оновлення `kubelet` перезапускається кожні кілька секунд, очікуючи в crashloop на команди від `kubeadm`. Цей цикл аварійного перезавантаження є очікуваним і нормальним. Після ініціалізації панелі управління `kubelet` працює в нормальному режимі. +{{< /note >}} + +#### Налаштування мережі {#network-setup} + +`kubeadm`, подібно до інших компонентів Kubernetes, намагається знайти доступну IP-адресу на мережевих інтерфейсах, повʼязаних із вказаним типовим шлюзом на хості. +Ця IP-адреса використовується для оголошення та/або прослуховування, яке виконується компонентом. + +Щоб дізнатися, яка це IP-адреса на Linux-хості, ви можете використовувати: + +```shell +ip route show # Перегляньте рядок, який починається з "default via" +``` + +{{< note >}} +Якщо на хості присутні два або більше стандартних шлюзи, компонент Kubernetes буде намагатися використовувати перший, який зустрічається із відповідною глобальною унікальною IP-адресою. При здійсненні цього вибору точний порядок шлюзів може відрізнятися між різними операційними системами та версіями ядра. +{{< /note >}} + +Компоненти Kubernetes не приймають мережевий інтерфейс як параметр, тому потрібно передавати власну IP-адресу як прапорець для всіх екземплярів компонентів, які потребують такої конфігурації. + +{{< note >}} +Якщо на хості відсутній стандартний шлюз і якщо не передано власну IP-адресу +компоненту Kubernetes, робота компонента може завершитися з помилкою. +{{< /note >}} + +Для налаштування IP-адреси оголошення API-сервера для вузлів панелі управління, створених із `init` та `join`, можна використовувати прапорець `--apiserver-advertise-address`. Переважно, варто встановлювати цю опцію в [API-інтерфейсі kubeadm](/docs/reference/config-api/kubeadm-config.v1beta3) +як `InitConfiguration.localAPIEndpoint` та `JoinConfiguration.controlPlane.localAPIEndpoint`. + +Для kubelet на всіх вузлах опцію `--node-ip` можна передати в `.nodeRegistration.kubeletExtraArgs` всередині конфігураційного файлу kubeadm (`InitConfiguration` або `JoinConfiguration`). + +Для роботи з двома стеками дивіться [Підтримка двох стеків із kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support). + +IP-адреси, які ви призначаєте компонентам панелі управління, стають частиною полів імені альтернативного підлеглого X.509 сертифікату. Зміна цих IP-адрес може вимагати підписання нових сертифікатів і перезапуску відповідних компонентів, щоб задіяти зміни у файлах сертифікатів. Дивіться [Ручне поновлення сертифікатів](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#manual-certificate-renewal) для отримання докладнішої інформації з цього питання. + +{{< warning >}} +Проєкт Kubernetes не рекомендує використовувати цей підхід (налаштування всіх екземплярів компонентів власними IP-адресами). Замість цього рекомендується встановити мережу хосту так, щоб IP-адреса стандартного шлюзу була тією, яку компоненти Kubernetes автоматично визначають і використовують. На Linux-вузлах ви можете використовувати команди, такі як `ip route` для налаштування мережі; ваша операційна система може також надавати засоби управління мережею вищого рівня. Якщо стандартний шлюз вашого вузла має публічну IP-адресу, слід налаштувати фільтрацію пакетів чи інші заходи безпеки, що захищають вузли та ваш кластер. +{{< /warning >}} + +### Підготовка необхідних образів контейнерів {#preparing-the-required-container-images} + +Цей крок є необовʼязковим і застосовується тільки у випадку, якщо ви бажаєте, щоб `kubeadm init` та `kubeadm join` не завантажували типові образи контейнерів, які розміщені на `registry.k8s.io`. + +Kubeadm має команди, які можуть допомогти вам попередньо витягти необхідні образи +при створенні кластера без Інтернет-зʼєднання на його вузлах. Дивіться [Запуск kubeadm без Інтернет-зʼєднання](/docs/reference/setup-tools/kubeadm/kubeadm-init#without-internet-connection) для отримання докладнішої інформації. + +Kubeadm дозволяє вам використовувати власний репозиторій образів для необхідних образів. Дивіться [Використання власних образів](/docs/reference/setup-tools/kubeadm/kubeadm-init#custom-images) для отримання більше інформації. + +### Ініціалізація вузла панелі управління {#initializing-your-control-plane-node} + +Вузол панелі управління — це машина, де працюють компоненти панелі управління, включаючи {{< glossary_tooltip term_id="etcd" >}} (база даних кластера) та {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} (з яким взаємодіє інструмент командного рядка {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}). + +1. (Рекомендовано) Якщо у вас є плани оновлення цього кластера з одною панеллю управління за допомогою `kubeadm` до рівня високої доступності, ви повинні вказати `--control-plane-endpoint`, щоб встановити загальний endpoint для всіх вузлів панелі управління. Такий endpoint може бути іменем DNS або IP-адресою балансувальника навантаження. +1. Виберіть надбудову мережі Pod та перевірте, чи для його налаштування потрібно передати будь-які аргументи в `kubeadm init`. Залежно від того, якого постачальника вибрано, вам може бути потрібно встановити значення `--pod-network-cidr` в значення, специфічне для постачальника. Дивіться [Встановлення надбудови мережі Podʼів](#pod-network). +1. (Необовʼязково) `kubeadm` намагається визначити середовище виконання контейнерів, використовуючи список відомих точок входу. Щоб використовувати інше середовище виконання контейнерів або якщо встановлено більше одного на наданому вузлі, вкажіть аргумент `--cri-socket` для `kubeadm`. Дивіться [Встановлення середовища виконання](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime). + +Щоб ініціалізувати вузол панелі управління, виконайте: + +```bash +kubeadm init +``` + +### Міркування щодо apiserver-advertise-address та ControlPlaneEndpoint {#considerations-about-apiserver-advertise-address-and-controlplaneendpoint} + +Хоча `--apiserver-advertise-address` може бути використано для встановлення оголошення адреси для API-сервера цього конкретного вузла панелі управління, `--control-plane-endpoint` може бути використано для встановлення загальної endpoint для всіх вузлів управління. + +`--control-plane-endpoint` дозволяє використовувати як IP-адреси, так і DNS-імена, які можуть транслюватись у IP-адреси. Будь ласка, зверніться до вашого адміністратора мережі, щоб оцінити можливі рішення щодо такого перетворення. + +Ось приклад: + +```none +192.168.0.102 cluster-endpoint +``` + +Де `192.168.0.102` — це IP-адреса цього вузла, а `cluster-endpoint` — це власне DNS-імʼя, яке повʼязується з цим IP. Це дозволить вам передавати `--control-plane-endpoint=cluster-endpoint` у `kubeadm init` і передавати те ж саме DNS-ім'я до `kubeadm join`. Пізніше ви можете змінити `cluster-endpoint`, щоб вказати адресу вашого балансувальника навантаження в сценарії високої доступності. + +Перетворення кластера з одною панеллю управлінням, створеного без `--control-plane-endpoint`, у високодоступний кластер не підтримується kubeadm. + +### Додаткова інформація {#more-information} + +Для отримання додаткової інформації щодо аргументів `kubeadm init`, див. [посібник kubeadm](/docs/reference/setup-tools/kubeadm/). + +Щоб налаштувати `kubeadm init` за допомогою файлу конфігурації, див. [Використання kubeadm init з файлом конфігурації](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). + +Для налаштування компонентів панелі управління, включаючи необовʼязкове призначення IPv6 для перевірки наявності для компонентів панелі управління та сервера etcd, надайте додаткові аргументи кожному компоненту, як описано на сторінці про [додаткові аргументи](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/). + +Щоб переналаштувати кластер, який вже був створений, див. [Переконфігурування кластера kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure). + +Щоб знову виконати `kubeadm init`, спершу вам потрібно [розібрати кластер](#tear-down). + +Якщо ви приєднуєте вузол з іншою архітектурою до вашого кластера, переконайтеся, що ваші розгорнуті DaemonSets мають підтримку образів контейнерів для цієї архітектури. + +`kubeadm init` спочатку виконує серію попередніх перевірок, щоб забезпечити готовність машини до запуску Kubernetes. Ці попередні перевірки виводять попередження та виходять при помилках. Потім `kubeadm init` завантажує та встановлює компоненти управління кластером. Це може зайняти кілька хвилин. Після завершення ви повинні побачити: + +```none +Your Kubernetes control-plane has initialized successfully! + +To start using your cluster, you need to run the following as a regular user: + + mkdir -p $HOME/.kube + sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config + sudo chown $(id -u):$(id -g) $HOME/.kube/config + +You should now deploy a Pod network to the cluster. +Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at: + /docs/concepts/cluster-administration/addons/ + +You can now join any number of machines by running the following on each node +as root: + + kubeadm join : --token --discovery-token-ca-cert-hash sha256: +``` + +Щоб кubectl працював для вашого користувача без прав root, виконайте ці команди, які є також частиною виводу `kubeadm init`: + +```bash +mkdir -p $HOME/.kube +sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config +sudo chown $(id -u):$(id -g) $HOME/.kube/config +``` + +Або, якщо ви є користувачем `root`, ви можете виконати: + +```bash +export KUBECONFIG=/etc/kubernetes/admin.conf +``` + +{{< warning >}} +Файл конфігурації kubeconfig `admin.conf`, який створює `kubeadm init`, містить сертифікат із `Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin`. Група `kubeadm:cluster-admins` привʼязана до вбудованої ролі кластера `cluster-admin`. +Не діліться файлом `admin.conf` будь з ким. + +`kubeadm init` генерує інший файл kubeconfig `super-admin.conf`, який містить сертифікат із `Subject: O = system:masters, CN = kubernetes-super-admin`. +`system:masters` — це суперкористувацька група, яка обходить рівень авторизації (наприклад, RBAC). Не діліться файлом `super-admin.conf` будь з ким. Рекомендується перемістити файл в безпечне місце. + +Див. [Генерація файлів kubeconfig для додаткових користувачів](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs#kubeconfig-additional-users) щодо того, як використовувати `kubeadm kubeconfig user` для генерації файлів kubeconfig для додаткових користувачів. +{{< /warning >}} + +Запишіть команду `kubeadm join`, яку виводить `kubeadm init`. Вам потрібна ця команда для [приєднання вузлів до вашого кластера](#join-nodes). + +Токен використовується для взаємної автентифікації між вузлом панелі управління та приєднуваними вузлами. Токен, який включено тут, є секретним. Зберігайте його у безпеці, оскільки будь-хто з цим токеном може додавати автентифіковані вузли до вашого кластера. Ці токени можна подивитись, створити та видалити за допомогою команди `kubeadm token`. Див. [посібник посилань для kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-token/). + +### Встановлення надбудови для мережі Pod {#pod-network} + +{{< caution >}} +Цей розділ містить важливу інформацію щодо налаштування мережі та порядку розгортання. Уважно прочитайте всі ці поради перед продовженням. + +**Вам потрібно розгорнути надбудову мережі Pod на основі {{< glossary_tooltip text="Container Network Interface" term_id="cni" >}} (CNI), щоб ваші Podʼи могли взаємодіяти один з одним. Кластерний DNS (CoreDNS) не буде запущений, доки не буде встановлена мережа.** + +- Пильнуйте, щоб мережа ваших Podʼів не перетиналася з будь-якою з мереж хосту. Якщо ви знаходите колізію між вашою пропонованою мережею Podʼів та деякими мережами вашого хосту, вам слід обрати відповідний блок CIDR для використання його під час виконання `kubeadm init` з `--pod-network-cidr` та як заміну у вашому файлі налаштувань мережевого втулка YAML. + +- Типово `kubeadm` налаштовує ваш кластер на використання та забезпечення використання [RBAC](/docs/reference/access-authn-authz/rbac/) (контроль доступу на основі ролей). Переконайтеся, що ваш мережевий втулок для Pod підтримує RBAC, так само як і будь-які маніфести, які ви використовуєте для її розгортання. + +- Якщо ви хочете використовувати IPv6 — як подвійний стек, так і лише одновимірну IPv6-мережу — для вашого кластера, переконайтеся, що ваш мережевий втулок для Podʼів підтримує IPv6. Підтримку IPv6 було додано до CNI у [v0.6.0](https://github.com/containernetworking/cni/releases/tag/v0.6.0). + +{{< /caution >}} + +{{< note >}} +Kubeadm повинен бути агностичним до CNI, а перевірка постачальників CNI виходить за рамки наших поточних e2e-тестів. Якщо ви знайшли проблему, повʼязану з втулком CNI, вам слід створити тікет у відповідному репозиторії втулка CNI, а не у репо kubeadm чи Kubernetes. +{{< /note >}} + +Кілька зовнішніх проєктів надають мережі Pod Kubernetes за допомогою CNI, деякі з яких також підтримують [Network Policy](/docs/concepts/services-networking/network-policies/). + +Див. список надбудов, які реалізують [Модель мережі Kubernetes](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model). + +Будь ласка, звертайтеся до сторінки [Встановлення надбудов](/docs/concepts/cluster-administration/addons/#networking-and-network-policy) для списку мережевих надбудов (може бути неповним), які підтримуються в Kubernetes. Ви можете встановити надбудову мережі Pod за допомогою наступної команди на вузлі панелі управління +або вузлі, на якому є облікові дані kubeconfig: + +```bash +kubectl apply -f +``` + +Ви можете встановити лише одну мережу Pod на кластер. + +Як тільки мережу Pod буде створено, ви можете підтвердити, що вона працює, перевіривши, що Pod CoreDNS у стані `Running` у виводі `kubectl get pods --all-namespaces`. І як тільки Pod CoreDNS запущено і він працює, ви можете продовжити приєднувати ваші вузли. + +Якщо ваша мережа не працює або CoreDNS не перебуває у стані `Running`, перегляньте +[посібник з усунення несправностей](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/) для `kubeadm`. + +### Керовані мітки вузлів {#managed-node-labels} + +Типово kubeadm вмикає контролер доступу [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction), що обмежує, які мітки можуть бути самостійно застосовані kubelet під час реєстрації вузла. Документація контролера доступу описує, які мітки можна використовувати з параметром kubelet `--node-labels`. Мітка `node-role.kubernetes.io/control-plane` є такою обмеженою міткою, і kubeadm вручну застосовує її, використовуючи привілейований клієнт після створення вузла. Щоб зробити це вручну, ви можете використовувати `kubectl label` +та переконатися, що використовується привілейований kubeconfig, такий як керований kubeadm `/etc/kubernetes/admin.conf`. + +### Ізоляція вузла панелі управління {#control-plane-node-isolation} + +Типово у вашому кластері не буде планувати розміщення Podʼів на вузлі панелі управління з міркувань безпеки. Якщо ви хочете мати можливість планувати Podʼи на вузлах панелі управління, наприклад, для кластера Kubernetes на одній машині, +виконайте команду: + +```bash +kubectl taint nodes --all node-role.kubernetes.io/control-plane- +``` + +Вивід буде схожим на: + +```none +node "test-01" untainted +... +``` + +Це видалить позначку `node-role.kubernetes.io/control-plane:NoSchedule` з будь-яких вузлів, які мають її, включаючи вузли панелі управління, що означає, що планувальник зможе розміщувати Podʼи всюди. + +Додатково ви можете виконати наступну команду, щоб видалити мітку [`node.kubernetes.io/exclude-from-external-load-balancers`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-exclude-from-external-load-balancers) з вузла панелі управління, що виключає його зі списку бекенд-серверів: + +```bash +kubectl label nodes --all node.kubernetes.io/exclude-from-external-load-balancers- +``` + +### Приєднання вузлів {#join-nodes} + +Вузли — це місця, де виконуються ваші завдання (контейнери та Podʼи, тощо). Щоб додати нові вузли до кластера, виконайте наступне для кожної машини: + +- Приєднайтеся за допомогою SSH до машини +- Станьте користувачем root (наприклад, `sudo su -`) +- [Встановіть середовище виконання](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime), якщо потрібно +- Запустіть команду, з виводу `kubeadm init`. Наприклад: + + ```bash + kubeadm join --token : --discovery-token-ca-cert-hash sha256: + ``` + +Якщо у вас немає токена, ви можете отримати його, виконавши наступну команду на вузлі панелі управління: + +```bash +kubeadm token list +``` + +Вивід буде схожий на це: + +```console +TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS +8ewj1p.9r9hcjoqgajrj4gi 23h 2018-06-12T02:51:28Z authentication, The default bootstrap system: + signing token generated by bootstrappers: + 'kubeadm init'. kubeadm: + default-node-token +``` + +Типово дія токенів закінчуються через 24 години. Якщо ви приєднуєте вузол до кластера після закінчення дії токена, ви можете створити новий токен, виконавши наступну команду на вузлі панелі управління: + +```bash +kubeadm token create +``` + +Вивід буде схожий на це: + +```console +5didvk.d09sbcov8ph2amjw +``` + +Якщо у вас немає значення `--discovery-token-ca-cert-hash`, ви можете отримати його, виконавши наступний ланцюжок команд на вузлі панелі управління: + +```bash +openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \ + openssl dgst -sha256 -hex | sed 's/^.* //' +``` + +Вивід буде схожий на: + +```console +8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78 +``` + +{{< note >}} +Щоб вказати IPv6-кортеж для `:`, IPv6-адресу слід взяти у квадратні дужки, наприклад: `[2001:db8::101]:2073`. +{{< /note >}} + +Вивід повинен виглядати приблизно так: + +```none +[preflight] Running pre-flight checks + +... (журнал виводу процесу приєднання) ... + +Node join complete: +* Certificate signing request sent to control-plane and response + received. +* Kubelet informed of new secure connection details. + +Run 'kubectl get nodes' on control-plane to see this machine join. +``` + +Через кілька секунд ви повинні помітити цей вузол у виводі з `kubectl get nodes`, якщо ви його запустите на вузлі панелі управління. + +{{< note >}} +Оскільки вузли кластера зазвичай ініціалізуються послідовно, ймовірно, що Podʼи CoreDNS будуть запущені всі на першому вузлі панелі управління. Для забезпечення більшої доступності перезавантажте Podʼи CoreDNS за допомогою `kubectl -n kube-system rollout restart deployment coredns` після приєднання принаймні одного нового вузла. +{{< /note >}} + +### (Необовʼязково) Керування кластером з інших машин, крім вузла панелі управління {#optional-controlling-your-cluster-from-machines-other-than-the-control-plane-node} + +Щоб отримати доступ до кластера з іншого компʼютера (наприклад, з ноутбука), вам потрібно скопіювати файл kubeconfig з вузла панелі управління на ваш робочий компʼютер так: + +```bash +scp root@:/etc/kubernetes/admin.conf . +kubectl --kubeconfig ./admin.conf get nodes +``` + +{{< note >}} +У даному прикладі вважається, що доступ SSH увімкнено для користувача root. Якщо цього не відбувається, ви можете скопіювати файл `admin.conf` так, щоб його можна було отримати через обліковий запис іншого користувача, і використовувати цього користувача для `scp`. + +Файл `admin.conf` надає користувачеві привілеї _superuser_ у кластері. Його слід використовувати обережно. Для звичайних користувачів рекомендується генерувати унікальні облікові дані, до яких ви надаєте привілеї. Це можна зробити за допомогою команди `kubeadm kubeconfig user --client-name `. Ця команда виведе файл KubeConfig у STDOUT, який вам слід зберегти в файл та розповсюджувати поміж користувачів. Після цього надайте привілеї за допомогою `kubectl create (cluster)rolebinding`. +{{< /note >}} + +### (Необовʼязково) Проксі-доступ до API Server на localhost {#optional-proxying-api-server-to-localhost} + +Якщо ви хочете підʼєднатися до API Server ззовні кластера, ви можете використовувати `kubectl proxy`: + +```bash +scp root@:/etc/kubernetes/admin.conf . +kubectl --kubeconfig ./admin.conf proxy +``` + +Тепер ви можете отримати доступ до API Server локально за адресою `http://localhost:8001/api/v1`. + +## Очищення {#tear-down} + +Якщо ви використовували тимчасові сервери для свого кластера для тестування, ви можете вимкнути їх і не проводити додаткового очищення. Ви можете використовувати `kubectl config delete-cluster`, щоб видалити ваші локальні посилання на кластер. + +Однак, якщо ви хочете розібрати ваш кластер відповіднішим чином, вам слід спочатку [перевести вузол в режим обслуговування](/docs/reference/generated/kubectl/kubectl-commands#drain) і переконатися, що на вузлі немає ресурсів, а потім зняти конфігурацію з вузла. + +### Видалення вузла {#remove-node} + +Зверніться до вузла панелі управління використовуючи відповідний обліковий запис та виконайте: + +```bash +kubectl drain <імʼя вузла> --delete-emptydir-data --force --ignore-daemonsets +``` + +Перед видаленням вузла скиньте стан, встановлений за допомогою `kubeadm`: + +```bash +kubeadm reset +``` + +Процес скидання не відновлює або не очищає правила iptables чи таблиці IPVS. Якщо ви хочете скинути iptables, вам слід це зробити вручну: + +```bash +iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X +``` + +Якщо ви хочете скинути таблиці IPVS, вам слід виконати наступну команду: + +```bash +ipvsadm -C +``` + +Тепер видаліть вузол: + +```bash +kubectl delete node <імʼя вузла> +``` + +Якщо ви хочете почати спочатку, запустіть `kubeadm init` або `kubeadm join` з відповідними аргументами. + +### Очищення панелі управління {#clean-up-the-control-plane} + +Ви можете використовувати `kubeadm reset` на хості панелі управління для виконання очищення. + +Дивіться [довідкову документацію](/docs/reference/setup-tools/kubeadm/kubeadm-reset/) для `kubeadm reset` для отримання додаткової інформації щодо цієї підкоманди та її параметрів. + +## Політика розбіжності версій {#version-skew-policy} + +Хоча kubeadm дозволяє розбіжність версій для деяких компонентів, якими він керує, рекомендується вирівнювати версію kubeadm із версіями компонентів панелі управління, kube-proxy та kubelet. + +### Відхилення версії kubeadm від версії Kubernetes {#kubeadm-s-skew-against-the-kubernetes-version} + +kubeadm можна використовувати із компонентами Kubernetes, які мають таку саму версію, як і kubeadm, або на одну версію застаріше. Версію Kubernetes можна вказати для kubeadm, використовуючи прапорець `--kubernetes-version` команди `kubeadm init` або поле [`ClusterConfiguration.kubernetesVersion`](/docs/reference/config-api/kubeadm-config.v1beta3/) при використанні `--config`. Ця опція буде контролювати версії kube-apiserver, kube-controller-manager, kube-scheduler та kube-proxy. + +Приклад: + +- kubeadm має версію {{< skew currentVersion >}} +- `kubernetesVersion` повинна бути {{< skew currentVersion >}} або {{< skew currentVersionAddMinor -1 >}} + +### Відхилення версії kubeadm від версії kubelet {#kubeadm-s-skew-against-the-kubelet} + +Аналогічно до версії Kubernetes, kubeadm можна використовувати з версією kubelet, яка є такою ж самою версією, що й kubeadm, або на одну версією застарішою. + +Приклад: + +- kubeadm має версію {{< skew currentVersion >}} +- kubelet на хості повинен мати версію {{< skew currentVersion >}}, {{< skew currentVersionAddMinor -1 >}}, {{< skew currentVersionAddMinor -2 >}} або {{< skew currentVersionAddMinor -3 >}} + +### Відхилення версії kubeadm від kubeadm {#kubeadm-s-skew-against-kubeadm} + +Є певні обмеження на те, як можна використовувати команди kubeadm на існуючих вузлах або цілих кластерах, під керуванням kubeadm. + +Якщо до кластера приєднуються нові вузли, використована для `kubeadm join` бінарна версія kubeadm повинна відповідати останній версії kubeadm, що використовувалася або для створення кластера за допомогою `kubeadm init`, або для оновлення того самого вузла за допомогою `kubeadm upgrade`. Подібні правила застосовуються до інших команд kubeadm з винятком `kubeadm upgrade`. + +Приклад для `kubeadm join`: + +- версія kubeadm {{< skew currentVersion >}} використовувалася для створення кластера за допомогою `kubeadm init` +- Приєднувані вузли повинні використовувати бінарний файл kubeadm версії {{< skew currentVersion >}} + +Вузли, які оновлюються, повинні використовувати версію kubeadm, яка є тією ж самою MINOR версією або на одну MINOR версію новішою, ніж версія kubeadm, яка використовувалася для управління вузлом. + +Приклад для `kubeadm upgrade`: + +- версія kubeadm {{< skew currentVersionAddMinor -1 >}} використовувалася для створення або оновлення вузла +- Версія kubeadm, використана для оновлення вузла, повинна бути на {{< skew currentVersionAddMinor -1 >}} або {{< skew currentVersion >}} + +Щоб дізнатися більше про різницю версій між різними компонентами Kubernetes, див. [Політику відхилень версій](/releases/version-skew-policy/). + +### Обмеження {#limitations} + +### Витривалість кластера {#resilience} + +Створений тут кластер має один вузол для панелі управління з однією базою даних etcd, яка працює на ньому. Це означає, що якщо вузол для панелі управління вийде з ладу, ваш кластер може втратити дані і може деведеться його перестворювати з нуля. + +Обхідні шляхи: + +- Регулярно [робіть резервні копії etcd](https://etcd.io/docs/v3.5/op-guide/recovery/). Тека даних etcd, налаштована за допомогою kubeadm, розташована за адресою `/var/lib/etcd` на вузлі панелі управління. + +- Використовуйте кілька вузлів для панелі управління. Ви можете прочитати про [Варіанти високодоступної топології](/docs/setup/production-environment/tools/kubeadm/ha-topology/), щоб вибрати топологію кластера, яка забезпечує [високу доступність](/docs/setup/production-environment/tools/kubeadm/high-availability/). + +### Платформна сумісність {#multi-platform} + +Пакунки та бінарники kubeadm для deb/rpm будуються для amd64, arm (32-біт), arm64, ppc64le та s390x, відповідабть [пропозиції щодо багатоплатформовості](https://git.k8s.io/design-proposals-archive/multi-platform.md). + +Багатоплатформові образи контейнерів для вузла панелі управління та надбудов також підтримуються з версії 1.12. + +Тільки деякі постачальники мережі пропонують рішення для всіх платформ. Зверніться до списку постачальників мережі вище або до документації кожного постачальника, щоб визначити, чи підтримує постачальник вашу платформу. + +### Усунення несправностей {#troubleshooting} + +Якщо ви стикаєтеся з труднощами у роботі з kubeadm, будь ласка, звертайтеся до наших +[документів із усунення несправностей](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). + + + +### Що далі {#whats-next} + +- Перевірте, що ваш кластер працює належним чином за допомогою [Sonobuoy](https://github.com/heptio/sonobuoy). +- Дивіться [Оновлення кластерів за допомогою kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) для отримання деталей щодо оновлення кластеру з використанням `kubeadm`. +- Дізнайтесь про розширене використання `kubeadm` у [довідковій документації кubeadm](/docs/reference/setup-tools/kubeadm/). +- Дізнайтеся більше про концепції Kubernetes [тут](/docs/concepts/) та [`kubectl`](/docs/reference/kubectl/). +- Дивіться сторінку [мережі кластера](/docs/concepts/cluster-administration/networking/) для отримання великого списку додаткових надбудов Pod network. +- Дивіться [список надбудов](/docs/concepts/cluster-administration/addons/) для вивчення інших надбудов, включаючи інструменти для ведення логів, моніторингу, мережевої політики, візуалізації та управління вашим кластером Kubernetes. +- Налаштуйте спосіб обробки вашим кластером логів подій кластера та застосунків, які працюють у Pod. Дивіться [Архітектура ведення логів](/docs/concepts/cluster-administration/logging/) для отримання огляду того, що включено в цей процес. + +### Зворотній звʼязок {#feedback} + +- Для ознайомлення з повідомленями про помилки відвідайте [трекер проблем kubeadm на GitHub](https://github.com/kubernetes/kubeadm/issues) +- Для отримання підтримки відвідайте канал Slack [#kubeadm](https://kubernetes.slack.com/messages/kubeadm/) +- Загальний канал розробки SIG Cluster Lifecycle на Slack: [#sig-cluster-lifecycle](https://kubernetes.slack.com/messages/sig-cluster-lifecycle/) +- [Інформація про SIG Cluster Lifecycle](https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle#readme) +- Розсилка SIG Cluster Lifecycle: [kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle) diff --git a/content/uk/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md b/content/uk/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md new file mode 100644 index 0000000000000..e3b9a777e913a --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md @@ -0,0 +1,146 @@ +--- +title: Підтримка подвійного стека за допомогою kubeadm +content_type: task +weight: 100 +min-kubernetes-server-version: 1.21 +--- + + + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +Ваш кластер Kubernetes має мережу з [підтримкою подвійного стека](/docs/concepts/services-networking/dual-stack/), що означає, що у кластері мережева взаємодія може використовувати обидві адресні родини. У кластері панель управління може призначити як IPv4-адреси, так і IPv6-адреси для {{< glossary_tooltip text="Podʼу" term_id="pod" >}} чи {{< glossary_tooltip text="Service" term_id="service" >}}. + + + +## {{% heading "prerequisites" %}} + +Вам потрібно встановити інструмент {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}}, дотримуючись кроків з [Встановлення kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). + +Для кожного сервера, який ви хочете використовувати як {{< glossary_tooltip text="вузол" term_id="node" >}}, переконайтеся, що на ньому увімкнено переспрямовування IPv6 трафіку (IPv6 forwarding). На Linux це можна зробити, виконавши `sysctl -w net.ipv6.conf.all.forwarding=1` з правами користувача root на кожному сервері. + +Вам потрібні діапазони адрес IPv4 та IPv6. Оператори кластера, як правило, +використовують приватні діапазони адрес для IPv4. Щодо IPv6, оператор кластера, як правило, обирає глобальний унікальний блок адрес з області `2000::/3`, використовуючи діапазон, який виділений оператору. Вам не потрібно робити маршрутизацію IP-діапазонів кластера в Інтернет. + +Розмір діапазону IP-адрес повинен бути достатнім для тієї кількості Podʼів та +Serviceʼів, які ви плануєте запускати. + +{{< note >}} +Якщо ви оновлюєте наявний кластер за допомогою команди `kubeadm upgrade`, `kubeadm` не підтримує внесення змін до діапазону IP-адрес ("кластер CIDR") або діапазону адрес служби кластера ("Service CIDR"). +{{< /note >}} + +### Створення кластера з подвійним стеком {#create-a-dual-stack-cluster} + +Для створення кластера з подвійним стеком за допомогою `kubeadm init` ви можете передати аргументи командного рядка аналогічно наступному прикладу: + +```shell +# Це діапазони адрес для прикладу +kubeadm init --pod-network-cidr=10.244.0.0/16,2001:db8:42:0::/56 --service-cidr=10.96.0.0/16,2001:db8:42:1::/112 +``` + +Щоб зробити це більш зрозумілим, ось приклад конфігураційного файлу `kubeadm` +[/docs/reference/config-api/kubeadm-config.v1beta3/](kubeadm-config.yaml) для вузла основної панелі управління з подвійним стеком. + +```yaml +--- +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +networking: + podSubnet: 10.244.0.0/16,2001:db8:42:0::/56 + serviceSubnet: 10.96.0.0/16,2001:db8:42:1::/112 +--- +apiVersion: kubeadm.k8s.io/v1beta3 +kind: InitConfiguration +localAPIEndpoint: + advertiseAddress: "10.100.0.1" + bindPort: 6443 +nodeRegistration: + kubeletExtraArgs: + node-ip: 10.100.0.2,fd00:1:2:3::2 +``` + +`advertiseAddress` в InitConfiguration вказує IP-адресу, яку API Server оголошує як адресу, на якій він очікує трафік. Значення `advertiseAddress` дорівнює значенню +прапорця `--apiserver-advertise-address` команди `kubeadm init`. + +Використовуйте kubeadm для ініціалізації панелі управління на вузлі з подвійним стеком: + +```shell +kubeadm init --config=kubeadm-config.yaml +``` + +Прапори kube-controller-manager `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` встановлені у стандартні значення. Див. [налаштування подвійного стека IPv4/IPv6](/docs/concepts/services-networking/dual-stack#configure-ipv4-ipv6-dual-stack). + +{{< note >}} +Прапор `--apiserver-advertise-address` не підтримує подвійний стек. +{{< /note >}} + +### Приєднання вузла до кластера з подвійним стеком {#join-a-node-to-dual-stack-cluster} + +Перш ніж приєднати вузол, переконайтеся, що вузол має мережевий інтерфейс з можливістю маршрутизації IPv6 та дозволяє пересилання IPv6. + +Ось приклад конфігураційного файлу `kubeadm` [/docs/reference/config-api/kubeadm-config.v1beta3/](kubeadm-config.yaml) для приєднання робочого вузла до кластера. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: JoinConfiguration +discovery: + bootstrapToken: + apiServerEndpoint: 10.100.0.1:6443 + token: "clvldh.vjjwg16ucnhp94qr" + caCertHashes: + - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e" + # змініть інформацію про автентифікацію вище, щоб відповідати фактичному токену та хешу сертифіката CA для вашого кластера +nodeRegistration: + kubeletExtraArgs: + node-ip: 10.100.0.3,fd00:1:2:3::3 +``` + +Також ось приклад конфігураційного файлу `kubeadm` [/docs/reference/config-api/kubeadm-config.v1beta3/](kubeadm-config.yaml) для приєднання іншого вузла панелі управління до кластера. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: JoinConfiguration +controlPlane: + localAPIEndpoint: + advertiseAddress: "10.100.0.2" + bindPort: 6443 +discovery: + bootstrapToken: + apiServerEndpoint: 10.100.0.1:6443 + token: "clvldh.vjjwg16ucnhp94qr" + caCertHashes: + - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e" + # змініть інформацію про автентифікацію вище, щоб відповідати фактичному токену та хешу сертифіката CA для вашого кластера +nodeRegistration: + kubeletExtraArgs: + node-ip: 10.100.0.4,fd00:1:2:3::4 + +``` + +`advertiseAddress` в JoinConfiguration.controlPlane вказує IP-адресу, яку API Server оголошує як адресу, на якій він слухає. Значення `advertiseAddress` дорівнює прапорцю `--apiserver-advertise-address` команди `kubeadm join`. + +```shell +kubeadm join --config=kubeadm-config.yaml +``` + +### Створення кластера з одним стеком {#create-a-single-stack-cluster} + +{{< note >}} +Підтримка подвійного стека не означає, що вам потрібно використовувати подвійні адреси. Ви можете розгорнути кластер з одним стеком, в якому увімкнена функція роботи з мережею з подвійним стеком. +{{< /note >}} + +Щоб зробити речі більш зрозумілими, ось приклад конфігураційного файлу `kubeadm` [/docs/reference/config-api/kubeadm-config.v1beta3/](kubeadm-config.yaml) для контрольного пункту з одним стеком. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +networking: + podSubnet: 10.244.0.0/16 + serviceSubnet: 10.96.0.0/16 +``` + +## {{% heading "whatsnext" %}} + +* [Перевірка мережевої взаємодії в подвійному стеку IPv4/IPv6](/docs/tasks/network/validate-dual-stack) +* Дізнайтеся більше про [підтримку подвійного стека](/docs/concepts/services-networking/dual-stack/) +* Дізнайтеся більше про [формат конфігурації kubeadm](/docs/reference/config-api/kubeadm-config.v1beta3/) diff --git a/content/uk/docs/setup/production-environment/tools/kubeadm/ha-topology.md b/content/uk/docs/setup/production-environment/tools/kubeadm/ha-topology.md new file mode 100644 index 0000000000000..385d82ddc6234 --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/kubeadm/ha-topology.md @@ -0,0 +1,57 @@ +--- +reviewers: +- sig-cluster-lifecycle +title: Варіанти топології високої доступності (HA) +content_type: concept +weight: 50 +--- + + + +Ця сторінка пояснює два варіанти конфігурації топології ваших високо доступних (HA) кластерів Kubernetes. + +Ви можете налаштувати стійкий кластер: + +- З вузлами панелі управління, де вузли etcd розташовані разом із вузлами панелі управління. +- З зовнішніми вузлами etcd, де etcd працює на окремих вузлах від вузлів панелі управління. + +Перед налаштуванням стійкого кластера слід ретельно розглянути переваги та недоліки кожної топології. + +{{< note >}} +kubeadm статично розгортає кластер etcd. Ознайомтесь з [Керівництвом з кластеризації](https://github.com/etcd-io/etcd/blob/release-3.4/Documentation/op-guide/clustering.md#static). +{{< /note >}} + +## Топологія etcd зі спільним розміщенням {#stacked-etcd-topology} + +Вискодоступний кластер зі спільним розміщенням — це [топологія](https://en.wikipedia.org/wiki/Network_topology), де розподілений кластер зберігання даних, який забезпечує etcd, розміщується поверх кластера, сформованого вузлами, керованими kubeadm, які запускають компоненти панелі управління. + +Кожен вузол панелі управління запускає екземпляр `kube-apiserver`, `kube-scheduler` та `kube-controller-manager`. `kube-apiserver` доступний для робочих вузлів за допомогою балансувальника навантаження. + +Кожен вузол панелі управління створює локального члена etcd, і цей член etcd спілкується лише з `kube-apiserver` цього вузла. Те ж саме стосується локальних екземплярів `kube-controller-manager` та `kube-scheduler`. + +Ця топологія зʼєднує вузли панелі управління з членами etcd на тих самих вузлах. Вона є простішою для налаштування, ніж кластер зі зовнішніми вузлами etcd, і простішою для управління реплікацією. + +Проте такий кластер має ризик втрати зʼєднання. Якщо один вузол вийде з ладу, втратиться як член etcd, так і екземпляр панелі управління, і резервні можливості будуть скомпрометовані. Цей ризик можна зменшити, додавши більше вузлів панелі управління. + +Отже, слід запускати мінімум три вузли панелі управління зі стековим розміщенням для високодоступного кластера. + +Це типова топологія в kubeadm. Локальний член etcd створюється автоматично +на вузлах панелі управління при використанні `kubeadm init` та `kubeadm join --control-plane`. + +![Топологія etcd зі стековим розміщенням](/images/kubeadm/kubeadm-ha-topology-stacked-etcd.svg) + +## Топологія зовнішнього розміщення etcd {#external-etcd-topology} + +Стійкий кластер із зовнішньою etcd — це [топологія](https://en.wikipedia.org/wiki/Network_topology), де розподілений кластер зберігання даних, наданий etcd, є зовнішнім щодо кластера, сформованого вузлами, які запускають компоненти панелі управління. + +Подібно до топології зі стековими etcd, кожен вузол панелі управління в топології зі зовнішньою etcd запускає екземпляр `kube-apiserver`, `kube-scheduler` та `kube-controller-manager`. І `kube-apiserver` доступний для робочих вузлів за допомогою балансувальника навантаження. Однак члени etcd працюють на окремих хостах, і кожен хост etcd спілкується з `kube-apiserver` кожного вузла панелі управління. + +Ця топологія відокремлює вузли панелі управління та членів etcd. Таким чином, вона забезпечує стійке налаштування, де втрата екземпляра панелі управління або члена etcd має менший вплив і не впливає на резервування кластера так сильно, як топологія стекового HA. + +Однак для цієї топології потрібно удвічі більше хостів, ніж для топології зі стековим etcd. Мінімум три хости для вузлів панелі управління та три хости для вузлів etcd необхідні для стійкого кластера з цією топологією. + +![Топологія зовнішнього розташування etcd](/images/kubeadm/kubeadm-ha-topology-external-etcd.svg) + +## {{% heading "whatsnext" %}} + +- [Встановлення високодоступного кластера з kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) diff --git a/content/uk/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/uk/docs/setup/production-environment/tools/kubeadm/high-availability.md new file mode 100644 index 0000000000000..0ae12049c1a67 --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -0,0 +1,371 @@ +--- +reviewers: +- sig-cluster-lifecycle +title: Створення високодоступних кластерів за допомогою kubeadm +content_type: task +weight: 60 +--- + + + +На цій сторінці пояснюється два різних підходи до налаштування високодоступного кластера Kubernetes з використанням інструменту kubeadm: + +- Зі стековими вузлами панелі управління. Цей підхід вимагає менше інфраструктури. Члени etcd та вузли панелі управління розташовані разом. +- Зовнішній кластер etcd. Цей підхід вимагає більше інфраструктури. Вузли панелі управління та члени etcd розділені. + +Перед тим як продовжити, вам слід ретельно розглянути, який підхід найкраще відповідає потребам ваших застосунків та оточенню. [Варіанти топології високої доступності](/docs/setup/production-environment/tools/kubeadm/ha-topology/) наводять переваги та недоліки кожного з них. + +У випадку виникнення проблем з налаштуванням HA-кластера, будь ласка, повідомте про це в системі [відстеження проблем kubeadm](https://github.com/kubernetes/kubeadm/issues/new). + +Також дивіться [документацію з оновлення](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). + +{{< caution >}} +Ця сторінка не стосується запуску вашого кластера на платформі хмарного провайдера. У хмарному середовищі жоден із документованих тут підходів не працює з обʼєктами служб типу LoadBalancer або з динамічними PersistentVolumes. +{{< /caution >}} + +## {{% heading "prerequisites" %}} + +Передумови залежать від топології, яку ви обрали для панелі управління кластера: + +{{< tabs name="prerequisite_tabs" >}} +{{% tab name="Стековий etcd" %}} + + +Вам потрібно: + +- Три або більше машин, які відповідають [мінімальним вимогам kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) для вузлів панелі управління. Наявність непарної кількості вузлів панелі управління може бути корисною при виборі лідера в разі відмови машини чи зони, + - включаючи {{< glossary_tooltip text="середовище виконання контейнерів" term_id="container-runtime" >}}, яке вже налаштоване та працює. +- Три або більше машин, які відповідають [мінімальним вимогам kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) для робочих вузлів, + - включаючи середовище виконання контейнерів, яке вже налаштоване та працює. +- Повноцінне мережеве зʼєднання між усіма машинами в кластері (публічна чи + приватна мережа). +- Привілеї суперкористувача на всіх машинах за допомогою `sudo`. + - Ви можете використовувати інший інструмент; цей посібник використовує `sudo` у прикладах. +- SSH-доступ з одного пристрою до всіх вузлів системи. +- `kubeadm` та `kubelet` вже встановлені на всіх машинах. + +_Дивіться [Топологія стекового etcd](/docs/setup/production-environment/tools/kubeadm/ha-topology/#stacked-etcd-topology) для контексту._ + +{{% /tab %}} +{{% tab name="Зовнішній etcd" %}} + +Вам потрібно: + +- Три або більше машин, які відповідають [мінімальним вимогам kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) для вузлів панелі управління. Наявність непарної кількості вузлів панелі управління може бути корисною при виборі лідера в разі відмови машини чи зони, + - включаючи робоче {{< glossary_tooltip text="середовище виконання контейнерів" term_id="container-runtime" >}}, яке вже налаштоване та працює +- Три або більше машин, які відповідають [мінімальним вимогам kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) для робочих вузлів, + - включаючи середовище виконання контейнерів контейнера, яке вже налаштоване та працює. +- Повноцінне мережеве зʼєднання між усіма машинами в кластері (публічна чи + приватна мережа). +- Привілеї суперкористувача на всіх машинах за допомогою `sudo`. + - Ви можете використовувати інший інструмент; цей посібник використовує `sudo` у прикладах. +- SSH-доступ з одного пристрою до всіх вузлів системи. +- `kubeadm` та `kubelet` вже встановлені на всіх машинах. + + + +І вам також потрібно: + +- Три або більше додаткових машин, які стануть членами кластера etcd. Наявність непарної кількості членів у кластері etcd — це вимога для досягнення оптимального кворуму під час голосування. + - Ці машини також повинні мати встановлені `kubeadm` та `kubelet`. + - На цих машинах також потрібно мати середовище виконання контейнерів, яке вже налаштоване та працює. + +_Дивіться [Топологія зовнішнього etcd](/docs/setup/production-environment/tools/kubeadm/ha-topology/#external-etcd-topology) для контексту._ +{{% /tab %}} +{{< /tabs >}} + +### Образи контейнерів {#container-images} + +Кожен хост повинен мати доступ для отримання та завантаження образів з реєстру контейнерів Kubernetes, `registry.k8s.io`. Якщо ви хочете розгорнути високодоступний кластер, де хостам не можна здійснювати доступ до образів, це можливо. Вам слід забезпечити, що правильні образи контейнерів вже доступні на відповідних хостах за допомогою інших засобів. + +### Інтерфейс командного рядка {#kubectl} + +Для управління Kubernetes після налаштування кластера, вам слід +[встановити kubectl](/docs/tasks/tools/#kubectl) на вашому компʼютері. Також корисно +встановити інструмент `kubectl` на кожному вузлі панелі управління, оскільки це може бути корисним для усунення несправностей. + + + +## Перші кроки для обох методів {#first-steps-for-both-methods} + +### Створення балансувальника навантаження для kube-apiserver {#create-load-balancer-for-kube-apiserver} + +{{< note >}} +Існує багато конфігурацій для балансувальників навантаження. Наведений нижче приклад — лише один із варіантів. Ваші вимоги до кластера можуть вимагати іншої конфігурації. +{{< /note >}} + +1. Створіть балансувальник навантаження kube-apiserver з імʼям, яке розпізнається DNS. + + - У хмарному середовищі ви повинні розмістити вузли панелі управління за TCP балансувальником навантаження, який виконує переспрямовування трафіку. Цей балансувальник розподіляє трафік до всіх справних вузлів панелі управління у своєму списку цілей. Перевірка доступності apiserver — це перевірка TCP порту, на якому слухає kube-apiserver (типове значення порту `:6443`). + + - Не рекомендується використовувати IP-адресу безпосередньо у хмарному середовищі. + + - Балансувальник навантаження повинен мати можливість взаємодіяти з усіма вузлами панелі управління на порті apiserver. Також він повинен дозволяти вхідний трафік на його порту прослуховування. + + - Переконайтеся, що адреса балансувальника завжди відповідає адресі `ControlPlaneEndpoint` kubeadm. + + - Прочитайте [Параметри для програмного балансування навантаження](https://git.k8s.io/kubeadm/docs/ha-considerations.md#options-for-software-load-balancing) для отримання додаткових відомостей. + +2. Додайте перший вузол панелі управління до балансувальника та перевірте зʼєднання: + + ```shell + nc -v + ``` + + Помилка "connection refused" є очікуваною, оскільки API-сервер ще не запущено. Проте тайм-аут означає, що балансувальник не може взаємодіяти з вузлом панелі управління. Якщо виникає тайм-аут, повторно налаштуйте балансувальник + для взаємодії з вузлом панелі управління. + +3. Додайте решту вузлів панелі управління до цільової групи балансувальника. + +## Панель управління та вузли etcd зі стековою архітектурою {#stacked-control-plane-and-etcd-nodes} + +### Кроки для першого вузла панелі управління {#steps-for-the-first-control-plane-node} + +1. Ініціалізуйте панель управління: + + ```sh + sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs + ``` + + - Ви можете використовувати прапорець `--kubernetes-version`, щоб встановити версію Kubernetes, яку слід використовувати. Рекомендується, щоб версії kubeadm, kubelet, kubectl та Kubernetes відповідали одна одній. + - Прапорець `--control-plane-endpoint` повинен бути встановлений на адресу або DNS та порт балансувальника. + + - Прапорець `--upload-certs` використовується для завантаження сертифікатів, які слід використовувати на всіх екземплярах панелі управління. Якщо натомість ви віддаєте перевагу копіюванню сертифікатів між вузлами панелі управління вручну або за допомогою засобів автоматизації, видаліть цей прапорець та зверніться до розділу [Розподіл сертифікатів вручну](#manual-certs) нижче. + + {{< note >}} + Прапорці `kubeadm init` `--config` та `--certificate-key` не можна змішувати, тому якщо ви хочете використовувати [конфігурацію kubeadm](/docs/reference/config-api/kubeadm-config.v1beta3/) вам слід додати поле `certificateKey` у відповідні місця конфігурації (під `InitConfiguration` та `JoinConfiguration: controlPlane`). + {{< /note >}} + + {{< note >}} + Деякі мережеві втулки CNI вимагають додаткової конфігурації, наприклад вказівки IP для Podʼу в форматі CIDR, тоді як інші — ні. + Див. [документацію мережі CNI](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network). Щоб додати CIDR Podʼу, скористайтесь прапорцем `--pod-network-cidr`, або якщо ви використовуєте файл конфігурації kubeadm встановіть поле `podSubnet` в обʼєкті `networking` конфігурації `ClusterConfiguration`. + {{< /note >}} + + Вивід виглядатиме десь так: + + ```sh + ... + You can now join any number of control-plane node by running the following command on each as a root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + + Please note that the certificate-key gives access to cluster sensitive data, keep it secret! + As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use kubeadm init phase upload-certs to reload certs afterward. + + Then you can join any number of worker nodes by running the following on each as root: + kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 + ``` + + - Скопіюйте цей вивід у текстовий файл. Ви будете потребувати його пізніше для приєднання вузлів панелі управління та робочих вузлів до кластера. + - Коли використовується `--upload-certs` з `kubeadm init`, сертифікати основної панелі управління шифруються та завантажуються у `kubeadm-certs` Secret. + - Щоб знову завантажити сертифікати та згенерувати новий ключ розшифрування, використовуйте наступну команду на вузлі панелі управління який вже приєднаний до кластера: + + ```sh + sudo kubeadm init phase upload-certs --upload-certs + ``` + + - Ви також можете вказати власний `--certificate-key` під час `init`, який пізніше може бути використаний з `join`. Щоб згенерувати такий ключ, використовуйте наступну команду: + + ```sh + kubeadm certs certificate-key + ``` + + Ключ сертифіката — це рядок, закодований у шістнадцятковій формі, який є ключем AES розміром 32 байти. + + {{< note >}} + Секрет `kubeadm-certs` та ключ розшифрування діють впродовж двох годин. + {{< /note >}} + + {{< caution >}} + Як зазначено у виводі команди, ключ сертифіката надає доступ до чутливих даних кластера, тримайте його в таємниці! + {{< /caution >}} + +2. Застосуйте обраний вами мережеву втулок CNI: [Дотримуйтеся цих інструкцій](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) для встановлення постачальника CNI. Переконайтеся, що конфігурація відповідає CIDR IP для Podʼу, вказаному в файлі конфігурації kubeadm (якщо застосовується). + + {{< note >}} + Вам слід вибрати мережевий втулок, який відповідає вашому випадку використання та встановити його, перш ніж перейти до наступного кроку. Якщо ви цього не зробите, вам не вдасться належним чином запустити свій кластер. + {{< /note >}} + +3. Введіть наступну команду та спостерігайте, як запускаються екземпляри компонентів панелі управління: + + ```sh + kubectl get pod -n kube-system -w + ``` + +### Кроки для інших вузлів панелі управління {#steps-for-the-rest-of-the-control-plane-nodes} + +Для кожного додаткового вузла панелі управління: + +1. Виконайте команду приєднання, яка вам була надана раніше виводом `kubeadm init` на першому вузлі. Вона повинна виглядати приблизно так: + + ```sh + sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 --control-plane --certificate-key f8902e114ef118304e561c3ecd4d0b543adc226b7a07f675f56564185ffe0c07 + ``` + + - Прапорець `--control-plane` повідомляє `kubeadm join` створити новий вузол панелі управління. + - Прапорець `--certificate-key ...` призведе до того, що сертифікати вузлів панелі управління будуть завантажені з секрету `kubeadm-certs` в кластері та розшифровані за допомогою вказаного ключа. + +Ви можете приєднувати кілька вузлів панелі управління паралельно. + +## Зовнішні вузли etcd {#external-etcd-nodes} + +Налаштування кластера з зовнішніми вузлами etcd подібно до процедури, використовуваної для стекових вузлів etcd, з винятком того, що ви повинні налаштувати etcd спочатку, і ви повинні передавати інформацію про etcd у конфігураційному файлі kubeadm. + +### Налаштуйте кластер etcd {#setup-the-etcd-cluster} + +1. Слідуйте цим [інструкціям](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) для налаштування кластера etcd. + +1. Налаштуйте SSH, як описано [тут](#manual-certs). + +1. Скопіюйте наступні файли з будь-якого вузла etcd в кластері на перший вузол панелі управління: + + ```sh + export CONTROL_PLANE="ubuntu@10.0.0.7" + scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}": + scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}": + ``` + + - Замініть значення `CONTROL_PLANE` на `user@host` першого вузла панелі управління. + +### Налаштуйте перший вузол панелі управління {#setup-the-first-control-plane-node} + +1. Створіть файл із назвою `kubeadm-config.yaml` із наступним змістом: + + ```yaml + --- + apiVersion: kubeadm.k8s.io/v1beta3 + kind: ClusterConfiguration + kubernetesVersion: stable + controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # змініть це (див. нижче) + etcd: + external: + endpoints: + - https://ETCD_0_IP:2379 # змініть ETCD_0_IP відповідно + - https://ETCD_1_IP:2379 # змініть ETCD_1_IP відповідно + - https://ETCD_2_IP:2379 # змініть ETCD_2_IP відповідно + caFile: /etc/kubernetes/pki/etcd/ca.crt + certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt + keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key + ``` + + {{< note >}} + Різниця між stacked etcd та external etcd полягає в тому, що налаштування external etcd потребує конфігураційного файлу з endpointʼами etcd в обʼєкті `external` для `etcd`. У випадку топології stacked etcd це вирішується автоматично. + {{< /note >}} + + - Замініть наступні змінні в шаблоні конфігурації на відповідні значення для вашого кластера: + + - `LOAD_BALANCER_DNS` + - `LOAD_BALANCER_PORT` + - `ETCD_0_IP` + - `ETCD_1_IP` + - `ETCD_2_IP` + +Наступні кроки схожі на налаштування stacked etcd: + +1. Виконайте команду `sudo kubeadm init --config kubeadm-config.yaml --upload-certs` на цьому вузлі. + +1. Запишіть вихідні команди для приєднання, які повертаються, у текстовий файл для подальшого використання. + +1. Застосуйте обраний вами втулок CNI. + + {{< note >}} + Ви повинні вибрати мережевий втулок, який відповідає вашому випадку використання та розгорнути його, перш ніж перейдете до наступного кроку. Якщо цього не зробити, ви не зможете належним чином запустити ваш кластер. + {{< /note >}} + +### Кроки для інших вузлів панелі управління {#steps-for-the-rest-of-the-control-plane-nodes} + +Кроки аналогічні налаштуванню для stacked etcd: + +- Переконайтеся, що перший вузол панелі управління повністю ініціалізований. +- Приєднайте кожен вузол панелі управління за допомогою команди приєднання, яку ви зберегли в текстовий файл. Рекомендується приєднувати вузли панелі управління по одному. +- Не забудьте, що ключ розшифрування з параметром `--certificate-key` діє дві години. + +## Загальні завдання після налаштування панелі управління {#common-tasks-after-bootstraping-control-plane} + +### Встановлення робочих вузлів {#installing-workers} + +Робочі вузли можна приєднати до кластера за допомогою команди, яку ви зберегли раніше як вивід з команди `kubeadm init`: + +```sh +sudo kubeadm join 192.168.0.200:6443 --token 9vr73a.a8uxyaju799qwdjv --discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866 +``` + +## Ручне поширення сертифікатів {#manual-certs} + +Якщо ви вирішили не використовувати `kubeadm init` з параметром `--upload-certs`, це означає, що вам доведеться вручну скопіювати сертифікати з первинного вузла панелі управління до приєднуваних вузлів панелі. + +Є багато способів це зробити. У наступному прикладі використовуються `ssh` та `scp`: + +SSH потрібен, якщо ви хочете керувати всіма вузлами з одного пристрою. + +1. Активуйте ssh-agent на своєму основному пристрої, який має доступ до всіх інших вузлів в системі: + + ```shell + eval $(ssh-agent) + ``` + +1. Додайте свій SSH-ідентифікатор до сеансу: + + ```shell + ssh-add ~/.ssh/path_to_private_key + ``` + +1. Перемикайтесь між вузлами, щоб перевірити, чи зʼєднання правильно працює. + + - Коли ви входите в будь-який вузол через SSH, додайте прапорець `-A`. Цей прапорець дозволяє вузлу, на який ви увійшли за допомогою SSH, отримувати доступ до агента SSH на вашому ПК. Розгляньте альтернативні методи, якщо ви не повністю довіряєте безпеці вашої сесії користувача на вузлі. + + ```shell + ssh -A 10.0.0.7 + ``` + + - Коли використовуєте sudo на будь-якому вузлі, обовʼязково зберігайте середовище, щоб SSH forwarding працював: + + ```shell + sudo -E -s + ``` + +1. Після налаштування SSH на всіх вузлах ви повинні запустити наступний скрипт на першому вузлі панелі управління після запуску `kubeadm init`. Цей скрипт скопіює сертифікати з першого вузла панелі управління на інші вузли панелі: + + У наступному прикладі замініть `CONTROL_PLANE_IPS` на IP-адреси інших вузлів панелі управління. + + ```sh + USER=ubuntu # налаштовується + CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8" + for host in ${CONTROL_PLANE_IPS}; do + scp /etc/kubernetes/pki/ca.crt "${USER}"@$host: + scp /etc/kubernetes/pki/ca.key "${USER}"@$host: + scp /etc/kubernetes/pki/sa.key "${USER}"@$host: + scp /etc/kubernetes/pki/sa.pub "${USER}"@$host: + scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host: + scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host: + scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt + # Пропустіть наступний рядок, якщо використовуєте зовнішній etcd + scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key + done + ``` + + {{< caution >}} + Копіюйте лише сертифікати в переліку вище. kubeadm буде опікуватись генеруванням решти сертифікатів з необхідними SAN для приєднання екземплярів панелі управління. Якщо ви помилитесь при копіюванні всіх сертифікатів, створення додаткових вузлів може зазнати невдачі через відсутність необхідних SAN. + {{< /caution >}} + +1. Потім на кожному приєднуваному вузлі панелі управління вам слід виконати наступний скрипт перед виконанням `kubeadm join`. Цей скрипт перемістить раніше скопійовані сертифікати з домашньої теки в `/etc/kubernetes/pki`: + + ```sh + USER=ubuntu # налаштовується + mkdir -p /etc/kubernetes/pki/etcd + mv /home/${USER}/ca.crt /etc/kubernetes/pki/ + mv /home/${USER}/ca.key /etc/kubernetes/pki/ + mv /home/${USER}/sa.pub /etc/kubernetes/pki/ + mv /home/${USER}/sa.key /etc/kubernetes/pki/ + mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/ + mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/ + mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt + # Пропустіть наступний рядок, якщо використовуєте зовнішній etcd + mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key + ``` diff --git a/content/uk/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/uk/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md new file mode 100644 index 0000000000000..a0528312ead82 --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -0,0 +1,296 @@ +--- +title: Встановлення kubeadm +content_type: concept +weight: 10 +card: + name: setup + weight: 40 + title: Встановлення інструменту розгортання кластерів kubeadm +--- + + + + + +Ця сторінка показує, як встановити інструменти `kubeadm`. Для отримання інформації щодо того, як створити кластер за допомогою kubeadm після виконання цього процесу встановлення, див. сторінку [Створення кластера за допомогою kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). + +{{< doc-versions-list "installation guide" >}} + +## {{% heading "prerequisites" %}} {#before-you-begin} + +* Сумісний хост на основі Linux. Проєкт Kubernetes надає загальні інструкції для дистрибутивів Linux, зокрема на базі Debian та Red Hat, а також для дистрибутивів без менеджера пакетів. +* 2 ГБ або більше оперативної памʼяті на кожній машині (менше може залишити мало місця для ваших застосунків). +* 2 процесори або більше. +* Повноцінне мережеве зʼєднання між усіма машинами в кластері (публічна чи приватна мережа підходить). +* Унікальні імена хостів, MAC-адреси та product_uuid для кожного вузла. Див. [тут](#verify-mac-address) для отримання докладнішої інформації. +* Відкриті певні порти на ваших машинах. Див. [тут](#check-required-ports) для отримання докладнішої інформації. +* Конфігурація swap. Починаючи з версії v1.22, обрана поведінка kubelet полягає в тому, щоб відмовлятися запускатися, якщо на вузлі виявлено swap. Swap підтримується починаючи з версії v1.22. З версії v1.28 підтримується swap лише для cgroup v2; feature gate NodeSwap в kubelet є бета-версією, типово відключений. + * Ви **ПОВИННІ** вимкнути swap, якщо kubelet не налаштований на використання swap. Наприклад, `sudo swapoff -a` вимкне обмін тимчасово. Щоб зробити ці зміни постійними після перезавантаження, переконайтеся, що swap вимкнено у файлах конфігурації, таких як `/etc/fstab`, `systemd.swap`, залежно від того, як він був налаштований у вашій системі. + +{{< note >}} +Встановлення за допомогою `kubeadm` виконується за допомогою бінарних файлів, які використовують динамічне звʼязування та передбачають, що ваша цільова система надає бібліотеку `glibc`. Це припущення стосується багатьох дистрибутивів Linux (включаючи Debian, Ubuntu, Fedora, CentOS і т. д.), але не завжди відповідає дійсності у випадку власних та легких дистрибутивів, які типово не включають `glibc`, наприклад, Alpine Linux. Очікується, що дистрибутив включає або [шар сумісності](https://wiki.alpinelinux.org/wiki/Running_glibc_programs), який забезпечує необхідні символи, або `glibc`. +{{< /note >}} + + + +## Перевірка унікальності MAC-адрес та product_uuid для кожного вузла {#verify-mac-address} + +* Ви можете отримати MAC-адресу мережевих інтерфейсів за допомогою команди `ip link` або `ifconfig -a`. +* product_uuid можна перевірити за допомогою команди `sudo cat /sys/class/dmi/id/product_uuid`. + +Ймовірно, що апаратні пристрої матимуть унікальні адреси, хоча деякі віртуальні машини можуть мати ідентичні значення. Kubernetes використовує ці значення для унікальної ідентифікації вузлів в кластері. Якщо ці значення не є унікальними для кожного вузла, процес встановлення може [завершитися невдачею](https://github.com/kubernetes/kubeadm/issues/31). + +## Перевірка мережевих адаптерів {#check-network-adapters} + +Якщо у вас є більше одного мережевого адаптера і компоненти Kubernetes недоступні за стандартним маршрутом, ми рекомендуємо додати IP-маршрут(и), щоб адреси кластера Kubernetes відповідали конкретному адаптеру. + +## Перевірка необхідних портів {#check-required-ports} + +Ці [необхідні порти](/docs/reference/networking/ports-and-protocols/) повинні бути відкриті для взаємодії компонентів Kubernetes між собою. Ви можете використовувати інструменти, такі як netcat, щоб перевірити, чи відкритий порт. Наприклад: + +```shell +nc 127.0.0.1 6443 +``` + +Мережевий втулок Podʼа, який ви використовуєте, також може вимагати, щоб певні порти були відкриті. Оскільки це відрізняється для кожного мережевого втулка, будь ласка, перегляньте їх документацію про те, які порти їм потрібні. + +## Встановлення середовища виконання контейнерів {#installing-runtime} + +Для запуску контейнерів у Pod, Kubernetes використовує {{< glossary_tooltip term_id="container-runtime" text="середовище виконання контейнерів" >}}. + +Стандартно Kubernetes використовує {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI), щоб взаємодіяти з обраним середовищем. + +Якщо ви не вказуєте середовище виконання, `kubeadm` автоматично намагається виявити встановлене середовище виконання контейнерів, скануючи список відомих точок доступу. + +Якщо виявлено кілька або жодного середовища виконання контейнерів, `kubeadm` повідомить про помилку та запросить вас вказати, яке середовище ви хочете використовувати. + +Дивіться [середовища виконання контейнерів](/docs/setup/production-environment/container-runtimes/) для отримання додаткової інформації. + +{{< note >}} +Рушій Docker не має реалізації [CRI](/docs/concepts/architecture/cri/), що є вимогою для роботи контейнерного середовища в Kubernetes. З цього приводу слід встановити додатковий сервіс [cri-dockerd](https://github.com/Mirantis/cri-dockerd). +`cri-dockerd` — це проєкт, побудований на основі колишньої вбудованої підтримки Docker Engine, яка була [вилучена](/dockershim) з kubelet у версії 1.24. +{{< /note >}} + +Наведені нижче таблиці містять відомі кінцеві точки для підтримуваних операційних систем: + +{{< tabs name="container_runtime" >}} +{{% tab name="Linux" %}} + +{{< table caption="Linux container runtimes" >}} +| Середовище виконання | Шлях до Unix socket | +|------------------------------------|----------------------------------------------| +| containerd | `unix:///var/run/containerd/containerd.sock` | +| CRI-O | `unix:///var/run/crio/crio.sock` | +| Docker Engine (з cri-dockerd) | `unix:///var/run/cri-dockerd.sock` | +{{< /table >}} + +{{% /tab %}} + +{{% tab name="Windows" %}} + +{{< table caption="Windows container runtimes" >}} +| Середовище виконання | Шлях до іменованого pipe Windows | +|------------------------------------|----------------------------------------------| +| containerd | `npipe:////./pipe/containerd-containerd` | +| Docker Engine (з cri-dockerd) | `npipe:////./pipe/cri-dockerd` | +{{< /table >}} + +{{% /tab %}} +{{< /tabs >}} + +## Встановлення kubeadm, kubelet та kubectl {#install-kubeadm-kubelet-and-kubectl} + +Ви повинні встановити ці пакунки на всіх своїх машинах: + +* `kubeadm`: команда для ініціалізації кластера. + +* `kubelet`: компонент, який працює на всіх машинах у вашому кластері та виконує такі дії, як запуск підсистем та контейнерів. + +* `kubectl`: утиліта командного рядка для взаємодії з вашим кластером. + +kubeadm **не буде** встановлювати або керувати `kubelet` або `kubectl` за вас, тому вам потрібно забезпечити відповідність їх версії панелі управління Kubernetes, яку ви хочете, щоб `kubeadm` встановив для вас. Якщо цього не зробити, існує ризик змішування версій, що може призвести до непередбачуваної та неправильної роботи. Однак _одина_ невелика розбіжність між `kubelet` та панеллю управління підтримується, але версія `kubelet` ніколи не повинна перевищувати версію API сервера. Наприклад, `kubelet` версії 1.7.0 буде повністю сумісний з API-сервером версії 1.8.0, але не навпаки. + +Щодо інформації про встановлення `kubectl`, див. [Встановлення та налаштування kubectl](/docs/tasks/tools/). + +{{< warning >}} +Ці інструкції виключають усі пакунки Kubernetes з будь-яких оновлень системи. Це через те, що `kubeadm` та Kubernetes вимагають [спеціальної уваги під час оновлення](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). +{{}} + +Докладніше про відмінності версій: + +* [Політика версій та відмінностей](/docs/setup/release/version-skew-policy/) Kubernetes +* [Політика відмінностей версій для kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) + +{{% legacy-repos-deprecation %}} + +{{< note >}} +Є окремий репозиторій пакунків для кожної мінорної версії Kubernetes. Якщо ви хочете встановити іншу мінорну версію, крім {{< skew currentVersion >}}, див. посібник з встановлення для бажаної мінорної версії. +{{< /note >}} + +{{< tabs name="k8s_install" >}} +{{% tab name="Debian-подібні дистрибутиви" %}} + +Ці інструкції для Kubernetes {{< skew currentVersion >}}. + +1. Оновіть індекс пакунків `apt` та встановіть пакунки, необхідні для використання репозитарію Kubernetes `apt`: + + ```shell + sudo apt-get update + # apt-transport-https може бути фіктивним пакунком; якщо це так, ви можете пропустити цей крок + sudo apt-get install -y apt-transport-https ca-certificates curl gpg + ``` + +2. Завантажте публічний ключ підпису для репозиторіїв пакунків Kubernetes. Той самий ключ підпису використовується для всіх репозитаріїв, тому ви можете ігнорувати версію в URL: + + ```shell + # Якщо каталог `/etc/apt/keyrings` не існує, його слід створити до команди curl, прочитайте нижче наведене примітку. + # sudo mkdir -p -m 755 /etc/apt/keyrings + curl -fsSL https://pkgs.k8s.io/core:/stable:/{{< param "version" >}}/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg + ``` + +{{< note >}} +У випусках старших за Debian 12 та Ubuntu 22.04 теки `/etc/apt/keyrings` типово не існує, її слід створити до команди curl. +{{< /note >}} + +3. Додайте відповідний репозиторій Kubernetes `apt`. Зверніть увагу, що цей репозиторій містить пакунки лише для Kubernetes {{< skew currentVersion >}}; для інших мінорних версій Kubernetes вам потрібно змінити мінорну версію Kubernetes в URL так, щоб вона відповідала вашій бажаній мінорній версії (також перевірте, чи ви ознайомились з документацією для версії Kubernetes, яку ви плануєте встановити). + + ```shell + # Це перезаписує будь-яку наявну конфігурацію в /etc/apt/sources.list.d/kubernetes.list + echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/{{< param "version" >}}/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list + ``` + +4. Оновіть індекс пакунків `apt`, встановіть kubelet, kubeadm та kubectl, та зафіксуйте їх версію: + + ```shell + sudo apt-get update + sudo apt-get install -y kubelet kubeadm kubectl + sudo apt-mark hold kubelet kubeadm kubectl + ``` + +{{% /tab %}} +{{% tab name="Red Hat-подібні дистрибутиви" %}} + +1. Встановіть SELinux у режим `permissive`: + + Ці інструкції для Kubernetes {{< skew currentVersion >}}. + + ```shell + # Встановити SELinux у режим `permissive` (фактично відключити його) + sudo setenforce 0 + sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config + ``` + +{{< caution >}} + +* Встановлення SELinux у режим `permissive` за допомогою виконання `setenforce 0` та `sed ...` фактично його вимикає. Це необхідно для того, щоб дозволити контейнерам отримувати доступ до файлової системи хосту, наприклад, деякі мережеві застосунки кластера вимагають цього. Ви повинні зробити це до тих пір, поки підтримка SELinux не буде покращена в kubelet. +* Ви можете залишити увімкненим SELinux, якщо ви знаєте, як його налаштувати, але це може вимагати налаштувань, які не підтримуються kubeadm. + +{{< /caution >}} + +1. Додайте репозиторій Kubernetes `yum`. Параметр `exclude` в визначенні репозиторію забезпечує, що пакунки, повʼязані з Kubernetes, не оновлюються при виконанні `yum update`, оскільки є спеціальна процедура, якої слід дотримуватися для оновлення Kubernetes. Зверніть увагу, що цей репозиторій має пакунки лише для Kubernetes {{< skew currentVersion >}}; для інших мінорних версій Kubernetes вам потрібно змінити мінорну версію Kubernetes в URL так, щоб вона відповідала вашій бажаній мінорній версії (також перевірте, чи ви ознайомились з документацією для версії Kubernetes, яку ви плануєте встановити). + + ```shell + # Це перезаписує будь-яку існуючу конфігурацію в /etc/yum.repos.d/kubernetes.repo + cat <}}/rpm/ + enabled=1 + gpgcheck=1 + gpgkey=}}/rpm/repodata/repomd.xml.key + exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni + EOF + + ``` + +2. Встановіть kubelet, kubeadm та kubectl, та активуйте kubelet, щоб він автоматично запускається при запуску: + + ```shell + sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes + sudo systemctl enable --now kubelet + ``` + +{{% /tab %}} +{{% tab name="Без менеджера пакунків" %}} + +Встановіть втулки CNI (необхідно для більшості мережевих підсистем): + +```bash +CNI_PLUGINS_VERSION="v1.3.0" +ARCH="amd64" +DEST="/opt/cni/bin" +sudo mkdir -p "$DEST" +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_PLUGINS_VERSION}/cni-plugins-linux-${ARCH}-${CNI_PLUGINS_VERSION}.tgz" | sudo tar -C "$DEST" -xz +``` + +Визначте теку для завантаження файлів команд: + +{{< note >}} +Змінна `DOWNLOAD_DIR` повинна бути встановлена на теку з правами на запис. Якщо ви використовуєте Flatcar Container Linux, встановіть `DOWNLOAD_DIR="/opt/bin"`. +{{< /note >}} + +```bash +DOWNLOAD_DIR="/usr/local/bin" +sudo mkdir -p "$DOWNLOAD_DIR" +``` + +Встановіть crictl (необхідно для kubeadm / Kubelet Container Runtime Interface (CRI)): + +```bash +CRICTL_VERSION="v1.28.0" +ARCH="amd64" +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz +``` + +Встановіть `kubeadm`, `kubelet`, `kubectl` та додайте службу `kubelet` systemd: + +```bash +RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" +ARCH="amd64" +cd $DOWNLOAD_DIR +sudo curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet} +sudo chmod +x {kubeadm,kubelet} + +RELEASE_VERSION="v0.16.2" +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubelet/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service +sudo mkdir -p /etc/systemd/system/kubelet.service.d +curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/krel/templates/latest/kubeadm/10-kubeadm.conf" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service.d/10-kubeadm.conf +``` + +{{< note >}} +Звіртесь з примітками в розділі [Перш ніж ви розпочнете](#before-you-begin) для дистрибутивів Linux, які типово не містять `glibc`. +{{< /note >}} + +Встановіть `kubectl`, слідкуючи інструкціям на сторінці [Встановлення інструментів](/docs/tasks/tools/#kubectl). + +Активуйте та запустіть `kubelet`: + +```bash +systemctl enable --now kubelet +``` + +{{< note >}} +Дистрибутив Flatcar Container Linux монтує теку `/usr` як файлову систему тільки для читання. Перед ініціалізацією кластера вам потрібно виконати додаткові кроки для налаштування теки для запису. Див. [Посібник з усунення несправностей kubeadm](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#usr-mounted-read-only), щоб дізнатися, як налаштувати теку для запису. +{{< /note >}} +{{% /tab %}} +{{< /tabs >}} + +Kubelet тепер перезавантажується кожні кілька секунд, чекаючи в циклі crashloop на вказівки від kubeadm. + +## Налаштування драйвера cgroup {#configure-a-cgroup-driver} + +Як середовище виконання контейнерів, так і kubelet мають властивість, відому як ["cgroup driver"](/docs/setup/production-environment/container-runtimes/#cgroup-drivers), яка є важливою для управління cgroup на машинах з операційною системою Linux. + +{{< warning >}} +Обовʼязково встановлюйте спільний драйвер cgroup для середовища виконання контейнерів та kubelet, інакше процес kubelet завершиться із помилкою. + +Докладніше дивіться в розділі [Налаштування драйвера cgroup](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/). +{{< /warning >}} + +## Розвʼязання проблем {#troubleshooting} + +Якщо у вас виникають труднощі з kubeadm, будь ласка, звертайтеся до наших [документів щодо розвʼязання проблем](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). + +## {{% heading "whatsnext" %}} + +* [Створення кластера за допомогою kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) diff --git a/content/uk/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md b/content/uk/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md new file mode 100644 index 0000000000000..53aba7cc3c875 --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md @@ -0,0 +1,153 @@ +--- +reviewers: +- sig-cluster-lifecycle +title: Налаштування кожного kubelet у кластері за допомогою kubeadm +content_type: concept +weight: 80 +--- + + + +{{% dockershim-removal %}} + +{{< feature-state for_k8s_version="v1.11" state="stable" >}} + +Життєвий цикл інструменту командного рядка kubeadm не повʼязаний з [kubelet](/docs/reference/command-line-tools-reference/kubelet), який є службою, що працює на кожному вузлі в кластері Kubernetes. Інструмент командного рядка kubeadm запускається користувачем під час ініціалізації або оновлення Kubernetes, тоді як kubelet завжди працює в фоновому режимі. + +Оскільки kubelet — це демон, його потрібно обслуговувати за допомогою якоїсь системи ініціалізації або менеджера служб. Коли kubelet встановлено за допомогою DEB або RPM-пакунків, systemd налаштовується для управління kubelet. Ви можете використовувати інший менеджер служб, але його потрібно налаштувати вручну. + +Деякі деталі конфігурації kubelet повинні бути однакові для всіх kubelet, які беруть участь в кластері, тоді як інші аспекти конфігурації повинні бути встановлені для кожного kubelet окремо, щоб врахувати різні характеристики кожної машини (такі як ОС, сховище та мережа). Ви можете керувати конфігурацією +kubelet вручну, але тепер kubeadm надає API-тип `KubeletConfiguration` для[централізованого управління конфігураціями kubelet](#configure-kubelets-using-kubeadm). + + + +## Шаблони конфігурації kubelet {#kubelet-configuration-patterns} + +У наступних розділах описано шаблони конфігурації kubelet, які спрощуються за допомогою kubeadm, замість керування конфігурацією kubelet для кожного вузла вручну. + +### Поширення конфігурації на рівні кластера для кожного kubelet {#propagating-cluster-level-configuration-to-each-kubelet} + +Ви можете надати kubelet стандартне значення для використання команд `kubeadm init` та `kubeadm join`. Цікаві приклади охоплюють використання іншого середовища виконання контейнерів або встановлення типової підмережі, яку використовують служби. + +Якщо ви хочете, щоб ваші служби використовували мережу `10.96.0.0/12`, ви можете передати параметр `--service-cidr` в kubeadm: + +```bash +kubeadm init --service-cidr 10.96.0.0/12 +``` + +Віртуальні IP-адреси для служб тепер виділяються з цієї підмережі. Вам також потрібно встановити адресу DNS, яку використовує kubelet, за допомогою прапорця `--cluster-dns`. Це налаштування мають бути однаковим для кожного kubelet +на кожному вузлі управління та вузлі в кластері. Kubelet надає структурований, версійований обʼєкт API, який може налаштовувати більшість параметрів в kubelet та розсилати цю конфігурацію кожному працюючому kubelet в кластері. Цей обʼєкт називається [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/). `KubeletConfiguration` дозволяє користувачу вказувати прапорці, такі як IP-адреси DNS кластера, у вигляді списку значень для camelCased ключа, як показано в наступному прикладі: + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +clusterDNS: +- 10.96.0.10 +``` + +Докладніше про `KubeletConfiguration` можна знайти у [цьому розділі](#configure-kubelets-using-kubeadm). + +### Надання конфігурації, специфічної для екземпляра {#providing-instance-specific-configuration-details} + +Деякі хости вимагають специфічних конфігурацій kubelet через різницю в апаратному забезпеченні, операційній системі, мережевій конфігурації чи інших параметрах, специфічних для хосту. У наступному переліку наведено кілька прикладів. + +- Шлях до файлу розвʼязання DNS, як вказано прапорцем конфігурації kubelet `--resolv-conf`, може відрізнятися залежно від операційної системи або від того, чи використовується `systemd-resolved`. Якщо цей шлях вказано неправильно, розвʼязування DNS буде невдалим на вузлі, конфігурація kubelet якого налаштована неправильно. + +- Обʼєкт API вузла `.metadata.name` типово вказує імʼя хосту машини, якщо ви не використовуєте хмарного постачальника. Ви можете використовувати прапорець `--hostname-override`, щоб змінити типову поведінку, якщо вам потрібно вказати імʼя вузла, відмінне від імені хосту машини. + +- Зараз kubelet не може автоматично виявити драйвер cgroup, який використовується середовищем виконання контейнерів, але значення `--cgroup-driver` повинно відповідати драйверу cgroup, який використовується середовищем виконання контейнерів, щоб забезпечити нормальну роботу kubelet. + +- Щоб вказати середовище виконання контейнерів, вам потрібно встановити його endpoint за допомогою прапорця `--container-runtime-endpoint=<шлях>`. + +Рекомендований спосіб застосування такої конфігурації, специфічної для екземпляра, — використовувати [патчі для KubeletConfiguration](/docs/setup/production-environment/tools/kubeadm/control-plane-flags#patches). + +## Налаштування kubelet за допомогою kubeadm {#configure-kubelets-using-kubeadm} + +Можливо налаштувати kubelet, який запустить kubeadm, якщо вказано власний обʼєкт API [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) +з конфігураційним файлом таким чином `kubeadm ... --config some-config-file.yaml`. + +Викликаючи `kubeadm config print init-defaults --component-configs KubeletConfiguration`, ви можете переглянути всі типові значення для цієї структури. + +Також можливо застосувати специфічні для екземпляра патчі до базового `KubeletConfiguration`. Див. [Налаштування kubelet](/docs/setup/production-environment/tools/kubeadm/control-plane-flags#customizing-the-kubelet) для отримання докладнішої інформації. + +### Послідовність дій при використанні `kubeadm init` {#workflow-when-using-kubeadm-init} + +Коли ви викликаєте `kubeadm init`, конфігурація kubelet записується на диск +в `/var/lib/kubelet/config.yaml` і також завантажується в ConfigMap `kubelet-config` в просторі імен `kube-system` кластера. Файл конфігурації kubelet також записується у `/etc/kubernetes/kubelet.conf` із базовою конфігурацією кластера для всіх kubelet в кластері. Цей файл конфігурації вказує на клієнтські сертифікати, які дозволяють kubelet взаємодіяти з сервером API. Це вирішує необхідність [поширення конфігурації на рівні кластера для кожного kubelet](#propagating-cluster-level-configuration-to-each-kubelet). + +Щоб вирішити другий шаблон [надання конфігурації, специфічної для екземпляра](#providing-instance-specific-configuration-details), kubeadm записує файл середовища у `/var/lib/kubelet/kubeadm-flags.env`, який містить список прапорців, які слід передати kubelet при запуску. Прапорці виглядають у файлі наступним чином: + +```bash +KUBELET_KUBEADM_ARGS="--flag1=value1 --flag2=value2 ..." +``` + +Крім прапорців, використовуваних при запуску kubelet, файл також містить динамічні параметри, такі як драйвер cgroup та використання іншого сокету контейнерного середовища (`--cri-socket`). + +Після того як ці два файли конвертуються на диск, kubeadm намагається виконати дві команди, якщо ви використовуєте systemd: + +```bash +systemctl daemon-reload && systemctl restart kubelet +``` + +Якщо перезавантаження та перезапуск вдалися, продовжується звичайний робочий процес `kubeadm init`. + +### Послідовність при використанні `kubeadm join` {#workflow-when-using-kubeadm-join} + +Коли ви викликаєте `kubeadm join`, kubeadm використовує облікові дані Bootstrap Token, щоб виконати запуск TLS, який отримує необхідні облікові дані для завантаження `kubelet-config` ConfigMap та записує його в `/var/lib/kubelet/config.yaml`. Файл середовища генерується точно так само, як і при `kubeadm init`. + +Далі `kubeadm` виконує дві команди для завантаження нової конфігурації в kubelet: + +```bash +systemctl daemon-reload && systemctl restart kubelet +``` + +Після завантаження нової конфігурації kubelet, kubeadm записує `/etc/kubernetes/bootstrap-kubelet.conf` файл конфігурації KubeConfig, який містить сертифікат CA та Bootstrap Token. Ці дані використовуються kubelet для виконання TLS Bootstrap та отримання унікальних облікових даних, які зберігається в `/etc/kubernetes/kubelet.conf`. + +Коли файл `/etc/kubernetes/kubelet.conf` записаний, kubelet завершує виконання TLS Bootstrap. Kubeadm видаляє файл `/etc/kubernetes/bootstrap-kubelet.conf` після завершення TLS Bootstrap. + +## Файл kubelet drop-in для systemd {#the-kubelet-drop-in-file-for-systemd} + +`kubeadm` постачається з конфігурацією systemd для запуску kubelet. Зверніть увагу, що команда kubeadm CLI ніколи не торкається цього drop-in файлу. + +Цей файл конфігурації, встановлений за допомогою `kubeadm` +[пакета](https://github.com/kubernetes/release/blob/cd53840/cmd/krel/templates/latest/kubeadm/10-kubeadm.conf), записується в `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` та використовується systemd. Він доповнює основний +[`kubelet.service`](https://github.com/kubernetes/release/blob/cd53840/cmd/krel/templates/latest/kubelet/kubelet.service): + +{{< note >}} +Наведені нижче вміст — це лише приклад. Якщо ви не хочете використовувати менеджер пакунків, дотримуйтеся інструкції, описаної в розділі ([Без менеджера пакунків](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#k8s-install-2)). +{{< /note >}} + +```none +[Service] +Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf" +Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml" +# Це файл, який "kubeadm init" та "kubeadm join" генерують в режимі виконання, заповнюючи +# змінну KUBELET_KUBEADM_ARGS динамічно +EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env +# Це файл, який користувач може використовувати для заміщення аргументів kubelet як останній захист. В ідеалі, +# користувач повинен використовувати обʼєкт .NodeRegistration.KubeletExtraArgs в файлах конфігурації. +# KUBELET_EXTRA_ARGS повинен бути джерелом цього файлу. +EnvironmentFile=-/etc/default/kubelet +ExecStart= +ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS +``` + +Цей файл вказує на типове знаходження для всіх файлів, які керуються kubeadm для kubelet. + +- Файл KubeConfig для TLS Bootstrap — `/etc/kubernetes/bootstrap-kubelet.conf`, але він використовується тільки у випадку, якщо `/etc/kubernetes/kubelet.conf` не існує. +- Файл KubeConfig з унікальними ідентифікаційними даними kubelet — `/etc/kubernetes/kubelet.conf`. +- Файл, що містить ComponentConfig kubelet — `/var/lib/kubelet/config.yaml`. +- Динамічний файл середовища, що містить `KUBELET_KUBEADM_ARGS`, взятий з `/var/lib/kubelet/kubeadm-flags.env`. +- Файл, що може містити перевизначення прапорців, вказаних користувачем за допомогою `KUBELET_EXTRA_ARGS`, береться з `/etc/default/kubelet` (для DEB) або `/etc/sysconfig/kubelet` (для RPM). `KUBELET_EXTRA_ARGS` останній в ланцюжку прапорців та має найвищий пріоритет у випадку конфлікту налаштувань. + +## Бінарні файли Kubernetes та вміст пакунків {#kubernetes-binaries-and-package-contents} + +DEB та RPM-пакети, які постачаються з випусками Kubernetes: + +| Назва пакунка | Опис | +|--------------|-------------| +| `kubeadm` | Встановлює інструмент командного рядка `/usr/bin/kubeadm` та [файл drop-in для kubelet](#the-kubelet-drop-in-file-for-systemd) для kubelet. | +| `kubelet` | Встановлює виконавчий файл `/usr/bin/kubelet`. | +| `kubectl` | Встановлює виконавчий файл `/usr/bin/kubectl`. | +| `cri-tools` | Встановлює виконавчий файл `/usr/bin/crictl` з [репозиторію git cri-tools](https://github.com/kubernetes-sigs/cri-tools). | +| `kubernetes-cni` | Встановлює бінарні файли `/opt/cni/bin` з [репозиторію git plugins](https://github.com/containernetworking/plugins). | diff --git a/content/uk/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/uk/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md new file mode 100644 index 0000000000000..b50c01a3cd00d --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -0,0 +1,289 @@ +--- +reviewers: +- sig-cluster-lifecycle +title: Налаштування високодоступного кластера etcd за допомогою kubeadm +content_type: task +weight: 70 +--- + + + +{{< note >}} +Використовуючи kubeadm як інструмент управління для зовнішніх вузлів etcd +у цьому посібнику, слід зауважити, що kubeadm не планує підтримувати ротацію сертифікатів чи оновлення для таких вузлів. Довгостроковим планом є надання інструменту [etcdadm](https://github.com/kubernetes-sigs/etcdadm) можливостей управління цими аспектами. +{{< /note >}} + +Типово kubeadm запускає локальний екземпляр etcd на кожному вузлі панелі управління Також можливо розглядати кластер etcd як зовнішній та розгортати екземпляри etcd на окремих хостах. Відмінності між цими підходами описано на сторінці +[Варіанти топології високої доступності](/docs/setup/production-environment/tools/kubeadm/ha-topology). + +Це завдання веде через процес створення кластера високої доступності з зовнішньою базою etcd із трьох членів, який може використовувати kubeadm під час створення кластера. + +## {{% heading "prerequisites" %}} + +- Три хости, які можуть взаємодіяти між собою через TCP-порти 2379 та 2380. Цей + документ вважає, що це стандартні порти. Однак їх можна налаштувати через + файл конфігурації kubeadm. +- На кожному хості повинен бути встановлений systemd та сумісна з bash оболонка. +- На кожному хості повинно бути встановлене [середовище виконання контейнерів, kubelet та kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). +- Кожен хост повинен мати доступ до реєстру образів контейнерів Kubernetes (`registry.k8s.io`) або ви можете отримати перелік та/або витягти необхідний образ etcd, використовуючи `kubeadm config images list/pull`. У цьому посібнику екземпляри etcd налаштовані як [статичні Podʼи](/docs/tasks/configure-pod-container/static-pod/), керовані kubelet. +- Є якась інфраструктура для копіювання файлів між хостами. Наприклад, `ssh` та `scp` можуть відповідати цьому вимогу. + + + +## Налаштування кластера {#setup-up-the-cluster} + +Загальний підхід — генерувати всі сертифікати на одному вузлі та розповсюджувати лише _необхідні_ файли на інші вузли. + +{{< note >}} +kubeadm містить усі необхідні криптографічні механізми для генерації описаних нижче сертифікатів; для цього прикладу не потрібні інші криптографічні інструменти. +{{< /note >}} + +{{< note >}} +У прикладах нижче використовуються адреси IPv4, але ви також можете налаштувати kubeadm, kubelet та etcd на використання адрес IPv6. Підтримка подвійного стека передбачена для деяких параметрів Kubernetes, але не для etcd. Докладніше +щодо підтримки подвійного стека Kubernetes дивіться [Підтримка подвійного стека з kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/). +{{< /note >}} + +1. Налаштуйте kubelet як менеджер служб для etcd. + + {{< note >}}Це потрібно зробити на кожному хості, на якому повинен працювати etcd.{{< /note >}} + Оскільки etcd був створений першим, вам слід перевизначити пріоритет служби, створивши новий файл юніта, який має вищий пріоритет, ніж файл юніта kubelet, який надає kubeadm. + + ```sh + cat << EOF > /etc/systemd/system/kubelet.service.d/kubelet.conf + # Замініть "systemd" на драйвер cgroup вашого середовища виконання контейнерів. Стандартне значення в kubelet - "cgroupfs". + # Замініть значення "containerRuntimeEndpoint" на інше середовище виконання контейнерів за потреби. + # + apiVersion: kubelet.config.k8s.io/v1beta1 + kind: KubeletConfiguration + authentication: + anonymous: + enabled: false + webhook: + enabled: false + authorization: + mode: AlwaysAllow + cgroupDriver: systemd + address: 127.0.0.1 + containerRuntimeEndpoint: unix:///var/run/containerd/containerd.sock + staticPodPath: /etc/kubernetes/manifests + EOF + + cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf + [Service] + ExecStart= + ExecStart=/usr/bin/kubelet --config=/etc/systemd/system/kubelet.service.d/kubelet.conf + Restart=always + EOF + + systemctl daemon-reload + systemctl restart kubelet + ``` + + Перевірте статус kubelet, щоб переконатися, що він працює. + + ```sh + systemctl status kubelet + ``` + +2. Створіть конфігураційні файли для kubeadm. + + Згенеруйте один файл конфігурації kubeadm для кожного хосту, на якому буде запущений екземпляр etcd, використовуючи наступний сценарій. + + ```sh + # Оновіть HOST0, HOST1 та HOST2 IP ваших хостів + export HOST0=10.0.0.6 + export HOST1=10.0.0.7 + export HOST2=10.0.0.8 + + # Оновіть NAME0, NAME1 та NAME2 іменами хостів + export NAME0="infra0" + export NAME1="infra1" + export NAME2="infra2" + + # Створіть тимчасові теки для зберігання файлів, які потраплять на інші хости + mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/ + + HOSTS=(${HOST0} ${HOST1} ${HOST2}) + NAMES=(${NAME0} ${NAME1} ${NAME2}) + + for i in "${!HOSTS[@]}"; do + HOST=${HOSTS[$i]} + NAME=${NAMES[$i]} + cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml + --- + apiVersion: "kubeadm.k8s.io/v1beta3" + kind: InitConfiguration + nodeRegistration: + name: ${NAME} + localAPIEndpoint: + advertiseAddress: ${HOST} + --- + apiVersion: "kubeadm.k8s.io/v1beta3" + kind: ClusterConfiguration + etcd: + local: + serverCertSANs: + - "${HOST}" + peerCertSANs: + - "${HOST}" + extraArgs: + initial-cluster: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380 + initial-cluster-state: new + name: ${NAME} + listen-peer-urls: https://${HOST}:2380 + listen-client-urls: https://${HOST}:2379 + advertise-client-urls: https://${HOST}:2379 + initial-advertise-peer-urls: https://${HOST}:2380 + EOF + done + ``` + +3. Згенеруйте центр сертифікації. + + Якщо у вас вже є ЦС, то єдине що треба зробити — скопіювати файли `crt` та `key` ЦС у `/etc/kubernetes/pki/etcd/ca.crt` та `/etc/kubernetes/pki/etcd/ca.key`. Після копіювання цих файлів перейдіть до наступного кроку — "Створення сертифікатів для кожного учасника". + + Якщо у вас ще немає ЦС, то виконайте цю команду на `$HOST0` (де ви згенерували файли конфігурації для kubeadm). + + ```sh + kubeadm init phase certs etcd-ca + ``` + + Це створює два файли: + + - `/etc/kubernetes/pki/etcd/ca.crt` + - `/etc/kubernetes/pki/etcd/ca.key` + +4. Створення сертифікатів для кожного учасника. + + ```sh + kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml + kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml + kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml + kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml + cp -R /etc/kubernetes/pki /tmp/${HOST2}/ + # очистити одноразові сертифікати + find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete + + kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml + kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml + kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml + kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml + cp -R /etc/kubernetes/pki /tmp/${HOST1}/ + find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete + + kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml + kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml + kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml + kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml + # Немає потреби переміщувати сертифікати, оскільки вони призначені для HOST0 + + # приберемо сертифікати, які не повинні бути скопійовані з цього хоста + find /tmp/${HOST2} -name ca.key -type f -delete + find /tmp/${HOST1} -name ca.key -type f -delete + ``` + +5. Скопіюйте сертифікати та конфігурації kubeadm. + + Сертифікати вже були згенеровані, і тепер їх потрібно перемістити на відповідні хости. + + ```sh + USER=ubuntu + HOST=${HOST1} + scp -r /tmp/${HOST}/* ${USER}@${HOST}: + ssh ${USER}@${HOST} + USER@HOST $ sudo -Es + root@HOST $ chown -R root:root pki + root@HOST $ mv pki /etc/kubernetes/ + ``` + +6. Переконайтеся, що всі очікувані файли існують. + + Повний перелік обовʼязкових файлів на `$HOST0`: + + ```sh + /tmp/${HOST0} + └── kubeadmcfg.yaml + --- + /etc/kubernetes/pki + ├── apiserver-etcd-client.crt + ├── apiserver-etcd-client.key + └── etcd + ├── ca.crt + ├── ca.key + ├── healthcheck-client.crt + ├── healthcheck-client.key + ├── peer.crt + ├── peer.key + ├── server.crt + └── server.key + ``` + + На `$HOST1`: + + ```sh + $HOME + └── kubeadmcfg.yaml + --- + /etc/kubernetes/pki + ├── apiserver-etcd-client.crt + ├── apiserver-etcd-client.key + └── etcd + ├── ca.crt + ├── healthcheck-client.crt + ├── healthcheck-client.key + ├── peer.crt + ├── peer.key + ├── server.crt + └── server.key + ``` + + На `$HOST2`: + + ```sh + $HOME + └── kubeadmcfg.yaml + --- + /etc/kubernetes/pki + ├── apiserver-etcd-client.crt + ├── apiserver-etcd-client.key + └── etcd + ├── ca.crt + ├── healthcheck-client.crt + ├── healthcheck-client.key + ├── peer.crt + ├── peer.key + ├── server.crt + └── server.key + ``` + +7. Створіть маніфести статичних Podʼів. + + Тепер, коли сертифікати та конфігурації на місці, прийшов час створити маніфести для etcd. На кожному хості виконайте команду `kubeadm` для генерації статичного маніфесту для etcd. + + ```sh + root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml + root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml + root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml + ``` + +8. Опціонально: Перевірте стан кластера. + + Якщо `etcdctl` недоступний, ви можете запустити цей інструмент в середовищі контейнера. Ви можете це зробити безпосередньо з вашим середовищем виконання контейнерів за допомогою такого інструменту, як `crictl run`, а не через Kubernetes + + ```sh + ETCDCTL_API=3 etcdctl \ + --cert /etc/kubernetes/pki/etcd/peer.crt \ + --key /etc/kubernetes/pki/etcd/peer.key \ + --cacert /etc/kubernetes/pki/etcd/ca.crt \ + --endpoints https://${HOST0}:2379 endpoint health + ... + https://[HOST0 IP]:2379 is healthy: successfully committed proposal: took = 16.283339ms + https://[HOST1 IP]:2379 is healthy: successfully committed proposal: took = 19.44402ms + https://[HOST2 IP]:2379 is healthy: successfully committed proposal: took = 35.926451ms + ``` + + - Встановіть `${HOST0}`на IP-адресу хосту, який ви тестуєте. + +## {{% heading "whatsnext" %}} + +Коли у вас є кластер etcd з 3 робочими учасниками, ви можете продовжити налаштування високодоступного вузла панелі управління, використовуючи [метод зовнішнього etcd з kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/). diff --git a/content/uk/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/uk/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md new file mode 100644 index 0000000000000..90f383e0547fe --- /dev/null +++ b/content/uk/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -0,0 +1,464 @@ +--- +title: Розвʼязання проблем kubeadm +content_type: concept +weight: 20 +--- + + + +Так само як і з будь-якою іншою технологією, ви можете зіткнутися з проблемами під час встановлення або використання kubeadm. Цей документ містить список найпоширеніших проблем та їх рішень, пропонуючи вам кроки, які допоможуть зʼясувати та розвʼязати проблеми. + +Якщо вашої проблеми немає в переліку нижче, будь ласка, скористайтесь настпуним: + +- Ви вважаєте, що це помилка в kubeadm: + - Відвідайте [github.com/kubernetes/kubeadm](https://github.com/kubernetes/kubeadm/issues), пошукайте в списку наявних повідомлень. + - Якщо ви не знайшли свою проблему, створіть нове [повідомлення про проблему](https://github.com/kubernetes/kubeadm/issues/new) використовуючи готовий шаблон. + +- Ви не впевнені, що це проблема в роботі kubeadm, ви можете запитати в [Slack](https://slack.k8s.io/) в каналі `#kubeadm`, або поставити питання на [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes). Будь ласка, додайте теґи `#kubeadm` та `#kubernetes`. + + + +## Неможливо приєднати вузол v1.18 до кластера v1.17 через відсутність RBAC {#not-possible-to-join-a-v1-18-node-to-a-v1-17-cluster-due-to-missing-rbac} + +У версії v1.18 kubeadm додав запобігання приєднання вузла до кластера, якщо вузол з таким самим імʼям вже існує. Це вимагало додавання RBAC для користувача bootstrap-token для можливості виконання операції GET обʼєкта Node. + +Однак це викликає проблему, коли `kubeadm join` з v1.18 не може приєднатися до кластера, створеного за допомогою kubeadm v1.17. + +Для того, щоб оминути цю проблему у вас є два варіанти: + +Виконайте `kubeadm init phase bootstrap-token` на вузлі панелі управління за допомогою kubeadm v1.18. Зауважте, що це дозволяє інші дозволи bootstrap-token. + +або + +Застосуйте наступний RBAC вручну за допомогою `kubectl apply -f ...`: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: kubeadm:get-nodes +rules: + - apiGroups: + - "" + resources: + - nodes + verbs: + - get +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: kubeadm:get-nodes +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: kubeadm:get-nodes +subjects: + - apiGroup: rbac.authorization.k8s.io + kind: Group + name: system:bootstrappers:kubeadm:default-node-token +``` + +## `ebtables` або подібний виконавчий файл не знайдений під час встановлення {#ebtables-or-similar-executable-not-found-during-installation} + +Якщо ви бачите наступні попередження під час виконання `kubeadm init`: + +```console +[preflight] WARNING: ebtables not found in system path +[preflight] WARNING: ethtool not found in system path +``` + +Тоді вам може бракувати `ebtables`, `ethtool` або подібного виконавчого файлу на вашому вузлі. Ви можете встановити їх за допомогою наступних команд: + +- Для користувачів Ubuntu/Debian виконайте `apt install ebtables ethtool`. +- Для користувачів CentOS/Fedora виконайте `yum install ebtables ethtool`. + +## `kubeadm` блокується під час очікування на панель управління під час встановлення {#kubeadm-blocks-waiting-for-control-plane-during-installation} + +Якщо ви помічаєте, що `kubeadm init` зупиняється після виведення наступного рядка: + +```console +[apiclient] Created API client, waiting for the control plane to become ready +``` + +Це може бути спричинено кількома проблемами. Найбільш поширеними є: + +- проблеми з мережевим підключенням. Перш ніж продовжувати, перевірте, чи ваша машина має повне підключення до мережі. +- драйвер cgroup контейнера відрізняється від драйвера kubelet cgroup. Щоб зрозуміти, як правильно налаштувати це, див. [Налаштування драйвера cgroup](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/). +- контейнери панелі управління впадають в цикл або зупиняються. Ви можете перевірити це, використовуючи `docker ps` та вивчаючи кожен контейнер за допомогою `docker logs`. Для інших середовищ виконання контейнерів, див. [Налагодження вузлів Kubernetes за допомогою crictl](/docs/tasks/debug/debug-cluster/crictl/). + +## `kubeadm` блокується під час видалення керованих контейнерів {#kubeadm-blocks-when-removing-managed-containers} + +Наступне може трапитися, якщо середовище виконання контейнерів зупиняється і не видаляє жодних керованих контейнерів Kubernetes: + +```shell +sudo kubeadm reset +``` + +```console +[preflight] Running pre-flight checks +[reset] Stopping the kubelet service +[reset] Unmounting mounted directories in "/var/lib/kubelet" +[reset] Removing kubernetes-managed containers +(block) +``` + +Можливий варіант вирішення — перезапустити середовище виконання контейнерів, а потім знову запустити `kubeadm reset`. Ви також можете використовувати `crictl` для налагодження стану середовища виконання контейнерів. Див. [Налагодження вузлів Kubernetes за допомогою crictl](/docs/tasks/debug/debug-cluster/crictl/). + +## Podʼи у стані `RunContainerError`, `CrashLoopBackOff` або `Error` {#pods-in-runcontainererror-crashloopbackoff-or-error-state} + +Відразу після виконання `kubeadm init` не повинно бути жодних контейнерів у таких станах. + +- Якщо є контейнери в одному з цих станів _відразу після_ `kubeadm init`, будь ласка, створіть тікет в репозиторії kubeadm. `coredns` (або `kube-dns`) повинен перебувати у стані `Pending` до моменту розгортання додатка для мережі. +- Якщо ви бачите контейнери у стані `RunContainerError`, `CrashLoopBackOff` або `Error` після розгортання додатка для мережі та нічого не відбувається з `coredns` (або `kube-dns`), дуже ймовірно, що додаток Pod Network, який ви встановили, є пошкодженим. Можливо, вам потрібно надати йому більше привілеїв RBAC або використовувати новішу версію. Будь ласка, створіть тікет в системі відстеження проблем постачальника Pod Network та очікуйте розвʼязання проблеми там. + +## `coredns` застрягає у стані `Pending` {#coredns-is-stuck-in-the-pending-state} + +Це **очікувано** і є частиною дизайну. kubeadm є агностичним до мережі, тому адміністратор повинен [встановити вибраний додаток для мережі](/docs/concepts/cluster-administration/addons/) за власним вибором. Вам потрібно встановити Pod Network, перш ніж `coredns` може бути повністю розгорнутим. Таким чином, стан `Pending` перед налаштуванням мережі є нормальним. + +## Сервіси `HostPort` не працюють {#hostport-services-do-not-work} + +Функціональність `HostPort` та `HostIP` доступна залежно від вашого провайдера Pod Network. Будь ласка, звʼяжіться з автором додатка Pod Network, щоб дізнатися, чи +функціональність `HostPort` та `HostIP` доступна. + +Перевірено, що Calico, Canal та Flannel CNI підтримують HostPort. + +Для отримання додаткової інформації перегляньте [документацію CNI portmap](https://github.com/containernetworking/plugins/blob/master/plugins/meta/portmap/README.md). + +Якщо ваш постачальник мережі не підтримує втулок CNI portmap, можливо, вам доведеться використовувати [функцію NodePort для сервісів](/docs/concepts/services-networking/service/#type-nodeport) або використовуйте `HostNetwork=true`. + +## До Podʼів неможливо отримати доступ за їх Service IP {#pods-are-not-accessible-via-their-service-ip} + +- Багато додатків для мережі ще не увімкнули [режим hairpin](/docs/tasks/debug/debug-application/debug-service/#a-pod-fails-to-reach-itself-via-the-service-ip), який дозволяє Podʼам звертатися до себе за їх Service IP. Це повʼязано з [CNI](https://github.com/containernetworking/cni/issues/476). Будь ласка, звʼяжіться з постачальником додатка для мережі, щоб дізнатися про останній статус підтримки режиму hairpin. + +- Якщо ви використовуєте VirtualBox (безпосередньо, або через Vagrant), вам слід переконатися, що `hostname -i` повертає маршрутизовану IP-адресу. Типово перший інтерфейс підключений до немаршрутизованої мережі тільки для хосту. Як тимчасовий варіант, ви можете змінити `/etc/hosts`, подивіться цей [Vagrantfile](https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11) для прикладу. + +## Помилки сертифіката TLS {#tls-certificate-errors} + +Наступна помилка вказує на можливу несумісність сертифікатів. + +```none +# kubectl get pods +Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") +``` + +- Перевірте, що файл `$HOME/.kube/config` містить дійсний сертифікат, та перегенеруйте сертифікат за необхідності. Сертифікати у файлі конфігурації kubeconfig закодовані у форматі base64. Команда `base64 --decode` може бути використана для декодування сертифіката, а `openssl x509 -text -noout` може бути використано для перегляду інформації про сертифікат. + +- Скасуйте змінну середовища `KUBECONFIG` за допомогою: + + ```sh + unset KUBECONFIG + ``` + + Або встановіть його в типове розташування `KUBECONFIG`: + + ```sh + export KUBECONFIG=/etc/kubernetes/admin.conf + ``` + +- Іншим обхідним методом є перезапис наявного `kubeconfig` для користувача "admin": + + ```sh + mv $HOME/.kube $HOME/.kube.bak + mkdir $HOME/.kube + sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config + sudo chown $(id -u):$(id -g) $HOME/.kube/config + ``` + +## Помилка ротації сертифіката клієнта Kubelet {#kubelet-client-cert} + +Стандартно `kubeadm` налаштовує `kubelet` на автоматичну ротацію сертифікатів клієнта за допомогою символічного посилання `/var/lib/kubelet/pki/kubelet-client-current.pem`, вказаного в `/etc/kubernetes/kubelet.conf`. Якщо цей процес ротації завершиться невдачею, ви можете побачити помилки, такі як `x509: certificate has expired or is not yet valid` в журналах `kube-apiserver`. Щоб виправити цю проблему, слід виконати наступні кроки: + +1. Зробіть резервну копію та видаліть файли `/etc/kubernetes/kubelet.conf` та `/var/lib/kubelet/pki/kubelet-client*` з несправного вузла. +2. З робочого вузла контрольної площини кластера, де є `/etc/kubernetes/pki/ca.key`, виконайте `kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf`. `$NODE` повинно бути встановлено на імʼя наявного несправного вузла в кластері. Вручну змініть отриманий `kubelet.conf`, щоб відкоригувати імʼя та endpoint сервера, або передайте `kubeconfig user --config` (він приймає `InitConfiguration`). Якщо в у вашому кластері немає `ca.key`, ви повинні вручну підписати вбудовані сертифікати в `kubelet.conf`. +3. Скопіюйте цей отриманий `kubelet.conf` в `/etc/kubernetes/kubelet.conf` на несправному вузлі. +4. Перезапустіть `kubelet` (`systemctl restart kubelet`) на несправному вузлі та зачекайте, доки `/var/lib/kubelet/pki/kubelet-client-current.pem` буде відновлено. +5. Вручну відредагуйте `kubelet.conf`, щоб вказати на обертані сертифікати клієнта `kubelet`, замінивши `client-certificate-data` та `client-key-data` на: + + ```yaml + client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem + client-key: /var/lib/kubelet/pki/kubelet-client-current.pem + ``` + +6. Перезапустіть `kubelet`. +7. Переконайтеся, що вузол стає `Ready`. + +## Типовий мережевий інтерфейс NIC при використанні Flannel як мережі для Podʼів у Vagrant {#default-nic-when-using-flannel-as-the-pod-network-in-vagrant} + +Наступна помилка може свідчити про те, що щось пішло не так у мережі Podʼів: + +```sh +Error from server (NotFound): the server could not find the requested resource +``` + +- Якщо ви використовуєте Flannel як мережу для Podʼів у Vagrant, тоді вам доведеться вказати типове імʼя інтерфейсу для Flannel. + + Зазвичай Vagrant призначає два інтерфейси всім віртуальним машинам. Перший, для якого всі хости мають IP-адресу `10.0.2.15`, призначено для зовнішнього трафіку, який проходить через NAT. + + Це може призвести до проблем із Flannel, яка стандартно він обирає перший інтерфейс на хості. Це призводить до того, що всі хости вважають, що у них однакова публічна IP-адреса. Щоб цього уникнути, передайте прапорець `--iface eth1` для Flannel, щоб обрати другий інтерфейс. + +## Непублічні IP-адреси для контейнерів {#non-public-ip-used-for-containers} + +У деяких ситуаціях команди `kubectl logs` та `kubectl run` можуть повертати помилки на функціональному кластері: + +```console +Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc65b868-glc5m/mysql: dial tcp 10.19.0.41:10250: getsockopt: no route to host +``` + +- Це може бути викликано використанням Kubernetes IP-адреси, яка не може взаємодіяти з іншими IP-адресами на одній підмережі, можливо, через політику провайдера машин. +- DigitalOcean призначає публічний IP для `eth0`, а також приватний IP для внутрішнього використання як анкера для їхньої функції змінного IP. Однак, `kubelet` вибере останній як `InternalIP` вузла замість першого. + + Використовуйте `ip addr show` для перевірки цього сценарію, а не `ifconfig`, оскільки `ifconfig` не показує обрану адресу IP для аліаса. Альтернативно, API-точка, специфічна для DigitalOcean, дозволяє запитувати анкер IP-адресу з машини: + + ```sh + curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address + ``` + + Обхідним рішенням є повідомлення `kubelet`, яку IP використовувати за допомогою `--node-ip`. Коли використовується DigitalOcean, це може бути публічний IP (призначений `eth0`) або приватний IP (призначений `eth1`), якщо ви хочете використовувати додаткову приватну мережу. Розділ `kubeletExtraArgs` структури kubeadm [`NodeRegistrationOptions`](/docs/reference/config-api/kubeadm-config.v1beta3/#kubeadm-k8s-io-v1beta3-NodeRegistrationOptions) може бути використаний для цього. + + Потім перезапустіть `kubelet`: + + ```sh + systemctl daemon-reload + systemctl restart kubelet + ``` + +## Podʼи `coredns` перебувають у стані `CrashLoopBackOff` або `Error` {#coredns-pods-have-crashloopbackoff-or-error-state} + +Якщо у вас є вузли, які працюють із SELinux та старішою версією Docker, ви можете стикнутися зі сценарієм, де Podʼи `coredns` не запускаються. Щоб вирішити це, ви можете спробувати один з наступних варіантів: + +- Оновіться до [новішої версії Docker](/docs/setup/production-environment/container-runtimes/#docker). + +- [Вимкніть SELinux](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-enabling_and_disabling_selinux-disabling_selinux). + +- Змініть розгортання `coredns`, встановивши `allowPrivilegeEscalation` в `true`: + +```bash +kubectl -n kube-system get deployment coredns -o yaml | \ + sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \ + kubectl apply -f - +``` + +Іншою причиною того, що CoreDNS має `CrashLoopBackOff`, є те, що Pod CoreDNS, розгорнутий в Kubernetes, виявляє цикл. [Існують різні обхідні варіанти](https://github.com/coredns/coredns/tree/master/plugin/loop#troubleshooting-loops-in-kubernetes-clusters), щоб уникнути спроб перезапуску Podʼу CoreDNS кожного разу, коли CoreDNS виявляє цикл та виходить. + +{{< warning >}} +Вимкнення SELinux або встановлення `allowPrivilegeEscalation` в `true` може піддавати ризику безпеку вашого кластера. +{{< /warning >}} + +## Podʼі etcd постійно перезапускаються {#etcd-pods-restart-contantly} + +Якщо ви стикаєтеся з такою помилкою: + +``` +rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "process_linux.go:110: decoding init error from pipe caused \"read parent: connection reset by peer\"" +``` + +Ця проблема виникає, якщо ви використовуєте CentOS 7 з Docker 1.13.1.84. Ця версія Docker може завадити kubelet виконуватися в контейнері etcd. + +Для усунення цієї проблеми виберіть один з наступних варіантів: + +- Поверніться до попередньої версії Docker, наприклад, 1.13.1-75 + + ```bash + yum downgrade docker-1.13.1-75.git8633870.el7.centos.x86_64 docker-client-1.13.1-75.git8633870.el7.centos.x86_64 docker-common-1.13.1-75.git8633870.el7.centos.x86_64 + ``` + +- Встановіть одну з новіших рекомендованих версій, наприклад 18.06: + + ```bash + sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo + yum install docker-ce-18.06.1.ce-3.el7.x86_64 + ``` + +## Неможливо передати розділений комою список значень аргументів під прапорцем `--component-extra-args` {#not-possible-to-pass-comma-separated-list-of-values-to-arguments-inside-a-component-extra-args-flag} + +Прапорці `kubeadm init`, такі як `--component-extra-args`, дозволяють передавати власні аргументи компоненту панелі управління, наприклад, kube-apiserver. Однак цей механізм обмежений через тип, який використовується для розбору значень (`mapStringString`). + +Якщо ви вирішите передати аргумент, який підтримує кілька значень, розділених комами, такий як `--apiserver-extra-args "enable-admission-plugins=LimitRanger,NamespaceExists"`, цей прапорець видасть помилку `flag: malformed pair, expect string=string`. Це відбувається через те, що список аргументів для `--apiserver-extra-args` очікує пари `key=value`, і в цьому випадку `NamespacesExists` розглядається як ключ, якому не вистачає значення. + +У іншому випадку ви можете спробувати розділити пари `key=value` так: `--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`, але це призведе до того, що ключ `enable-admission-plugins` матиме лише значення `NamespaceExists`. + +Відомий обхід цього — використання [файлу конфігурації](/docs/reference/config-api/kubeadm-config.v1beta3/) kubeadm. + +## kube-proxy плануєтья до того, як вузол ініціалізовано cloud-controller-manager {#kube-proxy-scheduled-before-node-is-initialized-by-cloud-controller-manager} + +У сценаріях хмарних провайдерів kube-proxy може виявитися запланованим на нових робочих вузлах до того, як cloud-controller-manager ініціалізує адреси вузла. Це призводить до того, що kube-proxy не може належним чином отримати IP-адресу вузла, і це має негативний вплив на функцію проксі, що керує балансуванням навантаження. + +У kube-proxy Pods можна побачити наступну помилку: + +``` +server.go:610] Failed to retrieve node IP: host IP unknown; known addresses: [] +proxier.go:340] invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP +``` + +Відомий варіант рішення — виправлення DaemonSet kube-proxy, щоб дозволити його планування на вузлах панелі управління незалежно від їхніх умов, утримуючи його подальше від інших вузлів, доки їхні початкові умови зберігаються: + +```bash +kubectl -n kube-system patch ds kube-proxy -p='{ + "spec": { + "template": { + "spec": { + "tolerations": [ + { + "key": "CriticalAddonsOnly", + "operator": "Exists" + }, + { + "effect": "NoSchedule", + "key": "node-role.kubernetes.io/control-plane" + } + ] + } + } + } +}' +``` + +Тікет, що відстежує цю проблему, розташовано [тут](https://github.com/kubernetes/kubeadm/issues/1027). + +## `/usr` монтується тільки для читання на вузлах {#usr-mounted-read-only} + +У дистрибутивах Linux, таких як Fedora CoreOS або Flatcar Container Linux, тека `/usr` монтується як файлова система тільки для читання. Для [підтримки flex-volume](https://github.com/kubernetes/community/blob/ab55d85/contributors/devel/sig-storage/flexvolume.md) компоненти Kubernetes, такі як kubelet і kube-controller-manager, використовують типовий шлях `/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`, проте тека flex-volume _має бути доступною для запису_, щоб ця функція працювала. + +{{< note >}} +У випуску Kubernetes v1.23 функцію FlexVolume було визнано застарілою. +{{< /note >}} + +Для усунення цієї проблеми ви можете налаштувати теку flex-volume, використовуючи [файл конфігурації](/docs/reference/config-api/kubeadm-config.v1beta3/) kubeadm. + +На основному вузлі панелі управління (створеному за допомогою `kubeadm init`) передайте наступний файл, використовуючи параметр `--config`: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: InitConfiguration +nodeRegistration: + kubeletExtraArgs: + volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" +--- +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +controllerManager: + extraArgs: + flex-volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" +``` + +При долученні вузлів: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: JoinConfiguration +nodeRegistration: + kubeletExtraArgs: + volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" +``` + +Альтернативно ви можете змінити файл `/etc/fstab`, щоб зробити монтування `/usr` доступним для запису, проте будьте обізнані, що це змінює принцип дизайну дистрибутиву Linux. + +## `kubeadm upgrade plan` виводить повідомлення про помилку `context deadline exceeded` {#kubeadm-upgrade-plan-prints-out-context-deadline-exceeded-error-message} + +Це повідомлення про помилку виводиться при оновленні кластера Kubernetes за допомогою `kubeadm` у випадку використання зовнішнього etcd. Це не критична помилка і виникає через те, що старі версії `kubeadm` виконують перевірку версії зовнішнього кластера etcd. Ви можете продовжити з `kubeadm upgrade apply ...`. + +Цю проблему виправлено у версії 1.19. + +## `kubeadm reset` відмонтовує `/var/lib/kubelet` {#kubeadm-reset-unmounts-var-lib-kubelet} + +Якщо `/var/lib/kubelet` має точку монтування, виконання `kubeadm reset` фактично відмонтує його. + +Для уникнення цієї проблеми повторно замонтуйте каталог `/var/lib/kubelet` після виконання операції `kubeadm reset`. + +Це вдосконалення було введено в kubeadm 1.15. Проблема виправлена в 1.20. + +## Неможливо безпечно використовувати metrics-server в кластері kubeadm {#cannot-use-metrics-server-securely-in-a-kubeadm-cluster} + +У кластері kubeadm [metrics-server](https://github.com/kubernetes-sigs/metrics-server) може бути використаний в небезпечний спосіб, передаючи йому параметр `--kubelet-insecure-tls`. Це не рекомендується для промислових кластерів. + +Якщо ви хочете використовувати TLS між metrics-server та kubelet, виникає проблема, оскільки kubeadm розгортає самопідписний службовий сертифікат для kubelet. Це може призвести до наступних помилок з боку metrics-server: + +``` +x509: certificate signed by unknown authority +x509: certificate is valid for IP-foo not IP-bar +``` + +Дивіться [Увімкнення підписаних службових сертифікатів kubelet](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#kubelet-serving-certs), щоб зрозуміти, як налаштувати kubelet в кластері kubeadm для отримання належно підписаних службових сертифікатів. + +Також перегляньте [Як запустити metrics-server безпечно](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md#how-to-run-metrics-server-securely). + +## Оновлення не вдається через незмінність хешу etcd {#upgrade-fails-due-to-etcd-hash-not-changing} + +Це стосується лише оновлення вузла панелі управління за допомогою бінарного файлу kubeadm v1.28.3 або пізніше, при умові, що вузол в цей час керується версіями kubeadm v1.28.0, v1.28.1 або v1.28.2. + +Ось повідомлення про помилку, яке може виникнути: + +``` +[upgrade/etcd] Failed to upgrade etcd: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition +[upgrade/etcd] Waiting for previous etcd to become available +I0907 10:10:09.109104 3704 etcd.go:588] [etcd] attempting to see if all cluster endpoints ([https://172.17.0.6:2379/ https://172.17.0.4:2379/ https://172.17.0.3:2379/]) are available 1/10 +[upgrade/etcd] Etcd was rolled back and is now available +static Pod hash for component etcd on Node kinder-upgrade-control-plane-1 did not change after 5m0s: timed out waiting for the condition +couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced +k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.rollbackOldManifests + cmd/kubeadm/app/phases/upgrade/staticpods.go:525 +k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.upgradeComponent + cmd/kubeadm/app/phases/upgrade/staticpods.go:254 +k8s.io/kubernetes/cmd/kubeadm/app/phases/upgrade.performEtcdStaticPodUpgrade + cmd/kubeadm/app/phases/upgrade/staticpods.go:338 +... +``` + +Причина цієї помилки полягає в тому, що пошкоджені версії генерують файл маніфесту etcd із небажаними стандартними в PodSpec. Це призводить до різниці в порівнянні маніфестів, і kubeadm буде очікувати зміни хешу в Pod, але kubelet ніколи не оновить хеш. + +Є два способи обійти цю проблему, якщо ви бачите її у своєму кластері: + +- Оновлення etcd може бути пропущено між пошкодженими версіями та v1.28.3 (або пізніше) за допомогою: + + ```shell + kubeadm upgrade {apply|node} [version] --etcd-upgrade=false + ``` + + Це не рекомендується у випадку, якщо пізніше патч-версії v1.28 вводять нову версію etcd. + +- Перед оновленням виправте маніфест для статичного Pod etcd, щоб видалити стандартні проблемні атрибути: + + ```patch + diff --git a/etc/kubernetes/manifests/etcd_defaults.yaml b/etc/kubernetes/manifests/etcd_origin.yaml + index d807ccbe0aa..46b35f00e15 100644 + --- a/etc/kubernetes/manifests/etcd_defaults.yaml + +++ b/etc/kubernetes/manifests/etcd_origin.yaml + @@ -43,7 +43,6 @@ spec: + scheme: HTTP + initialDelaySeconds: 10 + periodSeconds: 10 + - successThreshold: 1 + timeoutSeconds: 15 + name: etcd + resources: + @@ -59,26 +58,18 @@ spec: + scheme: HTTP + initialDelaySeconds: 10 + periodSeconds: 10 + - successThreshold: 1 + timeoutSeconds: 15 + - terminationMessagePath: /dev/termination-log + - terminationMessagePolicy: File + volumeMounts: + - mountPath: /var/lib/etcd + name: etcd-data + - mountPath: /etc/kubernetes/pki/etcd + name: etcd-certs + - dnsPolicy: ClusterFirst + - enableServiceLinks: true + hostNetwork: true + priority: 2000001000 + priorityClassName: system-node-critical + - restartPolicy: Always + - schedulerName: default-scheduler + securityContext: + seccompProfile: + type: RuntimeDefault + - terminationGracePeriodSeconds: 30 + volumes: + - hostPath: + path: /etc/kubernetes/pki/etcd + ``` + +Більше інформації можна знайти в [тікеті](https://github.com/kubernetes/kubeadm/issues/2927) для цієї помилки. diff --git a/content/uk/docs/setup/production-environment/turnkey-solutions.md b/content/uk/docs/setup/production-environment/turnkey-solutions.md new file mode 100644 index 0000000000000..6dafa08963d3b --- /dev/null +++ b/content/uk/docs/setup/production-environment/turnkey-solutions.md @@ -0,0 +1,13 @@ +--- +title: Хмарні рішення під ключ +content_type: concept +weight: 40 +--- + + + +Ця сторінка надає список постачальників сертифікованих рішень Kubernetes. З кожної сторінки постачальника ви можете дізнатися, як встановити та налаштувати готові до експлуатації кластери. + + + +{{< cncf-landscape helpers=true category="platform--certified-kubernetes-hosted" >}} diff --git a/content/uk/docs/setup/release/_index.md b/content/uk/docs/setup/release/_index.md deleted file mode 100644 index 5fed3d9c90ebf..0000000000000 --- a/content/uk/docs/setup/release/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -#title: "Release notes and version skew" -title: "Зміни в релізах нових версій" -weight: 10 ---- diff --git a/content/uk/docs/tasks/_index.md b/content/uk/docs/tasks/_index.md new file mode 100644 index 0000000000000..40f068907e2ae --- /dev/null +++ b/content/uk/docs/tasks/_index.md @@ -0,0 +1,14 @@ +--- +title: Завдання +main_menu: true +weight: 50 +content_type: concept +--- + + + +Цей розділ документації Kubernetes містить сторінки, які +показують, як виконувати окремі завдання. Сторінка завдання показує, як виконати конкретну дію, зазвичай надаючи коротку послідовність кроків. + +Якщо ви хочете написати сторінку завдання, див. +[Створення запиту на злиття для документації](/docs/contribute/new-content/open-a-pr/). diff --git a/content/uk/docs/tasks/access-application-cluster/_index.md b/content/uk/docs/tasks/access-application-cluster/_index.md new file mode 100644 index 0000000000000..a2acdce59a506 --- /dev/null +++ b/content/uk/docs/tasks/access-application-cluster/_index.md @@ -0,0 +1,5 @@ +--- +title: "Доступ до застосунків у кластері" +description: Налаштування балансування навантаження, перенаправлення портів або налаштування фаєрволу або DNS-конфігурацій для доступу до застосунків у кластері. +weight: 100 +--- diff --git a/content/uk/docs/tasks/administer-cluster/_index.md b/content/uk/docs/tasks/administer-cluster/_index.md new file mode 100644 index 0000000000000..401089a9295d5 --- /dev/null +++ b/content/uk/docs/tasks/administer-cluster/_index.md @@ -0,0 +1,5 @@ +--- +title: "Адміністрування кластера" +description: "Дізнайтеся про загальні завдання адміністрування кластера." +weight: 20 +--- \ No newline at end of file diff --git a/content/uk/docs/tasks/administer-cluster/access-cluster-api.md b/content/uk/docs/tasks/administer-cluster/access-cluster-api.md new file mode 100644 index 0000000000000..47ef2c184bc4a --- /dev/null +++ b/content/uk/docs/tasks/administer-cluster/access-cluster-api.md @@ -0,0 +1,333 @@ +--- +title: Доступ до кластера через API Kubernetes +content_type: task +weight: 60 +--- + + + +Ця сторінка описує, як отримати доступ до кластера через API Kubernetes. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +## Доступ до API Kubernetes {#accessing-the-kubernetes-api} + +### Перший доступ за допомогою kubectl {#accessing-for-the-first-time-using-kubectl} + +При першому доступі до API Kubernetes використовуйте інструмент командного рядка Kubernetes, `kubectl`. + +Для отримання доступу до кластера вам потрібно знати його розташування та мати облікові дані для входу. Зазвичай вони встановлюються автоматично, коли ви користуєтесь настановами зі сторінки [Початок роботи](/docs/setup/), або ж ви вже маєте розгорнутий кластер з налаштованим доступом. + +Перевірте місце знаходження та облікові дані, про які знає kubectl, за допомогою цієї команди: + +```shell +kubectl config view +``` + +Багато [прикладів](https://github.com/kubernetes/examples/tree/master/) містять введення в користування `kubectl`. Повну документацію ви можете знайти в [довідці kubectl](/docs/reference/kubectl/). + +### Прямий доступ до REST API {#direct-accessing-the-rest-api} + +kubectl використовується для знаходження та автентифікації на сервері API. Якщо ви хочете дістатись REST API за допомогою інструментів на кшталт `curl` або `wget`, чи вебоглядача, існує кілька способів якими ви можете знайти та автентифікуватись на сервері API. + +1. Запустіть kubectl у режимі проксі (рекомендовано). Цей метод рекомендується, оскільки він використовує збережене розташування сервера API та перевіряє відповідність сервера API за допомогою самопідписного сертифіката. За допомогою цього методу неможлива атака man-in-the-middle (MITM). +2. Крім того, ви можете вказати знаходження та облікові дані безпосередньо http-клієнту. Це працює з клієнтським кодом, який плутають проксі. Щоб захиститися від атак man in the middle, вам потрібно буде імпортувати кореневий сертифікат у свій вебоглядач. + +Використання клієнтських бібліотек Go або Python забезпечує доступ до kubectl у режимі проксі. + +### Використання kubectl proxy {#using-kubectl-proxy} + +Наступна команда запускає kubectl у режимі, де він діє як зворотний проксі. Він виконує пошук сервера API та автентифікацію. + +```shell +kubectl proxy --port=8080 & +``` + +Дивіться [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy) для отримання додаткової інформації. + +Потім ви можете дослідити API за допомогою curl, wget або вебоглядача, наприклад: + +```shell +curl http://localhost:8080/api/ +``` + +Вивід має бути схожий на цей: + +```json +{ + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +#### Без використання kubectl proxy {#without-kubectl-proxy} + +Можна уникнути використання kubectl proxy, передаючи токен автентифікації безпосередньо на сервер API, наприклад: + +Використовуючи підхід `grep/cut`: + +```shell +# Перевірте всі можливі кластери, оскільки ваш .KUBECONFIG може мати кілька контекстів: +kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}' + +# Виберіть назву кластера, з яким ви хочете взаємодіяти, з виводу вище: +export CLUSTER_NAME="some_server_name" + +# Вкажіть сервер API, посилаючись на імʼя кластера +APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}") + +# Створіть секрет для зберігання токена для облікового запису служби +kubectl apply -f - </dev/null; do + echo "waiting for token..." >&2 + sleep 1 +done + +# Отримайте значення токена +TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode) + +# Дослідіть API скориставшись TOKEN +curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +``` + +Вивід має бути схожий на цей: + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +У вищенаведеному прикладі використовується прапорець `--insecure`. Це залишає систему вразливою до атак типу MITM (Man-In-The-Middle). Коли kubectl отримує доступ до кластера, він використовує збережений кореневий сертифікат та сертифікати клієнта для доступу до сервера. (Ці дані встановлені у каталозі `~/.kube`). Оскільки сертифікати кластера зазвичай самопідписні, може знадобитися спеціальна конфігурація, щоб ваш HTTP-клієнт використовував кореневий сертифікат. + +На деяких кластерах сервер API може не вимагати автентифікації; він може обслуговувати локальний хост або бути захищений фаєрволом. Не існує стандарту для цього. Документ [Керування доступом до API Kubernetes](/docs/concepts/security/controlling-access) описує, як ви можете налаштувати це, як адміністратор кластера. + +### Програмний доступ до API {#programmatic-access-to-the-api} + +Kubernetes офіційно підтримує клієнтські бібліотеки для [Go](#go-client), [Python](#python-client), [Java](#java-client), [dotnet](#dotnet-client), [JavaScript](#javascript-client) та [Haskell](#haskell-client). Існують інші клієнтські бібліотеки, які надаються та підтримуються їхніми авторами, а не командою Kubernetes. Дивіться [бібліотеки клієнтів](/docs/reference/using-api/client-libraries/) для доступу до API з інших мов програмування та їхнього методу автентифікації. + +#### Go-клієнт {#go-client} + +* Щоб отримати бібліотеку, виконайте наступну команду: `go get k8s.io/client-go@kubernetes-<номер-версії-kubernetes>`. Дивіться [https://github.com/kubernetes/client-go/releases](https://github.com/kubernetes/client-go/releases), щоб переглянути підтримувані версії. +* Напишіть застосунок поверх клієнтів client-go. + +{{< note >}} + +`client-go` визначає власні обʼєкти API, тому у разі необхідності імпортуйте визначення API з client-go, а не з основного сховища. Наприклад, `import "k8s.io/client-go/kubernetes"` є правильним. + +{{< /note >}} + +Go-клієнт може використовувати той самий [файл kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), +як і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей [приклад](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go): + +```golang +package main + +import ( + "context" + "fmt" + "k8s.io/apimachinery/pkg/apis/meta/v1" + "k8s.io/client-go/kubernetes" + "k8s.io/client-go/tools/clientcmd" +) + +func main() { + // використовуємо поточний контекст з kubeconfig + // path-to-kubeconfig -- наприклад, /root/.kube/config + config, _ := clientcmd.BuildConfigFromFlags("", "") + // створює clientset + clientset, _ := kubernetes.NewForConfig(config) + // доступ API до списку Podʼів + pods, _ := clientset.CoreV1().Pods("").List(context.TODO(), v1.ListOptions{}) + fmt.Printf("There are %d pods in the cluster\n", len(pods.Items)) +} +``` + +Якщо застосунок розгорнуто як Pod у кластері, дивіться [Доступ до API зсередини Pod](/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod). + +#### Python-клієнт {#python-client} + +Щоб використовувати [Python-клієнт](https://github.com/kubernetes-client/python), виконайте наступну команду: `pip install kubernetes`. Дивіться [сторінку бібліотеки Python-клієнта](https://github.com/kubernetes-client/python) для отримання додаткових варіантів встановлення. + +Python-клієнт може використовувати той самий [файл kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), як і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей [приклад](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py): + +```python +from kubernetes import client, config + +config.load_kube_config() + +v1=client.CoreV1Api() +print("Listing pods with their IPs:") +ret = v1.list_pod_for_all_namespaces(watch=False) +for i in ret.items: + print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name)) +``` + +#### Java-клієнт {#java-client} + +Для встановлення [Java-клієнта](https://github.com/kubernetes-client/java) виконайте наступну команду: + +```shell +# Зколнуйте код білліотеки java +git clone --recursive https://github.com/kubernetes-client/java + +# Встановлення артефактів проєкту, POM й так даіл: +cd java +mvn install +``` + +Дивіться [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases), щоб переглянути підтримувані версії. + +Java-клієнт може використовувати той самий [файл kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), що і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей [приклад](https://github.com/kubernetes-client/java/blob/master/examples/examples-release-15/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java): + +```java +package io.kubernetes.client.examples; + +import io.kubernetes.client.ApiClient; +import io.kubernetes.client.ApiException; +import io.kubernetes.client.Configuration; +import io.kubernetes.client.apis.CoreV1Api; +import io.kubernetes.client.models.V1Pod; +import io.kubernetes.client.models.V1PodList; +import io.kubernetes.client.util.ClientBuilder; +import io.kubernetes.client.util.KubeConfig; +import java.io.FileReader; +import java.io.IOException; + +/** + * Простий приклад використання Java API з застосунку поза кластером Kubernetes. + * + * Найпростіший спосіб запуску цього: mvn exec:java + * -Dexec.mainClass="io.kubernetes.client.examples.KubeConfigFileClientExample" + * + */ +public class KubeConfigFileClientExample { + public static void main(String[] args) throws IOException, ApiException { + + // шлях до файлуу KubeConfig + String kubeConfigPath = "~/.kube/config"; + + // завантаження конфігурації ззовні кластера, kubeconfig із файлової системи + ApiClient client = + ClientBuilder.kubeconfig(KubeConfig.loadKubeConfig(new FileReader(kubeConfigPath))).build(); + + // встановлення глобального api-client на того, що працює в межах кластера, як описано вище + Configuration.setDefaultApiClient(client); + + // the CoreV1Api завантажує api-client з глобальної конфігурації. + CoreV1Api api = new CoreV1Api(); + + // виклик клієнта CoreV1Api + V1PodList list = api.listPodForAllNamespaces(null, null, null, null, null, null, null, null, null); + System.out.println("Listing all pods: "); + for (V1Pod item : list.getItems()) { + System.out.println(item.getMetadata().getName()); + } + } +} +``` + +#### dotnet-клієнт {#dotnet-client} + +Щоб використовувати [dotnet-клієнт](https://github.com/kubernetes-client/csharp), виконайте наступну команду: `dotnet add package KubernetesClient --version 1.6.1`. Дивіться [сторінку бібліотеки dotnet-клієнта](https://github.com/kubernetes-client/csharp) для отримання додаткових варіантів встановлення. Дивіться [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases), щоб переглянути підтримувані версії. + +Dotnet-клієнт може використовувати той самий [файл kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), що і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей [приклад](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs): + +```csharp +using System; +using k8s; + +namespace simple +{ + internal class PodList + { + private static void Main(string[] args) + { + var config = KubernetesClientConfiguration.BuildDefaultConfig(); + IKubernetes client = new Kubernetes(config); + Console.WriteLine("Starting Request!"); + + var list = client.ListNamespacedPod("default"); + foreach (var item in list.Items) + { + Console.WriteLine(item.Metadata.Name); + } + if (list.Items.Count == 0) + { + Console.WriteLine("Empty!"); + } + } + } +} +``` + +#### JavaScript-клієнт {#javascript-client} + +Щоб встановити [JavaScript-клієнт](https://github.com/kubernetes-client/javascript), виконайте наступну команду: `npm install @kubernetes/client-node`. Дивіться [сторінку бібліотеки JavaScript-клієнта](https://github.com/kubernetes-client/javascript) для отримання додаткових варіантів встановлення. Дивіться [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases), щоб переглянути підтримувані версії. + +JavaScript-клієнт може використовувати той самий [файл kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), що і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей [приклад](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js): + +```javascript +const k8s = require('@kubernetes/client-node'); + +const kc = new k8s.KubeConfig(); +kc.loadFromDefault(); + +const k8sApi = kc.makeApiClient(k8s.CoreV1Api); + +k8sApi.listNamespacedPod('default').then((res) => { + console.log(res.body); +}); +``` + +#### Haskell-клієнт {#haskell-client} + +Дивіться [https://github.com/kubernetes-client/haskell/releases](https://github.com/kubernetes-client/haskell/releases), щоб переглянути підтримувані версії. + +[Haskell-клієнт](https://github.com/kubernetes-client/haskell) може використовувати той самий [файл kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/), що і kubectl CLI, для пошуку та автентифікації на сервері API. Дивіться цей [приклад](https://github.com/kubernetes-client/haskell/blob/master/kubernetes-client/example/App.hs): + +```haskell +exampleWithKubeConfig :: IO () +exampleWithKubeConfig = do + oidcCache <- atomically $ newTVar $ Map.fromList [] + (mgr, kcfg) <- mkKubeClientConfig oidcCache $ KubeConfigFile "/path/to/kubeconfig" + dispatchMime + mgr + kcfg + (CoreV1.listPodForAllNamespaces (Accept MimeJSON)) + >>= print +``` + +## {{% heading "whatsnext" %}} + +* [Доступ до API Kubernetes із Pod](/docs/tasks/run-application/access-api-from-pod/) diff --git a/content/uk/docs/tasks/administer-cluster/certificates.md b/content/uk/docs/tasks/administer-cluster/certificates.md new file mode 100644 index 0000000000000..92264143411c9 --- /dev/null +++ b/content/uk/docs/tasks/administer-cluster/certificates.md @@ -0,0 +1,277 @@ +--- +title: "Генерація сертифікатів вручну" +content_type: task +weight: 30 +--- + + + +При використанні автентифікації сертифіката клієнта ви можете генерувати сертифікати вручну за допомогою [`easyrsa`](https://github.com/OpenVPN/easy-rsa), [`openssl`](https://github.com/openssl/openssl) або [`cfssl`](https://github.com/cloudflare/cfssl). + + + +### easyrsa + +З **easyrsa** ви можете вручну генерувати сертифікати для вашого кластера. + +1. Завантажте, розпакуйте та ініціалізуйте патчену версію `easyrsa3`. + + ```shell + curl -LO https://dl.k8s.io/easy-rsa/easy-rsa.tar.gz + tar xzf easy-rsa.tar.gz + cd easy-rsa-master/easyrsa3 + ./easyrsa init-pki + ``` + +1. Згенеруйте новий центр сертифікації (CA). `--batch` встановлює автоматичний режим; `--req-cn` вказує загальну назву (CN, Common Name) для нового кореневого сертифіката CA. + + ```shell + ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass + ``` + +1. Згенеруйте сертифікат та ключ сервера. + + Аргумент `--subject-alt-name` встановлює можливі IP-адреси та імена DNS, за якими буде доступний сервер API. `MASTER_CLUSTER_IP` зазвичай є першою IP-адресою з діапазону служб CIDR, який вказаний як аргумент `--service-cluster-ip-range` для сервера API та компонента керування контролером. Аргумент `--days` використовується для встановлення кількості днів чинності сертифіката. У прикладі нижче також припускається, що ви використовуєте `cluster.local` як типове імʼя домену DNS. + + ```shell + ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ + "IP:${MASTER_CLUSTER_IP},"\ + "DNS:kubernetes,"\ + "DNS:kubernetes.default,"\ + "DNS:kubernetes.default.svc,"\ + "DNS:kubernetes.default.svc.cluster,"\ + "DNS:kubernetes.default.svc.cluster.local" \ + --days=10000 \ + build-server-full server nopass + ``` + +1. Скопіюйте `pki/ca.crt`, `pki/issued/server.crt` та `pki/private/server.key` у вашу теку. + +1. Заповніть та додайте наступні параметри до параметрів запуску сервера API: + + ```shell + --client-ca-file=/yourdirectory/ca.crt + --tls-cert-file=/yourdirectory/server.crt + --tls-private-key-file=/yourdirectory/server.key + ``` + +### openssl + +Ви також можете вручну генерувати сертифікати за допомогою **openssl**. + +1. Згенеруйте 2048-бітний ca.key : + + ```shell + openssl genrsa -out ca.key 2048 + ``` + +2. Згенеруйте ca.crt для ca.key (використовуйте `-days` для встановлення кількості днів чинності сертифіката): + + ```shell + openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt + ``` + +3. Згенеруйте 2048-бітний server.key: + + ```shell + openssl genrsa -out server.key 2048 + ``` + +4. Створіть конфігураційний файл для генерування Certificate Signing Request (CSR). + + Переконайтеся, що ви встановили власні значення для параметрів в кутових дужках, наприклад ``, замінивши їх на власні значення перед збереженням файлу, наприклад з назвою `csr.conf`. Зауважте, що значення `` є IP-адресою API-сервера, як про це йдеться в попередньому розділі. Приклад конфігураційного файлу нижче використовує `cluster.local` як типове імʼя домену DNS. + + ```ini + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn + + [ dn ] + C = + ST = + L = + O = + OU = + CN = + + [ req_ext ] + subjectAltName = @alt_names + + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = + IP.2 = + + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names + ``` + +5. Згенеруйте Certificate Signing Request (CSR) на основі конфігураційного файлу: + + ```shell + openssl req -new -key server.key -out server.csr -config csr.conf + ``` + +6. Згенеруйте сертифікат сервера, використовуючи ca.key, ca.crt та server.csr: + + ```shell + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf -sha256 + ``` + +7. Перегляньте запит на підписання сертифіката: + + ```shell + openssl req -noout -text -in ./server.csr + ``` + +8. Перегляньте сертифікат: + + ```shell + openssl x509 -noout -text -in ./server.crt + ``` + +Нарешті, додайте ті ж самі параметри до параметрів запуску сервера API. + +### cfssl + +Ви також можете вручну генерувати сертифікати за допомогою **cfssl**. + +1. Завантажте, розпакуйте та підготуйте інструменти як показано нижче + + ```shell + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl + chmod +x cfssl + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson + chmod +x cfssljson + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo + chmod +x cfssl-certinfo + ``` + +2. Створіть теку для зберігання артифактів та ініціалізації cfssl: + + ```shell + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json + ``` + +3. Створіть конфігураційний файл JSON для генерації файлу CA, наприклад, `ca-config.json`: + + ```json + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } + ``` + +4. Створіть конфігураційний файл JSON для генерації Certificate Signing Request (CSR), наприклад, `ca-csr.json`. Переконайтеся, що ви встановили власні значення для параметрів в кутових дужках. + + ```json + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } + ``` + +5. Згенеруйте сертифікат CA (`ca.pem`) та ключ CA (`ca-key.pem`): + + ```shell + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca + ``` + +6. Створіть конфігураційний файл JSON для генерації ключів та сертифікатів для сервера API, наприклад, `server-csr.json`. Переконайтеся, що ви встановили власні значення для параметрів в кутових дужках. `` є IP-адресою кластера, як про це йдеться в попередньому розділі. В прикладі нижче також припускається, що ви використовуєте `cluster.local` як типове імʼя домену DNS. + + ```json + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } + ``` + +7. Згенеруйте ключ та сертифікат для сервера API, які типово зберігаються у файлах `server-key.pem` та `server.pem`, відповідно: + + ```shell + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ + --config=ca-config.json -profile=kubernetes \ + server-csr.json | ../cfssljson -bare server + ``` + +## Розповсюдження самопідписних сертифікатів CA {#distribute-self-signed-ca-certificates} + +Клієнтський вузол може не визнавати самопідписні сертифікати CA. Для оточення, що не є операційним, або для операційного оточення, що працює за корпоративним фаєрволом, ви можете розповсюджувати самопідписні сертифікати CA на всіх клієнтів та оновлювати перелік довірених сертифікатів. + +На кожному клієнті виконайте наступні кроки: + +```shell +sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt +sudo update-ca-certificates +``` + +```none +Updating certificates in /etc/ssl/certs... +1 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d.... +done. +``` + +## API сертифікатів {#certificates-api} + +Ви можете використовувати `certificates.k8s.io` API для надання сертифікатів x509 для використання для автентифікації, як про це йдеться на сторінці [Керування TLS в кластері](/docs/tasks/tls/managing-tls-in-a-cluster/). diff --git a/content/uk/docs/tasks/administer-cluster/kubeadm/_index.md b/content/uk/docs/tasks/administer-cluster/kubeadm/_index.md new file mode 100644 index 0000000000000..1f8813d34125d --- /dev/null +++ b/content/uk/docs/tasks/administer-cluster/kubeadm/_index.md @@ -0,0 +1,4 @@ +--- +title: "Адміністрування з kubeadm" +weight: 10 +--- diff --git a/content/uk/docs/tasks/administer-cluster/manage-resources/_index.md b/content/uk/docs/tasks/administer-cluster/manage-resources/_index.md new file mode 100644 index 0000000000000..428702610c885 --- /dev/null +++ b/content/uk/docs/tasks/administer-cluster/manage-resources/_index.md @@ -0,0 +1,4 @@ +--- +title: "Керування ресурсами памʼяті, CPU та API" +weight: 40 +--- diff --git a/content/uk/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/uk/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md new file mode 100644 index 0000000000000..d9c81853683e3 --- /dev/null +++ b/content/uk/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md @@ -0,0 +1,29 @@ +--- +title: "Міграція з dockershim" +weight: 20 +content_type: task +no_list: true +--- + + + +Цей розділ містить інформацію, яку вам потрібно знати при міграції з dockershim на інші оточення виконання контейнерів. + +Після оголошення про [застарівання dockershim](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) в Kubernetes 1.20, виникли питання, як це вплине на різні робочі навантаження та розгортання самого Kubernetes. Наш [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/) допоможе вам краще зрозуміти проблему. + +Dockershim був видалений з Kubernetes з випуском v1.24. Якщо ви використовуєте Docker Engine через dockershim як своє оточення виконання контейнерів і хочете оновитись до v1.24, рекомендується або мігрувати на інше оточення виконання, або знайти альтернативний спосіб отримання підтримки Docker Engine. Ознайомтеся з розділом [оточення виконання контейнерів](/docs/setup/production-environment/container-runtimes/), щоб дізнатися про ваші варіанти. + +Версія Kubernetes з dockershim (1.23) вийшла з стану підтримки, а v1.24 скоро вийде зі стану підтримки [скоро](/releases/#release-v1-24). Переконайтеся, що [повідомляєте про проблеми](https://github.com/kubernetes/kubernetes/issues) з міграцією, щоб проблеми могли бути вчасно виправлені, і ваш кластер був готовий до видалення dockershim. Після виходу v1.24 зі стану підтримки вам доведеться звертатися до вашого постачальника Kubernetes за підтримкою або оновлювати кілька версій одночасно, якщо є критичні проблеми, які впливають на ваш кластер. + +Ваш кластер може мати більше одного типу вузлів, хоча це не є загальною конфігурацією. + +Ці завдання допоможуть вам здійснити міграцію: + +* [Перевірте, чи вас стосується видалення dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) +* [Міграція вузлів Docker Engine з dockershim на cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) +* [Міграція телеметрії та агентів безпеки з dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/) + +## {{% heading "whatsnext" %}} + +* Ознайомтеся з [оточеннями виконання контейнерів](/docs/setup/production-environment/container-runtimes/), щоб зрозуміти які з варіантів вам доступні. +* Якщо ви знайшли дефект або іншу технічну проблему, повʼязану з відмовою від dockershim, ви можете [повідомити про проблему](https://github.com/kubernetes/kubernetes/issues/new/choose) проєкту Kubernetes. diff --git a/content/uk/docs/tasks/administer-cluster/network-policy-provider/_index.md b/content/uk/docs/tasks/administer-cluster/network-policy-provider/_index.md new file mode 100644 index 0000000000000..6f00a7be918ec --- /dev/null +++ b/content/uk/docs/tasks/administer-cluster/network-policy-provider/_index.md @@ -0,0 +1,4 @@ +--- +title: Встановлення постачальника мережевої політики +weight: 50 +--- diff --git a/content/uk/docs/tasks/configmap-secret/_index.md b/content/uk/docs/tasks/configmap-secret/_index.md new file mode 100644 index 0000000000000..813b86dd8f49b --- /dev/null +++ b/content/uk/docs/tasks/configmap-secret/_index.md @@ -0,0 +1,5 @@ +--- +title: Керування Secrets +weight: 60 +description: Керування конфіденційними налаштуваннями за допомогою Secrets. +--- diff --git a/content/uk/docs/tasks/configure-pod-container/_index.md b/content/uk/docs/tasks/configure-pod-container/_index.md new file mode 100644 index 0000000000000..ad34a4e671ca4 --- /dev/null +++ b/content/uk/docs/tasks/configure-pod-container/_index.md @@ -0,0 +1,6 @@ +--- +title: Налаштування Podʼів та контейнерів +description: Виконайте загальні завдання конфігурації для Pod і контейнерів. +weight: 30 +--- + \ No newline at end of file diff --git a/content/uk/docs/tasks/debug/_index.md b/content/uk/docs/tasks/debug/_index.md new file mode 100644 index 0000000000000..579b7414fcc05 --- /dev/null +++ b/content/uk/docs/tasks/debug/_index.md @@ -0,0 +1,92 @@ +--- +title: Моніторинг, логування та налагодження +description: Налаштуйте моніторинг та логування для розвʼязання проблем кластера або налагодження контейнеризованих застосунків. +weight: 40 +reviewers: +- brendandburns +- davidopp +content_type: concept +no_list: true +card: + name: tasks + weight: 999 + title: Отримання допомоги +--- + + + +Іноді речі йдуть не так. Цей посібник призначений для допомоги у виправленні помилок. Він має два розділи: + +* [Налагодження вашого застосунку](/docs/tasks/debug/debug-application/) — корисно для користувачів, які розгортають код у Kubernetes та цікавляться причиною його непрацездатності. +* [Налагодження вашого кластера](/docs/tasks/debug/debug-cluster/) — корисно для адміністраторів кластерів та людей, чиї кластери Kubernetes не перебувають у найкращому стані. + +Вам також слід перевірити відомі проблеми для [випуску](https://github.com/kubernetes/kubernetes/releases), який ви використовуєте. + + + +## Отримання допомоги {#getting-help} + +Якщо вашу проблему не вдається вирішити жодною з інструкцій вище, існує ряд способів, як отримати допомогу від спільноти Kubernetes. + +### Питання {#questions} + +Документація на цьому сайті структурована таким чином, щоб надавати відповіді на широкий спектр питань. [Концепції](/docs/concepts/) пояснюють архітектуру Kubernetes та роботу кожного компонента, в той час, як [Налаштування](/docs/setup/) надає практичні інструкції для початку роботи. [Завдання](/docs/tasks/) показують, як виконати широке коло завдань, а [Посібники](/docs/tutorials/) — це більш комплексні огляди сценаріїв реального життя, специфічних для галузей або розробки з початку до кінця. Розділ [Довідник](/docs/reference/) надає детальну документацію з [API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) та інтерфейсів командного рядка (CLI), таких як [`kubectl`](/docs/reference/kubectl/). + +## Допоможіть! Моє питання не розглянуто! Мені потрібна допомога зараз! + +### Stack Exchange, Stack Overflow або Server Fault {#stack-exchange} + +Якщо у вас є питання, повʼязане з *розробкою програмного забезпечення* для вашого контейнеризованого застосунку, ви можете задати його на [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes). + +Якщо у вас є питання про Kubernetes, повʼязані з *управлінням кластером* або *конфігурацією*, ви можете задати їх на [Server Fault](https://serverfault.com/questions/tagged/kubernetes). + +Також існують кілька більш конкретних сайтів мережі Stack Exchange, які можуть бути відповідним місцем для питань про Kubernetes в таких областях, як [DevOps](https://devops.stackexchange.com/questions/tagged/kubernetes), [Software Engineering](https://softwareengineering.stackexchange.com/questions/tagged/kubernetes) або [InfoSec](https://security.stackexchange.com/questions/tagged/kubernetes). + +Хтось зі спільноти може вже ставив схоже питання або може допомогти з вашою проблемою. + +Команда Kubernetes також слідкуватиме за [постами з теґом Kubernetes](https://stackoverflow.com/questions/tagged/kubernetes). Якщо немає наявних питань, які можуть допомогти, **будь ласка, переконайтеся, що ваше питання відповідає [правилам Stack Overflow](https://stackoverflow.com/help/on-topic), [Server Fault](https://serverfault.com/help/on-topic) або сайту мережі Stack Exchange, на якому ви його ставите**, і ознайомтеся з інструкцією [як поставити нове питання](https://stackoverflow.com/help/how-to-ask), перед тим як задавати нове! + +### Slack {#slack} + +Багато людей зі спільноти Kubernetes збираються у Kubernetes Slack в каналі `#kubernetes-users`. Slack вимагає реєстрації; ви можете [запросити запрошення](https://slack.kubernetes.io), і реєстрація відкрита для всіх). Запрошуємо приходити та ставити будь-які питання. Після реєстрації ви отримайте доступ до [організації Kubernetes у Slack](https://kubernetes.slack.com) у вебоглядачі або в застосунку Slack. + +Після реєстрації переглядайте список каналів для різних тем. Наприклад, люди, які тільки вчаться Kubernetes, також можуть приєднатися до каналу [`#kubernetes-novice`](https://kubernetes.slack.com/messages/kubernetes-novice). Як ще один приклад, розробникам корисно приєднатися до каналу [`#kubernetes-contributors`](https://kubernetes.slack.com/messages/kubernetes-contributors). + +Також існують багато каналів, специфічних для країн / мов. Запрошуємо приєднатися до цих каналів для локалізованої підтримки та інформації: + +{{< table caption="Країна / канал Slack" >}} + +Країна | Канали +:---------|:------------ +Китай | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users), [`#cn-events`](https://kubernetes.slack.com/messages/cn-events) +Фінляндія | [`#fi-users`](https://kubernetes.slack.com/messages/fi-users) +Франція | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users), [`#fr-events`](https://kubernetes.slack.com/messages/fr-events) +Німеччина | [`#de-users`](https://kubernetes.slack.com/messages/de-users), [`#de-events`](https://kubernetes.slack.com/messages/de-events) +Індія | [`#in-users`](https://kubernetes.slack.com/messages/in-users), [`#in-events`](https://kubernetes.slack.com/messages/in-events) +Італія | [`#it-users`](https://kubernetes.slack.com/messages/it-users), [`#it-events`](https://kubernetes.slack.com/messages/it-events) +Японія | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users), [`#jp-events`](https://kubernetes.slack.com/messages/jp-events) +Корея | [`#kr-users`](https://kubernetes.slack.com/messages/kr-users) +Нідерланди | [`#nl-users`](https://kubernetes.slack.com/messages/nl-users) +Норвегія | [`#norw-users`](https://kubernetes.slack.com/messages/norw-users) +Польща | [`#pl-users`](https://kubernetes.slack.com/messages/pl-users) +Росія | [`#ru-users`](https://kubernetes.slack.com/messages/ru-users) +Іспанія | [`#es-users`](https://kubernetes.slack.com/messages/es-users) +Швеція | [`#se-users`](https://kubernetes.slack.com/messages/se-users) +Туреччина | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users), [`#tr-events`](https://kubernetes.slack.com/messages/tr-events) +{{< /table >}} + +### Форум {#forum} + +Вас раді бачити на офіційному форумі Kubernetes: [discuss.kubernetes.io](https://discuss.kubernetes.io). + +### Помилки та запитання щодо функціонала {#bugs-and-feature-requests} + +Якщо у вас є ознаки помилки або ви хочете подати запит на новий функціонал, будь ласка, скористайтесь [тікетами GitHub](https://github.com/kubernetes/kubernetes/issues). + +Перед тим як створити тікет, будь ласка, перегляньте наявні проблеми, щоб переконатися, чи є вже вирішення для вашої проблеми. + +Якщо ви подаєте звіт про помилку, будь ласка, включіть детальні відомості про те, як відтворити проблему, таку як: + +* Версія Kubernetes: `kubectl version` +* Хмарний провайдер, дистрибутив ОС, конфігурація мережі та версія оточення виконання контейнерів +* Кроки для відтворення проблеми diff --git a/content/uk/docs/tasks/debug/debug-application/_index.md b/content/uk/docs/tasks/debug/debug-application/_index.md new file mode 100644 index 0000000000000..54fc69325031c --- /dev/null +++ b/content/uk/docs/tasks/debug/debug-application/_index.md @@ -0,0 +1,7 @@ +--- +title: Налагодження застосунку +description: Виправлення загальних проблем з контейнеризованими застосунками. +weight: 20 +--- + +Цей розділ містить набір ресурсів для виправлення проблем з контейнеризованими застосунками. Він охоплює такі речі, як загальні проблеми з ресурсами Kubernetes (наприклад, Pods, Services або StatefulSets), поради щодо розуміння повідомлень про припинення роботи контейнера та способи налагодження запущених контейнерів. diff --git a/content/uk/docs/tasks/debug/debug-cluster/_index.md b/content/uk/docs/tasks/debug/debug-cluster/_index.md new file mode 100644 index 0000000000000..01a18d4c4e4d2 --- /dev/null +++ b/content/uk/docs/tasks/debug/debug-cluster/_index.md @@ -0,0 +1,317 @@ +--- +reviewers: +- davidopp +title: Налагодження кластера +description: Виправлення загальних проблем з кластером Kubernetes. +weight: 20 +no_list: true +--- + + + +Цей документ присвячений усуненню неполадок в кластері; ми передбачаємо, що ви вже виключили свій застосунок з переліку причин проблеми, з якою ви стикаєтеся. Дивіться [посібник Налагодження застосунку](/docs/tasks/debug/debug-application/) для порад з перевірки застосунків. Ви також можете звернутися до [загального документа з усунення неполадок](/docs/tasks/debug/) для отримання додаткової інформації. + +Щодо усунення неполадок інструменту {{}}, звертайтеся до [Посібника з усунення неполадок kubectl](/docs/tasks/debug/debug-cluster/troubleshoot-kubectl/). + + + +## Виведення інформації про кластер {#listing-your-cluster} + +Перша річ, яку потрібно дослідити у кластері — це переконатися, що всі ваші вузли зареєстровані правильно. + +Виконайте наступну команду: + +```shell +kubectl get nodes +``` + +Перевірте, що всі вузли, які ви очікуєте бачити, присутні, і що всі вони перебувають у стані `Ready`. + +Щоб отримати детальну інформацію про загальний стан вашого кластера, ви можете виконати: + +```shell +kubectl cluster-info dump +``` + +### Приклад: відлагодження вимкненого/недоступного вузла {#example-debugging-a-down-unreachable-node} + +Іноді при відлагодженні може бути корисно переглянути стан вузла, наприклад, через те, що ви помітили дивну поведінку Podʼа, який працює на вузлі, або щоб дізнатися, чому Pod не може розміститися на вузлі. Так само як і з Podʼами, ви можете використовувати `kubectl describe node` та `kubectl get node -o yaml`, щоб отримати детальну інформацію про вузли. Наприклад, ось що ви побачите, якщо вузол вимкнено (відключено від мережі, або kubelet припинив роботу і не може перезапуститися і т. д.). Зверніть увагу на події, які показують, що вузол не готовий, і також зверніть увагу, що Podʼи більше не працюють (їх буде виселено після пʼяти хвилин стану NotReady). + +```shell +kubectl get nodes +``` + +```none +NAME STATUS ROLES AGE VERSION +kube-worker-1 NotReady 1h v1.23.3 +kubernetes-node-bols Ready 1h v1.23.3 +kubernetes-node-st6x Ready 1h v1.23.3 +kubernetes-node-unaj Ready 1h v1.23.3 +``` + +```shell +kubectl describe node kube-worker-1 +``` + +```none +Name: kube-worker-1 +Roles: +Labels: beta.kubernetes.io/arch=amd64 + beta.kubernetes.io/os=linux + kubernetes.io/arch=amd64 + kubernetes.io/hostname=kube-worker-1 + kubernetes.io/os=linux +Annotations: kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock + node.alpha.kubernetes.io/ttl: 0 + volumes.kubernetes.io/controller-managed-attach-detach: true +CreationTimestamp: Thu, 17 Feb 2022 16:46:30 -0500 +Taints: node.kubernetes.io/unreachable:NoExecute + node.kubernetes.io/unreachable:NoSchedule +Unschedulable: false +Lease: + HolderIdentity: kube-worker-1 + AcquireTime: + RenewTime: Thu, 17 Feb 2022 17:13:09 -0500 +Conditions: + Type Status LastHeartbeatTime LastTransitionTime Reason Message + ---- ------ ----------------- ------------------ ------ ------- + NetworkUnavailable False Thu, 17 Feb 2022 17:09:13 -0500 Thu, 17 Feb 2022 17:09:13 -0500 WeaveIsUp Weave pod has set this + MemoryPressure Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status. + DiskPressure Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status. + PIDPressure Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status. + Ready Unknown Thu, 17 Feb 2022 17:12:40 -0500 Thu, 17 Feb 2022 17:13:52 -0500 NodeStatusUnknown Kubelet stopped posting node status. +Addresses: + InternalIP: 192.168.0.113 + Hostname: kube-worker-1 +Capacity: + cpu: 2 + ephemeral-storage: 15372232Ki + hugepages-2Mi: 0 + memory: 2025188Ki + pods: 110 +Allocatable: + cpu: 2 + ephemeral-storage: 14167048988 + hugepages-2Mi: 0 + memory: 1922788Ki + pods: 110 +System Info: + Machine ID: 9384e2927f544209b5d7b67474bbf92b + System UUID: aa829ca9-73d7-064d-9019-df07404ad448 + Boot ID: 5a295a03-aaca-4340-af20-1327fa5dab5c + Kernel Version: 5.13.0-28-generic + OS Image: Ubuntu 21.10 + Operating System: linux + Architecture: amd64 + Container Runtime Version: containerd://1.5.9 + Kubelet Version: v1.23.3 + Kube-Proxy Version: v1.23.3 +Non-terminated Pods: (4 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits Age + --------- ---- ------------ ---------- --------------- ------------- --- + default nginx-deployment-67d4bdd6f5-cx2nz 500m (25%) 500m (25%) 128Mi (6%) 128Mi (6%) 23m + default nginx-deployment-67d4bdd6f5-w6kd7 500m (25%) 500m (25%) 128Mi (6%) 128Mi (6%) 23m + kube-system kube-proxy-dnxbz 0 (0%) 0 (0%) 0 (0%) 0 (0%) 28m + kube-system weave-net-gjxxp 100m (5%) 0 (0%) 200Mi (10%) 0 (0%) 28m +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + Resource Requests Limits + -------- -------- ------ + cpu 1100m (55%) 1 (50%) + memory 456Mi (24%) 256Mi (13%) + ephemeral-storage 0 (0%) 0 (0%) + hugepages-2Mi 0 (0%) 0 (0%) +Events: +... +``` + +```shell +kubectl get node kube-worker-1 -o yaml +``` + +```yaml +apiVersion: v1 +kind: Node +metadata: + annotations: + kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock + node.alpha.kubernetes.io/ttl: "0" + volumes.kubernetes.io/controller-managed-attach-detach: "true" + creationTimestamp: "2022-02-17T21:46:30Z" + labels: + beta.kubernetes.io/arch: amd64 + beta.kubernetes.io/os: linux + kubernetes.io/arch: amd64 + kubernetes.io/hostname: kube-worker-1 + kubernetes.io/os: linux + name: kube-worker-1 + resourceVersion: "4026" + uid: 98efe7cb-2978-4a0b-842a-1a7bf12c05f8 +spec: {} +status: + addresses: + - address: 192.168.0.113 + type: InternalIP + - address: kube-worker-1 + type: Hostname + allocatable: + cpu: "2" + ephemeral-storage: "14167048988" + hugepages-2Mi: "0" + memory: 1922788Ki + pods: "110" + capacity: + cpu: "2" + ephemeral-storage: 15372232Ki + hugepages-2Mi: "0" + memory: 2025188Ki + pods: "110" + conditions: + - lastHeartbeatTime: "2022-02-17T22:20:32Z" + lastTransitionTime: "2022-02-17T22:20:32Z" + message: Weave pod has set this + reason: WeaveIsUp + status: "False" + type: NetworkUnavailable + - lastHeartbeatTime: "2022-02-17T22:20:15Z" + lastTransitionTime: "2022-02-17T22:13:25Z" + message: kubelet has sufficient memory available + reason: KubeletHasSufficientMemory + status: "False" + type: MemoryPressure + - lastHeartbeatTime: "2022-02-17T22:20:15Z" + lastTransitionTime: "2022-02-17T22:13:25Z" + message: kubelet has no disk pressure + reason: KubeletHasNoDiskPressure + status: "False" + type: DiskPressure + - lastHeartbeatTime: "2022-02-17T22:20:15Z" + lastTransitionTime: "2022-02-17T22:13:25Z" + message: kubelet has sufficient PID available + reason: KubeletHasSufficientPID + status: "False" + type: PIDPressure + - lastHeartbeatTime: "2022-02-17T22:20:15Z" + lastTransitionTime: "2022-02-17T22:15:15Z" + message: kubelet is posting ready status. AppArmor enabled + reason: KubeletReady + status: "True" + type: Ready + daemonEndpoints: + kubeletEndpoint: + Port: 10250 + nodeInfo: + architecture: amd64 + bootID: 22333234-7a6b-44d4-9ce1-67e31dc7e369 + containerRuntimeVersion: containerd://1.5.9 + kernelVersion: 5.13.0-28-generic + kubeProxyVersion: v1.23.3 + kubeletVersion: v1.23.3 + machineID: 9384e2927f544209b5d7b67474bbf92b + operatingSystem: linux + osImage: Ubuntu 21.10 + systemUUID: aa829ca9-73d7-064d-9019-df07404ad448 +``` + +## Аналіз логів {#looking-at-logs} + +Тепер для докладнішого вивчення кластера потрібно увійти на відповідні машини. Ось розташування відповідних файлів журналу. На системах, що використовують systemd, може знадобитися використання `journalctl` замість перегляду файлів журналу. + +### Вузли панелі управління {#control-plane-nodes} + +* `/var/log/kube-apiserver.log` — Сервер API, відповідальний за обслуговування API +* `/var/log/kube-scheduler.log` — Планувальник, відповідальний за прийняття рішень щодо планування +* `/var/log/kube-controller-manager.log` — Компонент, який виконує більшість вбудованих {{}} Kubernetes, за винятком планування (за це відповідає планувальник kube-scheduler). + +### Робочі вузли {#worker-nodes} + +* `/var/log/kubelet.log` — логи kubelet, відповідального за запуск контейнерів на вузлі +* `/var/log/kube-proxy.log` — логи `kube-proxy`, відповідального за направлення трафіку на Service endpoints. + +## Режими відмови кластера {#cluster-failure-modes} + +Це неповний перелік того, що може піти не так, та як виправити вашу конфігурацію кластера для помʼякшення проблем. + +### Причини відмов {#contributing-causes} + +* Вимкнення віртуальної машин(и) +* Розділ мережі в межах кластера чи між кластером та користувачами +* Крах програмного забезпечення Kubernetes +* Втрата даних або недоступність постійного сховища (наприклад, GCE PD або томів AWS EBS) +* Помилка оператора, наприклад, неправильно налаштоване програмне забезпечення Kubernetes або застосунку + +### Конкретні сценарії {#specific-scenarios} + +* Вимкнення віртуальної машини або аварійне вимикання apiserver + * Результати + * не можна зупинити, оновити чи запустити нові Podʼи, Services, контролер реплікацій + * наявні Podʼи та Services мають продовжувати нормальну роботу, якщо вони не залежать від API Kubernetes +* Втрата даних, на яких ґрунтується API сервер + * Результати + * компонент kube-apiserver не може успішно стартувати та стати спроможним обслуговувати запити + * kubelet не зможе досягти його, але продовжить виконувати ті самі Podʼи та забезпечувати той самий сервіс проксі + * необхідне ручне відновлення або відновлення стану apiserver перед його перезапуском +* Припинення роботи служб підтримки (контролер вузлів, менеджер контролера реплікацій, планувальник і т. д.) або їх крах + * наразі вони розміщені разом з apiserver, і їхня недоступність має схожі наслідки, що й в apiserver + * у майбутньому ці служби також будуть репліковані та не можуть бути розміщені в одному місці + * вони не мають власного постійного стану +* Вимкнення окремого вузла (віртуальна машина або фізична машина) + * Результати + * Podʼи на цьому вузлі перестають працювати +* Розрив мережі + * Результати + * розділ A вважає, що вузли в розділі B вимкнені; розділ B вважає, що apiserver вимкнений. + (Якщо майстер-вузол опиниться в розділі A.) +* Збій програмного забезпечення kubelet + * Результати + * аварійно вимкнений kubelet не може стартувати нові Podʼи на вузлі + * kubelet може видаляти Podʼи або ні + * вузол позначений як неспроможний + * контролери реплікацій стартують нові Podʼи в іншому місці +* Помилка оператора кластера + * Результати + * втрата Podʼів, Services і т. ін. + * втрата сховища даних для apiserver + * користувачі не можуть читати API + * і т.д. + +### Помʼякшення {#mitigations} + +* Дія: Використовуйте функцію автоматичного перезапуску віртуальних машин IaaS для віртуальних машин IaaS + * Помʼякшує: Вимкнення віртуальної машини або аварійне вимикання apiserver + * Помʼякшує: Вимкнення служб підтримки або їх краху + +* Дія: Використовуйте надійне сховище IaaS (наприклад, GCE PD або том AWS EBS) для віртуальних машин з apiserver+etcd + * Помʼякшує: Втрата даних, на яких ґрунтується API сервер + +* Дія: Використовуйте [конфігурацію високої доступності](/docs/setup/production-environment/tools/kubeadm/high-availability/) + * Помʼякшує: Вимкнення вузла керування або аварійне завершення роботи компонентів управління керуванням (планувальник, API сервер, менеджер контролера) + * Витримає одне або кілька одночасних відмов вузлів або компонентів + * Помʼякшує: Втрата сховища даних для API сервера (тобто каталог даних etcd) + * Передбачає конфігурацію HA (highly-available) etcd + +* Дія: Регулярно створюйте знімки віртуальних машин або томів PD/EBS, які використовуються apiserver + * Помʼякшує: Втрата сховища даних для API сервера + * Помʼякшує: Деякі випадки помилок оператора + * Помʼякшує: Деякі випадки несправності програмного забезпечення Kubernetes + +* Дія: Використовуйте контролер реплікацій та служби перед Podʼами + * Помʼякшує: Вимкнення вузла + * Помʼякшує: Збій програмного забезпечення kubelet + +* Дія: Застосунки (контейнери), призначені для того, щоб витримувати неочікувані перезапуски + * Помʼякшує: Вимкнення вузла + * Помʼякшує: Збій програмного забезпечення kubelet + +## {{% heading "whatsnext" %}} + +* Дізнайтеся про метрики, доступні в + [Resource Metrics Pipeline](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/) +* Відкрийте додаткові інструменти для + [моніторингу використання ресурсів](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) +* Використовуйте Node Problem Detector для + [моніторингу стану вузла](/docs/tasks/debug/debug-cluster/monitor-node-health/) +* Використовуйте `kubectl debug node` для [відлагодження вузлів Kubernetes](/docs/tasks/debug/debug-cluster/kubectl-node-debug) +* Використовуйте `crictl` для [відлагодження вузлів Kubernetes](/docs/tasks/debug/debug-cluster/crictl/) +* Отримайте більше інформації про [аудит Kubernetes](/docs/tasks/debug/debug-cluster/audit/) +* Використовуйте `telepresence` для [розробки та відлагодження служб локально](/docs/tasks/debug/debug-cluster/local-debugging/) \ No newline at end of file diff --git a/content/uk/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/uk/docs/tasks/extend-kubectl/kubectl-plugins.md new file mode 100644 index 0000000000000..2605ba879511d --- /dev/null +++ b/content/uk/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -0,0 +1,338 @@ +--- +title: "Розширення kubectl за допомогою втулків" +reviewers: +- juanvallejo +- soltysh +description: "Дізнайтеся, як розширити kubectl за допомогою втулків." +content_type: task +--- + + + +Цей посібник демонструє, як встановлювати та створювати розширення для [kubectl](/docs/reference/kubectl/kubectl/). Вважаючи основні команди `kubectl` основними будівельними блоками для взаємодії з кластером Kubernetes, адміністратор кластера може розглядати втулки як засіб використання цих будівельних блоків для створення складнішої поведінки. Втулки розширюють `kubectl` новими підкомандами, що дозволяє використовувати нові та власні функції, які не входять до основного дистрибутиву `kubectl`. + +## {{% heading "prerequisites" %}} + +Вам потрібно мати встановлений працюючий бінарний файл `kubectl`. + + + +## Встановлення втулків для kubectl {#installing-kubectl-plugins} + +Втулок — це автономний виконуваний файл, назва якого починається з `kubectl-`. Для встановлення втулка перемістіть його виконуваний файл до будь-якої теки, що знаходиться в вашому `PATH`. + +Ви також можете знайти та встановити втулки для `kubectl`, наявні у відкритому доступі, за допомогою [Krew](https://krew.dev/). Krew — це менеджер втулків, підтримуваний спільнотою Kubernetes SIG CLI. + +{{< caution >}} +Втулки для `kubectl`, доступні через [індекс втулків Krew](https://krew.sigs.k8s.io/plugins/), не перевіряються на безпеку. Ви повинні встановлювати та запускати втулки на власний розсуд, оскільки це довільні програми, що виконуються на вашому компʼютері. +{{< /caution >}} + +### Пошук втулків {#discovering-plugins} + +`kubectl` надає команду `kubectl plugin list`, яка оглядає ваш `PATH` для відповідних виконуваних файлів втулків. Виконання цієї команди призводить до огляду всіх файлів у вашому `PATH`. Будь-які файли, які є виконуваними та починаються з `kubectl-`, зʼявляться *в порядку їх розташування в вашому `PATH`* у виводі цієї команди. Для будь-яких файлів, що починаються з `kubectl-` та *не* є виконуваними, буде додано попередження. Також буде додане попередження для будь-яких вірних файлів втулків, назви яких перекриваються. + +Ви можете використовувати [Krew](https://krew.dev/), щоб шукати та встановлювати втулки для `kubectl` з [індексу втулків](https://krew.sigs.k8s.io/plugins/), який підтримується спільнотою. + +#### Обмеження + +Зараз неможливо створити втулки, які перезаписують чинні команди `kubectl`. Наприклад, створення втулка `kubectl-version` призведе до того, що цей втулок ніколи не буде виконаний, оскільки наявна команда `kubectl version` завжди матиме пріоритет. За цим обмеженням також *не* можна використовувати втулки для додавання нових підкоманд до наявних команд `kubectl`. Наприклад, додавання підкоманди `kubectl create foo`, назвавши свій втулок `kubectl-create-foo`, призведе до його ігнорування. + +`kubectl plugin list` виводить попередження для будь-яких вірних втулків, які намагаються це зробити. + +## Написання втулків для kubectl {#writing-kubectl-plugins} + +Ви можете написати втулок будь-якою мовою програмування або скриптом, який дозволяє вам створювати команди для командного рядка. + +Для втулків не потрібно жодної установки чи попереднього завантаження. Виконувані файли втулків успадковують середовище від бінарного файлу `kubectl`. Втулок визначає, який шлях команди він бажає реалізувати на основі свого імені. Наприклад, втулок з іменем `kubectl-foo` надає команду `kubectl foo`. Вам потрібно встановити виконуваний файл втулка десь у вашому `PATH`. + +### Приклад втулка {#example-plugin} + +```bash +#!/bin/bash + +# optional argument handling +if [[ "$1" == "version" ]] +then + echo "1.0.0" + exit 0 +fi + +# optional argument handling +if [[ "$1" == "config" ]] +then + echo "$KUBECONFIG" + exit 0 +fi + +echo "I am a plugin named kubectl-foo" +``` + +### Користування втулком {#using-a-plugin + +Для використання втулка зробіть його виконуваним: + +```shell +sudo chmod +x ./kubectl-foo +``` + +та помістіть його в теку, яка знаходиться в вашому `PATH`: + +```shell +sudo mv ./kubectl-foo /usr/local/bin +``` + +Тепер ви можете викликати втулок, використовуючи `kubectl foo`: + +```shell +kubectl foo +``` + +``` +I am a plugin named kubectl-foo +``` + +Всі аргументи та прапорці, передаються втулку як-вони-є для виконання: + +```shell +kubectl foo version +``` + +``` +1.0.0 +``` + +Всі змінні оточення також передається у вигляді як-вони-є: + +```bash +export KUBECONFIG=~/.kube/config +kubectl foo config +``` + +``` +/home//.kube/config +``` + +```shell +KUBECONFIG=/etc/kube/config kubectl foo config +``` + +``` +/etc/kube/config +``` + +Крім того, перший аргумент, який передається втуку, завжди буде повним шляхом до місця, де його було викликано (`$0` буде дорівнювати `/usr/local/bin/kubectl-foo` в прикладі вище). + +### Іменування втулків {#naming-a-plugin} + +Як видно в прикладі вище, втулок визначає шлях команди, яку він буде реалізовувати, на основі свого імені файлу. Кожна підкоманда в шляху, для якої використовується втулок, розділена дефісом (`-`). Наприклад, втулок, який бажає запускатись, коли користувач викликає команду `kubectl foo bar baz`, матиме імʼя файлу `kubectl-foo-bar-baz`. + +#### Обробка прапорців та аргументів {#flag-and-argument-handling} + +{{< note >}} +Механізм втулків не створює жодних специфічних для втулків значень або змінних середовища для процесу втулка. + +Раніше існувавший механізм втулків kubectl надавав змінні середовища, такі як `KUBECTL_PLUGINS_CURRENT_NAMESPACE`; таке вже не відбувається. +{{< /note >}} + +Втулки kubectl повинні розбирати та перевіряти всі передані їм аргументи. Див. [використання пакета command line runtime](#using-the-command-line-runtime-package) для отримання відомостей про бібліотеку Go, призначену на авторів втулків. + +Нижче наведено кілька додаткових випадків, коли користувачі викликають ваш втулок, надаючи додаткові прапорці та аргументи. Розберемо це на прикладі втулка `kubectl-foo-bar-baz` з вищезазначеного сценарію. + +Якщо ви виконуєте `kubectl foo bar baz arg1 --flag=value arg2`, механізм втулків kubectl спочатку намагатиметься знайти втулок з найдовшим можливим імʼям, що в цьому випадку буде `kubectl-foo-bar-baz-arg1`. Не знайшовши цього втулка, kubectl тоді розглядає останнє значення, розділене дефісами, як аргумент (тут `arg1`) та намагається знайти наступне найдовше можливе ім'я, `kubectl-foo-bar-baz`. Знайшовши втулок з таким імʼям, kubectl викликає цей втулок, передаючи всі аргументи та прапорці після імені втулка як аргументи для процесу втулка. + +Приклад: + +```bash +# створимо втулок +echo -e '#!/bin/bash\n\necho "My first command-line argument was $1"' > kubectl-foo-bar-baz +sudo chmod +x ./kubectl-foo-bar-baz + +# "iвстановимо" ваш втулок перемістивши його у теку з $PATH +sudo mv ./kubectl-foo-bar-baz /usr/local/bin + +# перевіримо, що kubectl розпізнав ваш втулок +kubectl plugin list +``` + +```none +The following kubectl-compatible plugins are available: + +/usr/local/bin/kubectl-foo-bar-baz +``` + +```shell +# перевірте, що виклик вашого втулка через команду "kubectl" працює +# навіть тоді, коли користувач передає додаткові аргументи та прапорці +# до виконуваного користувачем виконуваного файлу вашого втулка. + +kubectl foo bar baz arg1 --meaningless-flag=true +``` + +```none +My first command-line argument was arg1 +``` + +Як бачите, ваш втулок було знайдено на основі команди `kubectl`, вказаної користувачем, і всі додаткові аргументи та прапорці були передані як є до виконуваного файлу втулка після того, як його було знайдено. + +#### Назви з дефісами та підкреслюваннями {#names-with-dashes-and-underscores} + +Хоча механізм втулків `kubectl` використовує дефіси (`-`) у іменах файлів втулків для розділення послідовності підкоманд, оброблених втулком, все ж можна створити втулок з іменем, що містить дефіс в його виклику з командного рядка, використовуючи підкреслення (`_`) у його імені файлу. + +Приклад: + +```bash +# створимо втулок, що містить підкреслення в назві файлу +echo -e '#!/bin/bash\n\necho "I am a plugin with a dash in my name"' > ./kubectl-foo_bar +sudo chmod +x ./kubectl-foo_bar + +# перемістимо втулок у теку з $PATH +sudo mv ./kubectl-foo_bar /usr/local/bin + +# тепер ви можете викликати ваш втулок через kubectl: +kubectl foo-bar +``` + +``` +I am a plugin with a dash in my name +``` + +Зауважте, що додавання підкреслення в імʼя файлу втулка не заважає створенню команд, таких як `kubectl foo_bar`. Команду з прикладу вище можна викликати як з дефісом (`-`), так і з підкресленням (`_`): + +```bash +# Ви можете викликати вашу власну команду з дефісом +kubectl foo-bar +``` + +``` +I am a plugin with a dash in my name +``` + +```bash +# Ви ткаож можете викликати свою власну команду з підкресленнями +kubectl foo_bar +``` + +``` +I am a plugin with a dash in my name +``` + +#### Конфлікти імен та затьмарення {#name-conflicts-and-overshadowing} + +Можливе існування кількох втулків з однаковою назвою файлу в різних розташуваннях у вашому `PATH`. Наприклад, при наступному значенні `PATH`: `PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins`, копія втулка `kubectl-foo` може існувати в `/usr/local/bin/plugins` та `/usr/local/bin/moreplugins`, так що результат виклику команди `kubectl plugin list` буде наступним: + +```bash +PATH=/usr/local/bin/plugins:/usr/local/bin/moreplugins kubectl plugin list +``` + +``` +The following kubectl-compatible plugins are available: + +/usr/local/bin/plugins/kubectl-foo +/usr/local/bin/moreplugins/kubectl-foo + - warning: /usr/local/bin/moreplugins/kubectl-foo is overshadowed by a similarly named plugin: /usr/local/bin/plugins/kubectl-foo + +error: one plugin warning was found +``` + +У вказаному вище сценарії попередження під `/usr/local/bin/moreplugins/kubectl-foo` говорить вам, що цей втулок ніколи не буде виконано. Замість цього виконується файл, який зʼявляється першим у вашому `PATH`, `/usr/local/bin/plugins/kubectl-foo`, завдяки механізму втулків `kubectl`. + +Спосіб розвʼязання цієї проблеми — переконатися, що розташування втулка, яким ви хочете скористатися з `kubectl`, завжди стоїть на першому місці в вашому `PATH`. Наприклад, якщо ви хочете завжди використовувати `/usr/local/bin/moreplugins/kubectl-foo` в будь-який раз, коли викликається команда `kubectl foo`, змініть значення вашого `PATH` на `/usr/local/bin/moreplugins:/usr/local/bin/plugins`. + +#### Виклик найдовшого імені виконуваного файлу {#invocation-of-the-longest-executable-name} + +Є ще один вид перекриття, який може виникнути з іменами втулків. Допустимо, є два втулки у шляху користувача: `kubectl-foo-bar` та `kubectl-foo-bar-baz`. Механізм втулків `kubectl` завжди вибиратиме найдовше можливе імʼя втулка для заданої команди користувача. Нижче наведено деякі приклади, які докладніше пояснюють це: + +```bash +# для заданої команди `kubectl` завжди буде вибиратися втулок з найдовшим можливим іменем файла +kubectl foo bar baz +``` + +``` +Plugin kubectl-foo-bar-baz is executed +``` + +```bash +kubectl foo bar +``` + +``` +Plugin kubectl-foo-bar is executed +``` + +```bash +kubectl foo bar baz buz +``` + +``` +Plugin kubectl-foo-bar-baz is executed, with "buz" as its first argument +``` + +```bash +kubectl foo bar buz +``` + +``` +Plugin kubectl-foo-bar is executed, with "buz" as its first argument +``` + +Цей вибір дизайну гарантує, що підкоманди втулків можуть бути реалізовані у кількох файлах, якщо це необхідно, і що ці підкоманди можуть бути вкладені під "батьківською" командою втулка: + +```bash +ls ./plugin_command_tree +``` + +``` +kubectl-parent +kubectl-parent-subcommand +kubectl-parent-subcommand-subsubcommand +``` + +### Перевірка на наявність попереджень втулків {#checking-for-plugin-warnings} + +Ви можете скористатися вищезазначеною командою `kubectl plugin list`, щоб переконатися, що ваш втулок можна викликати за допомогою `kubectl`, та перевірити, чи немає попереджень, які перешкоджають його виклику як команди `kubectl`. + +```bash +kubectl plugin list +``` + +``` +The following kubectl-compatible plugins are available: + +test/fixtures/pkg/kubectl/plugins/kubectl-foo +/usr/local/bin/kubectl-foo + - warning: /usr/local/bin/kubectl-foo is overshadowed by a similarly named plugin: test/fixtures/pkg/kubectl/plugins/kubectl-foo +plugins/kubectl-invalid + - warning: plugins/kubectl-invalid identified as a kubectl plugin, but it is not executable + +error: 2 plugin warnings were found +``` + +### Використання пакунка виконання командного рядка {#using-the-command-line-runtime-package} + +Якщо ви пишете втулку для kubectl і використовуєте Go, ви можете скористатися [cli-runtime](https://github.com/kubernetes/cli-runtime) бібліотеками. + +Ці бібліотеки надають помічників для парсингу або оновлення файлу [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) користувача, для виконання запитів REST до API-сервера або звʼязування прапорців повʼязаних з конфігурацією та друком. + +Перегляньте [Sample CLI Plugin](https://github.com/kubernetes/sample-cli-plugin) для прикладу використання інструментів, які надаються у репозиторії CLI Runtime. + +## Розповсюдження втулків для kubectl {#distributing-kubectl-plugins} + +Якщо ви розробили втулок для того, щоб інші користувачі могли його використовувати, вам слід розглянути, як ви його пакуєте, розповсюджуєте і надаєте оновлення для користувачів. + +### Krew {#distributing-krew} + +[Krew](https://krew.dev/) пропонує крос-платформний спосіб пакування та розповсюдження ваших втулків. Таким чином, ви використовуєте єдиний формат пакування для всіх цільових платформ (Linux, Windows, macOS і т.д.) і надаєте оновлення користувачам. Krew також підтримує [індекс втулків](https://krew.sigs.k8s.io/plugins/), щоб інші люди могли знайти ваш втулок та встановлювати його. + +### Нативне / платформозалежне керування пакетами {#distributing-native} + +З іншого боку, ви можете використовувати традиційні системи керування пакунками, такі як `apt` або `yum` в Linux, Chocolatey в Windows і Homebrew в macOS. Будь-який менеджер пакунків підійде, якщо він може розмістити нові виконувані файли в каталозі `PATH` користувача. Як автор втулка, якщо ви обираєте цей варіант, вам також слід покласти на себе тягар оновлення пакунка для розповсюдження ваших втулків для kubectl для кожного релізу на кожній платформі. + +### Сирці {#distributing-source-code} + +Ви можете публікувати сирці, наприклад, як Git-репозиторій. Якщо ви обираєте цей варіант, той, хто хоче використовувати цей втулок, повинен витягти код, налаштувати середовище збірки (якщо він потребує компіляції) та використовувати втулок. Якщо ви також надаєте доступні скомпільовані пакунки або використовуєте Krew, це спростить процес встановлення. + +## {{% heading "whatsnext" %}} + +* Перегляньте репозиторій [Sample CLI Plugin](https://github.com/kubernetes/sample-cli-plugin) для детального прикладу втулка, написаного на Go. +* У разі будь-яких питань, не соромтеся звертатися до [команди SIG CLI](https://github.com/kubernetes/community/tree/master/sig-cli). +* Дізнайтеся більше про [Krew](https://krew.dev/), менеджер пакунків для втулків kubectl. diff --git a/content/uk/docs/tasks/extend-kubernetes/_index.md b/content/uk/docs/tasks/extend-kubernetes/_index.md new file mode 100644 index 0000000000000..bfbef5ffd4548 --- /dev/null +++ b/content/uk/docs/tasks/extend-kubernetes/_index.md @@ -0,0 +1,5 @@ +--- +title: "Розширення Kubernetes" +description: Розуміння розширених способів адаптації кластера Kubernetes до потреб вашого робочого середовища. +weight: 110 +--- diff --git a/content/uk/docs/tasks/inject-data-application/_index.md b/content/uk/docs/tasks/inject-data-application/_index.md new file mode 100644 index 0000000000000..a1b0c24c22f00 --- /dev/null +++ b/content/uk/docs/tasks/inject-data-application/_index.md @@ -0,0 +1,5 @@ +--- +title: Введення даних у застосунки +description: Визначення конфігурації та інших даних для Podʼів, на яких працює ваше навантаження. +weight: 70 +--- diff --git a/content/uk/docs/tasks/job/_index.md b/content/uk/docs/tasks/job/_index.md new file mode 100644 index 0000000000000..f5fc7cf7f770c --- /dev/null +++ b/content/uk/docs/tasks/job/_index.md @@ -0,0 +1,5 @@ +--- +title: "Запуск Job" +description: "Запуск Job з використанням паралельної обробки." +weight: 90 +--- diff --git a/content/uk/docs/tasks/manage-daemon/_index.md b/content/uk/docs/tasks/manage-daemon/_index.md new file mode 100644 index 0000000000000..975bfe7c7f342 --- /dev/null +++ b/content/uk/docs/tasks/manage-daemon/_index.md @@ -0,0 +1,5 @@ +--- +title: "Керування фоновими процесами кластера" +description: Виконуйте загальні завдання для керування DaemonSet, такі як виконання поступового оновлення. +weight: 130 +--- diff --git a/content/uk/docs/tasks/manage-gpus/scheduling-gpus.md b/content/uk/docs/tasks/manage-gpus/scheduling-gpus.md new file mode 100644 index 0000000000000..2ae39f8099ebf --- /dev/null +++ b/content/uk/docs/tasks/manage-gpus/scheduling-gpus.md @@ -0,0 +1,109 @@ +--- +reviewers: +- vishh +content_type: concept +title: Планування GPU +description: Налаштування та планування GPU для використання як ресурсу вузлів у кластері. +--- + + + +{{< feature-state state="stable" for_k8s_version="v1.26" >}} + +Kubernetes має **стабільну** підтримку для управління графічними обчислювальними пристроями (GPU) від AMD та NVIDIA на різних вузлах вашого кластера, використовуючи {{< glossary_tooltip text="втулки пристроїв" term_id="device-plugin" >}}. + +На цій сторінці описано, як користувачі можуть використовувати GPU і наведені деякі обмеження в реалізації. + + + +## Використання втулків пристроїв {#using-device-plugins} + +Kubernetes використовує втулки пристроїв, щоб дозволити Podʼам отримувати доступ до спеціалізованих апаратних можливостей, таких як GPU. + +{{% thirdparty-content %}} + +Як адміністратору, вам потрібно встановити драйвери GPU від відповідного виробника обладнання на вузлах і запустити відповідний втулок пристрою від виробника GPU. Ось кілька посилань на інструкції від виробників: + +* [AMD](https://github.com/RadeonOpenCompute/k8s-device-plugin#deployment) +* [Intel](https://intel.github.io/intel-device-plugins-for-kubernetes/cmd/gpu_plugin/README.html) +* [NVIDIA](https://github.com/NVIDIA/k8s-device-plugin#quick-start) + +Після встановлення втулка ваш кластер використовує власний ресурс планування, такий як `amd.com/gpu` або `nvidia.com/gpu`. + +Ви можете використовувати ці GPU у ваших контейнерах, запитуючи власний ресурс GPU,, так само як ви запитуєте `cpu` чи `memory`. +Однак є обмеження у специфікації вимог до ресурсів для власних пристроїв. + +GPU повинні бути вказані тільки в розділі `limits`, що означає: + +* Ви можете вказати `limits` для GPU без вказівки `requests`, оскільки Kubernetes за стандартно використовує ліміт як значення запиту. +* Ви можете вказати GPU як в `limits`, так і в `requests`, але ці два значення повинні бути рівними. +* Ви не можете вказати `requests` для GPU без вказівки `limits`. + +Ось приклад маніфесту для Podʼі, який запитує GPU: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: example-vector-add +spec: + restartPolicy: OnFailure + containers: + - name: example-vector-add + image: "registry.example/example-vector-add:v42" + resources: + limits: + gpu-vendor.example/example-gpu: 1 # запит на 1 GPU +``` + +## Керуйте кластерами з різними типами GPU {#managing-clusters-with-different-types-of-gpus} + +Якщо в різних вузлах вашого кластера є різні типи GPU, то ви можете використовувати [мітки вузлів і селектори вузлів](/docs/tasks/configure-pod-container/assign-pods-nodes/) для планування Podʼів на відповідних вузлах. + +Наприклад: + +```shell +# Позначте свої вузли з типом прискорювача, яким вони володіють. +kubectl label nodes node1 accelerator=example-gpu-x100 +kubectl label nodes node2 accelerator=other-gpu-k915 +``` + +Ця мітка ключа `accelerator` лише приклад; ви можете використовувати інший ключ мітки, якщо це зручніше. + +## Автоматичне позначення вузлів {#node-labelling} + +Як адміністратор, ви можете автоматично виявляти та мітити всі ваши вузли з підтримкою GPU, розгорнувши [Виявлення функцій вузлів Kubernetes](https://github.com/kubernetes-sigs/node-feature-discovery) (NFD). NFD виявляє апаратні функції, які доступні на кожному вузлі в кластері Kubernetes. Зазвичай NFD налаштовується таким чином, щоб оголошувати ці функції як мітки вузла, але NFD також може додавати розширені ресурси, анотації та заплямування вузла (node taints). NFD сумісний з усіма [підтримуваними версіями](/releases/version-skew-policy/#supported-versions) Kubernetes. Типово NFD створює [мітки функцій](https://kubernetes-sigs.github.io/node-feature-discovery/master/usage/features.html) для виявлених функцій. Адміністратори можуть використовувати NFD, щоб також мітити вузли конкретними функціями, щоб на них можна було планувати лише Podʼи, які запитують ці функції. + +Вам також потрібен втулок для NFD, який додає відповідні мітки до ваших вузлів; це можуть бути загальні мітки або вони можуть бути вендор-специфічними. Ваш вендор GPU може надати втулок від третіх сторін для NFD; перевірте їх документацію для отримання додаткової інформації. + +{{< highlight yaml "linenos=false,hl_lines=6-18" >}} +apiVersion: v1 +kind: Pod +metadata: + name: example-vector-add +spec: + # Виможете використовувати Kubernetes node affinity для планування цього Podʼу на вузол + # який надає kind типу GPU, який потрібе його контейнеру для роботи + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: "gpu.gpu-vendor.example/installed-memory" + operator: Gt # (greater than) + values: ["40535"] + - key: "feature.node.kubernetes.io/pci-10.present" # NFD Feature label + values: ["true"] # (optional) only schedule on nodes with PCI device 10 + restartPolicy: OnFailure + containers: + - name: example-vector-add + image: "registry.example/example-vector-add:v42" + resources: + limits: + gpu-vendor.example/example-gpu: 1 # запит 1 GPU +{{< /highlight >}} + +#### Вендори GPU {#gpu-vendor-implementations} + +* [Intel](https://intel.github.io/intel-device-plugins-for-kubernetes/cmd/gpu_plugin/README.html) +* [NVIDIA](https://github.com/NVIDIA/gpu-feature-discovery/#readme) diff --git a/content/uk/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/uk/docs/tasks/manage-hugepages/scheduling-hugepages.md new file mode 100644 index 0000000000000..9f7c58ed715a1 --- /dev/null +++ b/content/uk/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -0,0 +1,125 @@ +--- +reviewers: +- derekwaynecarr +title: Керування HugePages +content_type: task +description: Налаштування та керування великими сторінками як запланованим ресурсом в кластері. +--- + + +{{< feature-state state="stable" >}} + +Kubernetes підтримує виділення та використання заздалегідь розміщених великих сторінок (huge pages) застосунками в Podʼі. Ця сторінка описує, як користувачі можуть використовувати великі сторінки. + +## {{% heading "prerequisites" %}} + +На вузлах Kubernetes необхідно [перед використанням резервувати місце під великі сторінки](https://www.kernel.org/doc/html/latest/admin-guide/mm/hugetlbpage.html), щоб вузол зміг вказати свою ємність для великих сторінок. + +Вузол може резервувати великі сторінки різних розмірів, наприклад, наступний рядок у файлі `/etc/default/grub` резервує `2*1 ГБ` памʼяті для сторінок розміром 1 ГБ і `512*2 МБ` для сторінок розміром 2 МБ: + +``` +GRUB_CMDLINE_LINUX="hugepagesz=1G hugepages=2 hugepagesz=2M hugepages=512" +``` + +Вузли автоматично виявлять та повідомлять про всі великі сторінки як планові ресурси. + +Під час опису вузла ви повинні побачити щось подібне до наступного у розділах `Capacity` та `Allocatable`: + +``` +Capacity: + cpu: ... + ephemeral-storage: ... + hugepages-1Gi: 2Gi + hugepages-2Mi: 1Gi + memory: ... + pods: ... +Allocatable: + cpu: ... + ephemeral-storage: ... + hugepages-1Gi: 2Gi + hugepages-2Mi: 1Gi + memory: ... + pods: ... +``` + +{{< note >}} +Для динамічно виділених сторінок (після завантаження), Kubelet потрібно перезапустити, щоб нові обсяги були показані. +{{< /note >}} + + + +## API + +Великі сторінки можна використовувати за допомогою вимог до ресурсів на рівні контейнера з використанням імені ресурсу `hugepages-`, де `` — це найбільш компактне двійкове позначення з використанням цілочисельних значень, які підтримуються на певному вузлі. Наприклад, якщо вузол підтримує розміри сторінок 2048KiB та 1048576KiB, він буде показувати розміри `hugepages-2Mi` та `hugepages-1Gi`. На відміну від CPU або памʼяті, великі сторінки не підтримують перевищення. Зверніть увагу, що при запиті ресурсів великих сторінок також потрібно вказувати ресурси памʼяті або CPU. + +Pod може мати різні розміри великих сторінок в одній специфікації Podʼу. У цьому випадку для всіх точок монтування томів вона повинна використовувати нотацію `medium: HugePages-`. + + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: huge-pages-example +spec: + containers: + - name: example + image: fedora:latest + command: + - sleep + - inf + volumeMounts: + - mountPath: /hugepages-2Mi + name: hugepage-2mi + - mountPath: /hugepages-1Gi + name: hugepage-1gi + resources: + limits: + hugepages-2Mi: 100Mi + hugepages-1Gi: 2Gi + memory: 100Mi + requests: + memory: 100Mi + volumes: + - name: hugepage-2mi + emptyDir: + medium: HugePages-2Mi + - name: hugepage-1gi + emptyDir: + medium: HugePages-1Gi +``` + +Pod може використовувати `medium: HugePages` лише у випадку, якщо він запитує великі сторінки лише одного розміру. + + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: huge-pages-example +spec: + containers: + - name: example + image: fedora:latest + command: + - sleep + - inf + volumeMounts: + - mountPath: /hugepages + name: hugepage + resources: + limits: + hugepages-2Mi: 100Mi + memory: 100Mi + requests: + memory: 100Mi + volumes: + - name: hugepage + emptyDir: + medium: HugePages +``` + +- Запити великих сторінок повинні дорівнювати лімітам. Це є стандартним, якщо ліміти вказані, а запити — ні. +- Великі сторінки ізольовані на рівні контейнера, тому кожен контейнер має власний ліміт, як вказано у специфікації контейнера. +- Томи EmptyDir, що підтримуються великими сторінками, не можуть споживати більше памʼяті великих сторінок, ніж запитується для Podʼу. +- Застосунки, які використовують великі сторінки за допомогою `shmget()` з `SHM_HUGETLB`, повинні працювати з допоміжною групою, яка відповідає за `proc/sys/vm/hugetlb_shm_group`. +- Використанням великих сторінок у просторі імен можливо керувати за допомогою ResourceQuota, подібно іншим обчислювальним ресурсам, таким як `cpu` або `memory`, використовуючи токен `hugepages-`. diff --git a/content/uk/docs/tasks/manage-kubernetes-objects/_index.md b/content/uk/docs/tasks/manage-kubernetes-objects/_index.md new file mode 100644 index 0000000000000..55b807362b365 --- /dev/null +++ b/content/uk/docs/tasks/manage-kubernetes-objects/_index.md @@ -0,0 +1,5 @@ +--- +title: Керування обʼєктами Kubernetes +description: Декларативні та імперативні парадигми взаємодії з API Kubernetes. +weight: 50 +--- diff --git a/content/uk/docs/tasks/network/_index.md b/content/uk/docs/tasks/network/_index.md new file mode 100644 index 0000000000000..f1fa6a79893e5 --- /dev/null +++ b/content/uk/docs/tasks/network/_index.md @@ -0,0 +1,5 @@ +--- +title: Мережа +description: Дізнайтесь, як налаштувати мережу для вашого кластера Kubernetes. +weight: 140 +--- diff --git a/content/uk/docs/tasks/run-application/_index.md b/content/uk/docs/tasks/run-application/_index.md new file mode 100644 index 0000000000000..45d0afeeac4b0 --- /dev/null +++ b/content/uk/docs/tasks/run-application/_index.md @@ -0,0 +1,5 @@ +--- +title: Запуск застосунків +description: Запуск та керування застосунками зі збереженням стану так і без збереження стану" +weight: 80 +--- diff --git a/content/uk/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/uk/docs/tasks/run-application/horizontal-pod-autoscale.md new file mode 100644 index 0000000000000..7b259b8d98f29 --- /dev/null +++ b/content/uk/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -0,0 +1,608 @@ +--- +reviewers: +- fgrzadkowski +- jszczepkowski +- directxman12 +title: Горизонтальне автомасштабування Podʼів +feature: + title: Горизонтальне масштабування + description: > + Масштабуйте свої застосунки, збільшуйте та зменшуйте кількість їх екземплярів за допомогою простої команди, в графічному інтерфейсі або автоматично на основі використання ЦП. +content_type: concept +weight: 90 +--- + + + +In Kubernetes, a _HorizontalPodAutoscaler_ automatically updates a workload resource (such as +a {{< glossary_tooltip text="Deployment" term_id="deployment" >}} or +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}), with the +aim of automatically scaling the workload to match demand. + +Horizontal scaling means that the response to increased load is to deploy more +{{< glossary_tooltip text="Pods" term_id="pod" >}}. +This is different from _vertical_ scaling, which for Kubernetes would mean +assigning more resources (for example: memory or CPU) to the Pods that are already +running for the workload. + +If the load decreases, and the number of Pods is above the configured minimum, +the HorizontalPodAutoscaler instructs the workload resource (the Deployment, StatefulSet, +or other similar resource) to scale back down. + +Horizontal pod autoscaling does not apply to objects that can't be scaled (for example: +a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}.) + +The HorizontalPodAutoscaler is implemented as a Kubernetes API resource and a +{{< glossary_tooltip text="controller" term_id="controller" >}}. +The resource determines the behavior of the controller. +The horizontal pod autoscaling controller, running within the Kubernetes +{{< glossary_tooltip text="control plane" term_id="control-plane" >}}, periodically adjusts the +desired scale of its target (for example, a Deployment) to match observed metrics such as average +CPU utilization, average memory utilization, or any other custom metric you specify. + +There is [walkthrough example](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) of using +horizontal pod autoscaling. + + + +## How does a HorizontalPodAutoscaler work? + +{{< mermaid >}} +graph BT + +hpa[Horizontal Pod Autoscaler] --> scale[Scale] + +subgraph rc[RC / Deployment] + scale +end + +scale -.-> pod1[Pod 1] +scale -.-> pod2[Pod 2] +scale -.-> pod3[Pod N] + +classDef hpa fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef rc fill:#F9CB9C,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef scale fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef pod fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +class hpa hpa; +class rc rc; +class scale scale; +class pod1,pod2,pod3 pod +{{< /mermaid >}} + +Figure 1. HorizontalPodAutoscaler controls the scale of a Deployment and its ReplicaSet + +Kubernetes implements horizontal pod autoscaling as a control loop that runs intermittently +(it is not a continuous process). The interval is set by the +`--horizontal-pod-autoscaler-sync-period` parameter to the +[`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/) +(and the default interval is 15 seconds). + +Once during each period, the controller manager queries the resource utilization against the +metrics specified in each HorizontalPodAutoscaler definition. The controller manager +finds the target resource defined by the `scaleTargetRef`, +then selects the pods based on the target resource's `.spec.selector` labels, +and obtains the metrics from either the resource metrics API (for per-pod resource metrics), +or the custom metrics API (for all other metrics). + +- For per-pod resource metrics (like CPU), the controller fetches the metrics + from the resource metrics API for each Pod targeted by the HorizontalPodAutoscaler. + Then, if a target utilization value is set, the controller calculates the utilization + value as a percentage of the equivalent + [resource request](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) + on the containers in each Pod. If a target raw value is set, the raw metric values are used directly. + The controller then takes the mean of the utilization or the raw value (depending on the type + of target specified) across all targeted Pods, and produces a ratio used to scale + the number of desired replicas. + + Please note that if some of the Pod's containers do not have the relevant resource request set, + CPU utilization for the Pod will not be defined and the autoscaler will + not take any action for that metric. See the [algorithm details](#algorithm-details) section below + for more information about how the autoscaling algorithm works. + +- For per-pod custom metrics, the controller functions similarly to per-pod resource metrics, + except that it works with raw values, not utilization values. + +- For object metrics and external metrics, a single metric is fetched, which describes + the object in question. This metric is compared to the target + value, to produce a ratio as above. In the `autoscaling/v2` API + version, this value can optionally be divided by the number of Pods before the + comparison is made. + +The common use for HorizontalPodAutoscaler is to configure it to fetch metrics from +{{< glossary_tooltip text="aggregated APIs" term_id="aggregation-layer" >}} +(`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`). The `metrics.k8s.io` API is +usually provided by an add-on named Metrics Server, which needs to be launched separately. +For more information about resource metrics, see +[Metrics Server](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server). + +[Support for metrics APIs](#support-for-metrics-apis) explains the stability guarantees and support status for these +different APIs. + +The HorizontalPodAutoscaler controller accesses corresponding workload resources that support scaling (such as Deployments +and StatefulSet). These resources each have a subresource named `scale`, an interface that allows you to dynamically set the +number of replicas and examine each of their current states. +For general information about subresources in the Kubernetes API, see +[Kubernetes API Concepts](/docs/reference/using-api/api-concepts/). + +### Algorithm details + +From the most basic perspective, the HorizontalPodAutoscaler controller +operates on the ratio between desired metric value and current metric +value: + +``` +desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )] +``` + +For example, if the current metric value is `200m`, and the desired value +is `100m`, the number of replicas will be doubled, since `200.0 / 100.0 == +2.0` If the current value is instead `50m`, you'll halve the number of +replicas, since `50.0 / 100.0 == 0.5`. The control plane skips any scaling +action if the ratio is sufficiently close to 1.0 (within a globally-configurable +tolerance, 0.1 by default). + +When a `targetAverageValue` or `targetAverageUtilization` is specified, +the `currentMetricValue` is computed by taking the average of the given +metric across all Pods in the HorizontalPodAutoscaler's scale target. + +Before checking the tolerance and deciding on the final values, the control +plane also considers whether any metrics are missing, and how many Pods +are [`Ready`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions). +All Pods with a deletion timestamp set (objects with a deletion timestamp are +in the process of being shut down / removed) are ignored, and all failed Pods +are discarded. + +If a particular Pod is missing metrics, it is set aside for later; Pods +with missing metrics will be used to adjust the final scaling amount. + +When scaling on CPU, if any pod has yet to become ready (it's still +initializing, or possibly is unhealthy) _or_ the most recent metric point for +the pod was before it became ready, that pod is set aside as well. + +Due to technical constraints, the HorizontalPodAutoscaler controller +cannot exactly determine the first time a pod becomes ready when +determining whether to set aside certain CPU metrics. Instead, it +considers a Pod "not yet ready" if it's unready and transitioned to +ready within a short, configurable window of time since it started. +This value is configured with the `--horizontal-pod-autoscaler-initial-readiness-delay` +flag, and its default is 30 seconds. +Once a pod has become ready, it considers any transition to +ready to be the first if it occurred within a longer, configurable time +since it started. This value is configured with the +`--horizontal-pod-autoscaler-cpu-initialization-period` flag, and its +default is 5 minutes. + +The `currentMetricValue / desiredMetricValue` base scale ratio is then +calculated using the remaining pods not set aside or discarded from above. + +If there were any missing metrics, the control plane recomputes the average more +conservatively, assuming those pods were consuming 100% of the desired +value in case of a scale down, and 0% in case of a scale up. This dampens +the magnitude of any potential scale. + +Furthermore, if any not-yet-ready pods were present, and the workload would have +scaled up without factoring in missing metrics or not-yet-ready pods, +the controller conservatively assumes that the not-yet-ready pods are consuming 0% +of the desired metric, further dampening the magnitude of a scale up. + +After factoring in the not-yet-ready pods and missing metrics, the +controller recalculates the usage ratio. If the new ratio reverses the scale +direction, or is within the tolerance, the controller doesn't take any scaling +action. In other cases, the new ratio is used to decide any change to the +number of Pods. + +Note that the _original_ value for the average utilization is reported +back via the HorizontalPodAutoscaler status, without factoring in the +not-yet-ready pods or missing metrics, even when the new usage ratio is +used. + +If multiple metrics are specified in a HorizontalPodAutoscaler, this +calculation is done for each metric, and then the largest of the desired +replica counts is chosen. If any of these metrics cannot be converted +into a desired replica count (e.g. due to an error fetching the metrics +from the metrics APIs) and a scale down is suggested by the metrics which +can be fetched, scaling is skipped. This means that the HPA is still capable +of scaling up if one or more metrics give a `desiredReplicas` greater than +the current value. + +Finally, right before HPA scales the target, the scale recommendation is recorded. The +controller considers all recommendations within a configurable window choosing the +highest recommendation from within that window. This value can be configured using the +`--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes. +This means that scaledowns will occur gradually, smoothing out the impact of rapidly +fluctuating metric values. + +## API Object + +The Horizontal Pod Autoscaler is an API resource in the Kubernetes +`autoscaling` API group. The current stable version can be found in +the `autoscaling/v2` API version which includes support for scaling on +memory and custom metrics. The new fields introduced in +`autoscaling/v2` are preserved as annotations when working with +`autoscaling/v1`. + +When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +More details about the API object can be found at +[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling). + +## Stability of workload scale {#flapping} + +When managing the scale of a group of replicas using the HorizontalPodAutoscaler, +it is possible that the number of replicas keeps fluctuating frequently due to the +dynamic nature of the metrics evaluated. This is sometimes referred to as _thrashing_, +or _flapping_. It's similar to the concept of _hysteresis_ in cybernetics. + +## Autoscaling during rolling update + +Kubernetes lets you perform a rolling update on a Deployment. In that +case, the Deployment manages the underlying ReplicaSets for you. +When you configure autoscaling for a Deployment, you bind a +HorizontalPodAutoscaler to a single Deployment. The HorizontalPodAutoscaler +manages the `replicas` field of the Deployment. The deployment controller is responsible +for setting the `replicas` of the underlying ReplicaSets so that they add up to a suitable +number during the rollout and also afterwards. + +If you perform a rolling update of a StatefulSet that has an autoscaled number of +replicas, the StatefulSet directly manages its set of Pods (there is no intermediate resource +similar to ReplicaSet). + +## Support for resource metrics + +Any HPA target can be scaled based on the resource usage of the pods in the scaling target. +When defining the pod specification the resource requests like `cpu` and `memory` should +be specified. This is used to determine the resource utilization and used by the HPA controller +to scale the target up or down. To use resource utilization based scaling specify a metric source +like this: + +```yaml +type: Resource +resource: + name: cpu + target: + type: Utilization + averageUtilization: 60 +``` +With this metric the HPA controller will keep the average utilization of the pods in the scaling +target at 60%. Utilization is the ratio between the current usage of resource to the requested +resources of the pod. See [Algorithm](#algorithm-details) for more details about how the utilization +is calculated and averaged. + +{{< note >}} +Since the resource usages of all the containers are summed up the total pod utilization may not +accurately represent the individual container resource usage. This could lead to situations where +a single container might be running with high usage and the HPA will not scale out because the overall +pod usage is still within acceptable limits. +{{< /note >}} + +### Container resource metrics + +{{< feature-state for_k8s_version="v1.27" state="beta" >}} + +The HorizontalPodAutoscaler API also supports a container metric source where the HPA can track the +resource usage of individual containers across a set of Pods, in order to scale the target resource. +This lets you configure scaling thresholds for the containers that matter most in a particular Pod. +For example, if you have a web application and a logging sidecar, you can scale based on the resource +use of the web application, ignoring the sidecar container and its resource use. + +If you revise the target resource to have a new Pod specification with a different set of containers, +you should revise the HPA spec if that newly added container should also be used for +scaling. If the specified container in the metric source is not present or only present in a subset +of the pods then those pods are ignored and the recommendation is recalculated. See [Algorithm](#algorithm-details) +for more details about the calculation. To use container resources for autoscaling define a metric +source as follows: + +```yaml +type: ContainerResource +containerResource: + name: cpu + container: application + target: + type: Utilization + averageUtilization: 60 +``` + +In the above example the HPA controller scales the target such that the average utilization of the cpu +in the `application` container of all the pods is 60%. + +{{< note >}} +If you change the name of a container that a HorizontalPodAutoscaler is tracking, you can +make that change in a specific order to ensure scaling remains available and effective +whilst the change is being applied. Before you update the resource that defines the container +(such as a Deployment), you should update the associated HPA to track both the new and +old container names. This way, the HPA is able to calculate a scaling recommendation +throughout the update process. + +Once you have rolled out the container name change to the workload resource, tidy up by removing +the old container name from the HPA specification. +{{< /note >}} + +## Scaling on custom metrics + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature) + +Provided that you use the `autoscaling/v2` API version, you can configure a HorizontalPodAutoscaler +to scale based on a custom metric (that is not built in to Kubernetes or any Kubernetes component). +The HorizontalPodAutoscaler controller then queries for these custom metrics from the Kubernetes +API. + +See [Support for metrics APIs](#support-for-metrics-apis) for the requirements. + +## Scaling on multiple metrics + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature) + +Provided that you use the `autoscaling/v2` API version, you can specify multiple metrics for a +HorizontalPodAutoscaler to scale on. Then, the HorizontalPodAutoscaler controller evaluates each metric, +and proposes a new scale based on that metric. The HorizontalPodAutoscaler takes the maximum scale +recommended for each metric and sets the workload to that size (provided that this isn't larger than the +overall maximum that you configured). + +## Support for metrics APIs + +By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs. +In order for it to access these APIs, cluster administrators must ensure that: + +- The [API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) is enabled. + +- The corresponding APIs are registered: + + - For resource metrics, this is the `metrics.k8s.io` [API](/docs/reference/external-api/metrics.v1beta1/), + generally provided by [metrics-server](https://github.com/kubernetes-sigs/metrics-server). + It can be launched as a cluster add-on. + + - For custom metrics, this is the `custom.metrics.k8s.io` [API](/docs/reference/external-api/custom-metrics.v1beta2/). + It's provided by "adapter" API servers provided by metrics solution vendors. + Check with your metrics pipeline to see if there is a Kubernetes metrics adapter available. + + - For external metrics, this is the `external.metrics.k8s.io` [API](/docs/reference/external-api/external-metrics.v1beta1/). + It may be provided by the custom metrics adapters provided above. + +For more information on these different metrics paths and how they differ please see the relevant design proposals for +[the HPA V2](https://git.k8s.io/design-proposals-archive/autoscaling/hpa-v2.md), +[custom.metrics.k8s.io](https://git.k8s.io/design-proposals-archive/instrumentation/custom-metrics-api.md) +and [external.metrics.k8s.io](https://git.k8s.io/design-proposals-archive/instrumentation/external-metrics-api.md). + +For examples of how to use them see +[the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics) +and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects). + +## Configurable scaling behavior + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature) + +If you use the `v2` HorizontalPodAutoscaler API, you can use the `behavior` field +(see the [API reference](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec)) +to configure separate scale-up and scale-down behaviors. +You specify these behaviours by setting `scaleUp` and / or `scaleDown` +under the `behavior` field. + +You can specify a _stabilization window_ that prevents [flapping](#flapping) +the replica count for a scaling target. Scaling policies also let you control the +rate of change of replicas while scaling. + +### Scaling policies + +One or more scaling policies can be specified in the `behavior` section of the spec. +When multiple policies are specified the policy which allows the highest amount of +change is the policy which is selected by default. The following example shows this behavior +while scaling down: + +```yaml +behavior: + scaleDown: + policies: + - type: Pods + value: 4 + periodSeconds: 60 + - type: Percent + value: 10 + periodSeconds: 60 +``` + +`periodSeconds` indicates the length of time in the past for which the policy must hold true. +The maximum value that you can set for `periodSeconds` is 1800 (half an hour). +The first policy _(Pods)_ allows at most 4 replicas to be scaled down in one minute. The second policy +_(Percent)_ allows at most 10% of the current replicas to be scaled down in one minute. + +Since by default the policy which allows the highest amount of change is selected, the second policy will +only be used when the number of pod replicas is more than 40. With 40 or less replicas, the first policy will be applied. +For instance if there are 80 replicas and the target has to be scaled down to 10 replicas +then during the first step 8 replicas will be reduced. In the next iteration when the number +of replicas is 72, 10% of the pods is 7.2 but the number is rounded up to 8. On each loop of +the autoscaler controller the number of pods to be change is re-calculated based on the number +of current replicas. When the number of replicas falls below 40 the first policy _(Pods)_ is applied +and 4 replicas will be reduced at a time. + +The policy selection can be changed by specifying the `selectPolicy` field for a scaling +direction. By setting the value to `Min` which would select the policy which allows the +smallest change in the replica count. Setting the value to `Disabled` completely disables +scaling in that direction. + +### Stabilization window + +The stabilization window is used to restrict the [flapping](#flapping) of +replica count when the metrics used for scaling keep fluctuating. The autoscaling algorithm +uses this window to infer a previous desired state and avoid unwanted changes to workload +scale. + +For example, in the following example snippet, a stabilization window is specified for `scaleDown`. + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 300 +``` + +When the metrics indicate that the target should be scaled down the algorithm looks +into previously computed desired states, and uses the highest value from the specified +interval. In the above example, all desired states from the past 5 minutes will be considered. + +This approximates a rolling maximum, and avoids having the scaling algorithm frequently +remove Pods only to trigger recreating an equivalent Pod just moments later. + +### Default Behavior + +To use the custom scaling not all fields have to be specified. Only values which need to be +customized can be specified. These custom values are merged with default values. The default values +match the existing behavior in the HPA algorithm. + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 300 + policies: + - type: Percent + value: 100 + periodSeconds: 15 + scaleUp: + stabilizationWindowSeconds: 0 + policies: + - type: Percent + value: 100 + periodSeconds: 15 + - type: Pods + value: 4 + periodSeconds: 15 + selectPolicy: Max +``` +For scaling down the stabilization window is _300_ seconds (or the value of the +`--horizontal-pod-autoscaler-downscale-stabilization` flag if provided). There is only a single policy +for scaling down which allows a 100% of the currently running replicas to be removed which +means the scaling target can be scaled down to the minimum allowed replicas. +For scaling up there is no stabilization window. When the metrics indicate that the target should be +scaled up the target is scaled up immediately. There are 2 policies where 4 pods or a 100% of the currently +running replicas may at most be added every 15 seconds till the HPA reaches its steady state. + +### Example: change downscale stabilization window + +To provide a custom downscale stabilization window of 1 minute, the following +behavior would be added to the HPA: + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 60 +``` + +### Example: limit scale down rate + +To limit the rate at which pods are removed by the HPA to 10% per minute, the +following behavior would be added to the HPA: + +```yaml +behavior: + scaleDown: + policies: + - type: Percent + value: 10 + periodSeconds: 60 +``` + +To ensure that no more than 5 Pods are removed per minute, you can add a second scale-down +policy with a fixed size of 5, and set `selectPolicy` to minimum. Setting `selectPolicy` to `Min` means +that the autoscaler chooses the policy that affects the smallest number of Pods: + +```yaml +behavior: + scaleDown: + policies: + - type: Percent + value: 10 + periodSeconds: 60 + - type: Pods + value: 5 + periodSeconds: 60 + selectPolicy: Min +``` + +### Example: disable scale down + +The `selectPolicy` value of `Disabled` turns off scaling the given direction. +So to prevent downscaling the following policy would be used: + +```yaml +behavior: + scaleDown: + selectPolicy: Disabled +``` + +## Support for HorizontalPodAutoscaler in kubectl + +HorizontalPodAutoscaler, like every API resource, is supported in a standard way by `kubectl`. +You can create a new autoscaler using `kubectl create` command. +You can list autoscalers by `kubectl get hpa` or get detailed description by `kubectl describe hpa`. +Finally, you can delete an autoscaler using `kubectl delete hpa`. + +In addition, there is a special `kubectl autoscale` command for creating a HorizontalPodAutoscaler object. +For instance, executing `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` +will create an autoscaler for ReplicaSet _foo_, with target CPU utilization set to `80%` +and the number of replicas between 2 and 5. + +## Implicit maintenance-mode deactivation + +You can implicitly deactivate the HPA for a target without the +need to change the HPA configuration itself. If the target's desired replica count +is set to 0, and the HPA's minimum replica count is greater than 0, the HPA +stops adjusting the target (and sets the `ScalingActive` Condition on itself +to `false`) until you reactivate it by manually adjusting the target's desired +replica count or HPA's minimum replica count. + +### Migrating Deployments and StatefulSets to horizontal autoscaling + +When an HPA is enabled, it is recommended that the value of `spec.replicas` of +the Deployment and / or StatefulSet be removed from their +{{< glossary_tooltip text="manifest(s)" term_id="manifest" >}}. If this isn't done, any time +a change to that object is applied, for example via `kubectl apply -f +deployment.yaml`, this will instruct Kubernetes to scale the current number of Pods +to the value of the `spec.replicas` key. This may not be +desired and could be troublesome when an HPA is active. + +Keep in mind that the removal of `spec.replicas` may incur a one-time +degradation of Pod counts as the default value of this key is 1 (reference +[Deployment Replicas](/docs/concepts/workloads/controllers/deployment#replicas)). +Upon the update, all Pods except 1 will begin their termination procedures. Any +deployment application afterwards will behave as normal and respect a rolling +update configuration as desired. You can avoid this degradation by choosing one of the following two +methods based on how you are modifying your deployments: + +{{< tabs name="fix_replicas_instructions" >}} +{{% tab name="Client Side Apply (this is the default)" %}} + +1. `kubectl apply edit-last-applied deployment/` +2. In the editor, remove `spec.replicas`. When you save and exit the editor, `kubectl` + applies the update. No changes to Pod counts happen at this step. +3. You can now remove `spec.replicas` from the manifest. If you use source code management, + also commit your changes or take whatever other steps for revising the source code + are appropriate for how you track updates. +4. From here on out you can run `kubectl apply -f deployment.yaml` + +{{% /tab %}} +{{% tab name="Server Side Apply" %}} + +When using the [Server-Side Apply](/docs/reference/using-api/server-side-apply/) +you can follow the [transferring ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership) +guidelines, which cover this exact use case. + +{{% /tab %}} +{{< /tabs >}} + +## {{% heading "whatsnext" %}} + +If you configure autoscaling in your cluster, you may also want to consider running a +cluster-level autoscaler such as [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler). + +For more information on HorizontalPodAutoscaler: + +- Read a [walkthrough example](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for horizontal pod autoscaling. +- Read documentation for [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). +- If you would like to write your own custom metrics adapter, check out the + [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) to get started. +- Read the [API reference](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/) for HorizontalPodAutoscaler. diff --git a/content/uk/docs/tasks/tls/_index.md b/content/uk/docs/tasks/tls/_index.md new file mode 100644 index 0000000000000..268cb79b10942 --- /dev/null +++ b/content/uk/docs/tasks/tls/_index.md @@ -0,0 +1,5 @@ +--- +title: TLS +weight: 120 +description: Дізнайтесь, як захистити трафік у вашому кластері за допомогою TLS (Transport Layer Security). +--- diff --git a/content/uk/docs/tasks/tools/_index.md b/content/uk/docs/tasks/tools/_index.md new file mode 100644 index 0000000000000..0c455a1d823cf --- /dev/null +++ b/content/uk/docs/tasks/tools/_index.md @@ -0,0 +1,50 @@ +--- +title: "Встановлення інструментів" +description: Встановлення інструментів Kubernetes на ваш компʼютер. +weight: 10 +no_list: true +card: + name: tasks + weight: 20 + anchors: + - anchor: "#kubectl" + title: Встановлення kubectl +--- + +## kubectl + + +Інструмент командного рядка Kubernetes, [kubectl](/docs/reference/kubectl/kubectl/), дозволяє вам виконувати команди відносно кластерів Kubernetes. Ви можете використовувати kubectl для розгортання застосунків, огляду та управління ресурсами кластера, +а також перегляду логів. Для отримання додаткової інформації, включаючи повний перелік операцій kubectl, див. [Документацію з посилань на `kubectl`](/docs/reference/kubectl/). + +kubectl можна встановити на різноманітних платформах Linux, macOS та Windows. Знайдіть свою вибрану операційну систему нижче. + +- [Встановлення kubectl на Linux](/docs/tasks/tools/install-kubectl-linux) +- [Встановлення kubectl на macOS](/docs/tasks/tools/install-kubectl-macos) +- [Встановлення kubectl на Windows](/docs/tasks/tools/install-kubectl-windows) + +## kind + +[`kind`](https://kind.sigs.k8s.io/) дозволяє вам запускати Kubernetes на вашому локальному компʼютері. Цей інструмент вимагає встановлення або [Docker](https://www.docker.com/), або [Podman](https://podman.io/). + +На сторінці [Швидкий старт з kind](https://kind.sigs.k8s.io/docs/user/quick-start/) показано, що вам потрібно зробити, щоб розпочати роботу з kind. + +Переглянути посібник Швидкий старт з kind + +## minikube + +Подібно до `kind`, [`minikube`](https://minikube.sigs.k8s.io/) — це інструмент, який дозволяє вам запускати Kubernetes локально. `minikube` запускає одно- або багатовузловий локальний кластер Kubernetes на вашому персональному компʼютері (включаючи ПК з операційними системами Windows, macOS і Linux), так щоб ви могли випробувати Kubernetes або використовувати його для щоденної розробки. + +Якщо ваша основна мета — встановлення інструменту, ви можете скористатися офіційним посібником [Швидкий старт](https://minikube.sigs.k8s.io/docs/start/). + +Переглянути посібник Швидкий старт з Minikube + +Якщо у вас вже працює `minikube`, ви можете використовувати його для [запуску застосунку-прикладу](/docs/tutorials/hello-minikube/). + +## kubeadm + +Ви можете використовувати інструмент {{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} для створення та управління кластерами Kubernetes. Він виконує необхідні дії для запуску мінімально життєздатного та захищеного кластера за допомогою зручного інтерфейсу користувача. + +На сторінці [Встановлення kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) показано, як встановити kubeadm. Після встановлення ви можете використовувати його для [створення кластера](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). + +Переглянути посібник з встановлення kubeadm diff --git a/content/uk/docs/tasks/tools/install-minikube.md b/content/uk/docs/tasks/tools/install-minikube.md deleted file mode 100644 index 497f6e6aa602b..0000000000000 --- a/content/uk/docs/tasks/tools/install-minikube.md +++ /dev/null @@ -1,264 +0,0 @@ ---- -title: Встановлення Minikube -content_template: task -weight: 20 -card: - name: tasks - weight: 10 ---- - - - - - -Ця сторінка описує, як встановити [Minikube](/docs/tutorials/hello-minikube) - інструмент, який дозволяє -запустити Kubernetes кластер з однієї ноди у віртуальній машині на вашому персональному комп'ютері. - - -## {{% heading "prerequisites" %}} - -{{< tabs name="minikube_before_you_begin" >}} -{{% tab name="Linux" %}} -Для перевірки, чи підтримується віртуалізація на Linux, запустіть наступну команду і впевніться що її вивід не пустий: -``` -grep -E --color 'vmx|svm' /proc/cpuinfo -``` -{{% /tab %}} - -{{% tab name="macOS" %}} -Для перевірки, чи підтримується віртуалізація на macOS, запустіть наступну команду в терміналі. -``` -sysctl -a | grep -E --color 'machdep.cpu.features|VMX' -``` -Якщо ви бачите `VMX` у виводі (має бути кольоровий), то VT-x опція включена на вашому хості. -{{% /tab %}} - -{{% tab name="Windows" %}} -Для перевірки, чи підтримується віртуалізація на Windows 8 та версіях вище, запустіть наступну команду в терміналі -вашого або через command prompt. -``` -systeminfo -``` -Якщо ви бачите наступне, віртуалізація підтримується на Windows. -``` -Hyper-V Requirements: VM Monitor Mode Extensions: Yes - Virtualization Enabled In Firmware: Yes - Second Level Address Translation: Yes - Data Execution Prevention Available: Yes -``` - -Якщо ви бачите наступнний вивід, на вашій системі вже встановлен гіпервізор і ви можете пропустити наступний крок. -``` -Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed. -``` - - -{{% /tab %}} -{{< /tabs >}} - - - - - -# Встановлення Minikube - -{{< tabs name="tab_with_md" >}} -{{% tab name="Linux" %}} - -### Встановлення kubectl - -Впевніться що kubectl встановлений. Ви можете встановити kubectl згідно інструкції [Встановлення та налаштування kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux). - -### Встановлення Hypervisor - -Якщо у вас немає встановленого гіпервізора, то встановіть один з наступних: - -• [KVM](https://www.linux-kvm.org/), який також використовує QEMU - -• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) - -Minikube також пітримує опцію `--driver=none` яка дозволяє запускати компоненти Kubernetes -на хост системі, ні в віртуальній машині. -Використання цього драйвера вимагає [Docker](https://www.docker.com/products/docker-desktop) та Linux оточення але не гіпервізор. - -Якщо ви використувуєте `none` драйвер у Debian або похідних дістрибутивах, використовуйте `.deb` пакети для -Docker замість встановлення snap пакетів, які не працюють з Minikube. -Ви можете скачати `.deb` пакети звідси [Docker](https://www.docker.com/products/docker-desktop). - -{{< caution >}} -`none` VM драйвер може привести до проблем з безпекою та втрати даних. -Перед тим, як використовувати `--driver=none`, ознайомтесь [з цієй документацієй](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) для отримання додаткової інформації. -{{< /caution >}} - -Minikube також підтримує `vm-driver=podman` схожий на Docker драйвер. Podman запущений як суперюзер (root user) це найкрайщий шлях забезпечити повний доступ ваших контейнерів до будь-якої функції, наявної у вашій системі. - -{{< caution >}} -`podman` драйвер вимагає запущені контейнери з під root користувача оскільки звичайні облікові записи користувачів не мають повного доступу до всіх функцій операційної системи, які, можливо, потребуватимуть їх роботи. -{{< /caution >}} - -### Встановлення Minikube як Linux пакет - -Доступні *experimental* пакети для Minikube; ви можете знайти Linux (AMD64) пакети -для Minikube's [releases](https://github.com/kubernetes/minikube/releases) на сторінці GitHub. - -Використовувайте ваш Linux інсталер пакетів для того, шоб поставити відповідний пакет. - -### Встановлення Minikube за допомогою прямого завантаження - -Якщо ви не можете встановити Minikube за допомогою пакета, ви можете скачати автономний бінарний файл, -та використати його. - -```shell -curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \ - && chmod +x minikube -``` - -Ось простий спосіб додати виконуваний файл Minikube до вашого шляху: - -```shell -sudo mkdir -p /usr/local/bin/ -sudo install minikube /usr/local/bin/ -``` - -### Встановлення Minikube використовуючи Homebrew - -Як альтернативний варіант, ви можете установити Minikube використовуючи Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux): - -```shell -brew install minikube -``` - -{{% /tab %}} -{{% tab name="macOS" %}} -### Встановлення kubectl - -Впевніться шо kubectl встановлен. Ви можете встановити kubectl згідно інструкції [Установка та налаштування kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos). - -### Встановлення Hypervisor - -Якщо у вас немає встановленого гіпервізора, то встановіть один з наступних: - -• [HyperKit](https://github.com/moby/hyperkit) - -• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) - -• [VMware Fusion](https://www.vmware.com/products/fusion) - -### Встановлення Minikube -Найпростіший спосіб встановити Minikube на macOS це використати [Homebrew](https://brew.sh): - -```shell -brew install minikube -``` - -Ви також можете встановити Minikube за допомогою автономного бінарного файла: - -```shell -curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \ - && chmod +x minikube -``` - -Ось простий спосіб додати виконуваний файл Minikube до вашого шляху: - -```shell -sudo mv minikube /usr/local/bin -``` - -{{% /tab %}} -{{% tab name="Windows" %}} -### Встановлення kubectl - -Впевніться шо kubectl встановлен. Ви можете встановити kubectl згідно інструкції [Установка та налаштування kubectl](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows). - -### Встановлення Hypervisor - -Якщо у вас немає встановленого гіпервізора, то встановіть один з наступних: - -• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install) - -• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) - -{{< note >}} -Hyper-V може бути запущен на трьох версіях Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education. -{{< /note >}} - -### Встановлення Minikube за допомогою Chocolatey - -Найпростіший спосіб встановити Minikube на Windows за допомогою [Chocolatey](https://chocolatey.org/) (run as an administrator): - -```shell -choco install minikube -``` - -Коли Minikube закінчив установку, закрийте поточну CLI сесію та перезавантажтесь. Minikube має бути додан до вашого шляху автоматично. - -### Встановлення Minikube за допомогою програми встановлення - -Для встановлення Minikube вручну на Windows за допомогою [Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal), скачайте [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe) та виконайте програму. - -### Встановлення Minikube за допомогою прямого завантаження - -Для встановлення Minikube вручну на Windows, скачайте [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest), перейменуйте в `minikube.exe`, та додайте до вашего шляху. - -{{% /tab %}} -{{< /tabs >}} - - - -## {{% heading "whatsnext" %}} - -* [Запуск Kubernetes локально за допомогою Minikube](/docs/setup/learning-environment/minikube/) - - -## Підтвердження встановлення - -Щоб підтвердити успішну установку як гіпервізора, так і Minikube, ви можете запустити таку команду, щоб запустити локальний кластер Kubernetes: - -{{< note >}} - -Щоб встановити `--driver` за допомогою` minikube start`, введіть ім'я гіпервізора, який ви встановили, малими літерами, де `` згадано нижче. Повний список значень `--driver` доступний у [вказуванні документації на драйвер VM](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver). - -{{< /note >}} - -```shell -minikube start --driver= -``` - -Після того як `minikube start` закінчився, запустіть команду нижче, щоб перевірити стан кластера: - -```shell -minikube status -``` -Якщо ваш кластер працює, вивід із "minikube status" має бути аналогічним: - -``` -host: Running -kubelet: Running -apiserver: Running -kubeconfig: Configured -``` - -Після того, як ви підтвердили, чи Minikube працює з обраним вами гіпервізором, ви можете продовжувати використовувати Minikube або ви можете зупинити кластер. Щоб зупинити кластер, запустіть: - -```shell -minikube stop -``` - -## Очистити локальний стан {#cleanup-local-state} - -Якщо ви раніше встановили Minikube та запустили: -```shell -minikube start -``` - -але `minikube start` повертає помилку: -``` -machine does not exist -``` - -тоді вам треба очистити локальний стан minikube: -```shell -minikube delete -``` diff --git a/content/uk/docs/tutorials/_index.md b/content/uk/docs/tutorials/_index.md index 7f8e0024403bc..dd0e3d13011f5 100644 --- a/content/uk/docs/tutorials/_index.md +++ b/content/uk/docs/tutorials/_index.md @@ -1,72 +1,52 @@ --- -#title: Tutorials -title: Навчальні матеріали -main_menu: true +title: Посібники +linkTitle: Посібники +no_list: true weight: 60 -content_type: concept +сontent_type: concept --- - -У цьому розділі документації Kubernetes зібрані навчальні матеріали. Кожний матеріал показує, як досягти окремої мети, що більша за одне [завдання](/docs/tasks/). Зазвичай навчальний матеріал має декілька розділів, кожен з яких містить певну послідовність дій. До ознайомлення з навчальними матеріалами вам, можливо, знадобиться додати у закладки сторінку з [Глосарієм](/docs/reference/glossary/) для подальшого консультування. - - +Цей розділ документації Kubernetes містить посібники. Посібник показує, як досягти мети, яка більша за одне [завдання](/docs/tasks/). Зазвичай посібник має кілька розділів, кожен з яких має послідовність кроків. Перед тим, як пройти кожен посібник, ви можете додати [сторінку глосарія](/docs/reference/glossary/) до закладок для подальших посилань. - -## Основи +## Основи {#basics} - -* [Основи Kubernetes](/docs/tutorials/kubernetes-basics/) - детальний навчальний матеріал з інтерактивними уроками, що допоможе вам зрозуміти Kubernetes і спробувати його базову функціональність. -* [Масштабовані мікросервіси з Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) +* [Основи Kubernetes](/docs/tutorials/kubernetes-basics/) — це поглиблений інтерактивний посібник, який допомагає зрозуміти систему Kubernetes та спробувати деякі основні функції Kubernetes. * [Вступ до Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) * [Привіт Minikube](/docs/tutorials/hello-minikube/) - -## Конфігурація +## Налаштування {#configuration} -* [Приклад: Конфігурування Java мікросервісу](/docs/tutorials/configuration/configure-java-microservice/) -* [Конфігурування Redis використовуючи ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) +* [Приклад: Налаштування Java-мікросервісу](/docs/tutorials/configuration/configure-java-microservice/) +* [Налаштування Redis за допомогою ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) -## Застосунки без стану (Stateless Applications) {#застосунки-без-стану} +## Stateless-застосунки {#stateless-applications} -* [Відкриття зовнішньої IP-адреси для доступу до програми в кластері](/docs/tutorials/stateless-application/expose-external-ip-address/) +* [Вивід зовнішньої IP-адреси для доступу до застосунку в кластері](/docs/tutorials/stateless-application/expose-external-ip-address/) * [Приклад: Розгортання застосунку PHP Guestbook з Redis](/docs/tutorials/stateless-application/guestbook/) -## Застосунки зі станом (Stateful Applications) {#застосунки-зі-станом} +## Stateful-застосунки {#stateful-applications * [Основи StatefulSet](/docs/tutorials/stateful-application/basic-stateful-set/) -* [Приклад: WordPress та MySQL із постійними томами](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) -* [Приклад: Розгортання Cassandra зі Stateful Sets](/docs/tutorials/stateful-application/cassandra/) -* [Запуск ZooKeeper, координатора розподіленої системи](/docs/tutorials/stateful-application/zookeeper/) +* [Приклад: WordPress та MySQL з постійними томами](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) +* [Приклад: Розгортання Cassandra з Stateful Sets](/docs/tutorials/stateful-application/cassandra/) +* [Запуск ZooKeeper, розподіленої системи CP](/docs/tutorials/stateful-application/zookeeper/) -## Кластери +## Сервіси (Services) {#services} -* [AppArmor](/docs/tutorials/clusters/apparmor/) -* [Seccomp](/docs/tutorials/clusters/seccomp/) +* [Підключення застосунків за допомогою сервісів](/docs/tutorials/services/connect-applications-service/) +* [Використання IP-адреси джерела](/docs/tutorials/services/source-ip/) -## Сервіси +## Безпека {#security} -* [Використання Source IP](/docs/tutorials/services/source-ip/) +* [Застосування стандартів безпеки Pod на рівні кластера](/docs/tutorials/security/cluster-level-pss/) +* [Застосування стандартів безпеки Pod на рівні простору імен (namespace)](/docs/tutorials/security/ns-level-pss/) +* [AppArmor](/docs/tutorials/security/apparmor/) +* [Seccomp](/docs/tutorials/security/seccomp/) ## {{% heading "whatsnext" %}} - - -Якщо ви хочете написати навчальний матеріал, у статті -[Використання шаблонів сторінок](/docs/home/contribute/page-templates/) -ви знайдете інформацію про тип навчальної сторінки і шаблон. +Якщо ви хочете написати посібник, див. [Типи сторінок](/docs/contribute/style/page-content-types/) для отримання інформації про типи сторінок посібника. diff --git a/content/uk/docs/tutorials/configuration/_index.md b/content/uk/docs/tutorials/configuration/_index.md new file mode 100644 index 0000000000000..67c873a334ec5 --- /dev/null +++ b/content/uk/docs/tutorials/configuration/_index.md @@ -0,0 +1,4 @@ +--- +title: "Налаштування" +weight: 30 +--- \ No newline at end of file diff --git a/content/uk/docs/tutorials/hello-minikube.md b/content/uk/docs/tutorials/hello-minikube.md index 7d27b34bde86a..9061e5bed321e 100644 --- a/content/uk/docs/tutorials/hello-minikube.md +++ b/content/uk/docs/tutorials/hello-minikube.md @@ -1,397 +1,318 @@ --- -#title: Hello Minikube title: Привіт Minikube content_type: tutorial weight: 5 menu: main: - #title: "Get Started" - title: "Початок роботи" + title: "Розпочнемо" weight: 10 - #post: > - #

Ready to get your hands dirty? Build a simple Kubernetes cluster that runs "Hello World" for Node.js.

post: > -

Готові попрацювати? Створимо простий Kubernetes кластер для запуску Node.js застосунку "Hello World".

-card: - #name: tutorials - name: навчальні матеріали +

Готові забруднити руки? Побудуйте простий кластер Kubernetes, який запускає тестовий застосунок.

+card: + name: tutorials weight: 10 --- - -З цього навчального матеріалу ви дізнаєтесь, як запустити у Kubernetes простий Hello World застосунок на Node.js за допомогою [Minikube](/docs/setup/learning-environment/minikube) і Katacoda. Katacoda надає безплатне Kubernetes середовище, що доступне у вашому браузері. +Цей посібник покаже вам, як запустити простий кластер Kubernetes використовуючи minikube. Посібник надає образ контейнера, який використовує NGINX для відклику на всі запити. - +## {{% heading "objectives" %}} + +* Розгортання тестового застосунку в minikube. +* Запуск застосунку. +* Перегляд логів застосунку. + +## {{% heading "prerequisites" %}} + +Цей застосунок передбачає, що у вас вже є встановлений `minikube`. Дивіться __Крок 1__ в [minikube start](https://minikube.sigs.k8s.io/docs/start/) для інструкцій щодо встановлення. {{< note >}} -Також ви можете навчатись за цим матеріалом, якщо встановили [Minikube локально](/docs/tasks/tools/install-minikube/). +Виконайте лише інструкції з __Кроку 1, Встановлення__. Решту розглянуто на цій сторінці. {{< /note >}} +Вам також потрібно встановити `kubectl`. Дивіться [Встановлення інструментів](/docs/tasks/tools/#kubectl) для інструкцій щодо встановлення. + -## {{% heading "objectives" %}} +## Створення кластера minikube {#create-minikube-cluster} + +```shell +minikube start +``` +## Відкрийте інформаційну панель {#open-dashboard} - -* Розгорнути Hello World застосунок у Minikube. - -* Запустити застосунок. - -* Переглянути логи застосунку. +Відкрийте інформаційну панель Kubernetes. Це можна зробити двома різними способами: +{{< tabs name="dashboard" >}} +{{% tab name="Запустіть оглядач" %}} +Відкрийте __новий__ термінал та виконайте команду: +```shell +# Запустіть новий термінал та залиште його працювати. +minikube dashboard +``` -## {{% heading "prerequisites" %}} +Тепер поверніться до термінала, де ви запустили `minikube start`. + +{{< note >}} +Команда `dashboard` вмикає додаток інформаційної панелі та відкриває проксі для типового системного вебоглядача. Ви можете створювати ресурси Kubernetes на інформаційній панелі, такі як Deployment та Service. +Щоб дізнатися, як уникнути прямого запуску вебоглядача з термінала та отримати URL-адресу для вебінтерфейсу, дивіться вкладку «Копіювання та вставлення URL-адреси». - -У цьому навчальному матеріалі ми використовуємо образ контейнера, зібраний із наступних файлів: +Стандартно, інформаційна панель доступна лише з внутрішньої віртуальної мережі Kubernetes. Команда `dashboard` створює тимчасовий проксі, щоб інформаційна панель була доступна за межами віртуальної мережі Kubernetes. -{{% codenew language="js" file="minikube/server.js" %}} +Щоб зупинити проксі, натисніть `Ctrl+C`, щоб вийти з процесу. Після виходу з команди інформаційна панель залишається запущеною в кластері Kubernetes. Ви можете знову запустити команду `dashboard`, щоб створити інший проксі для доступу до інформаційної панелі. +{{< /note >}} -{{% codenew language="conf" file="minikube/Dockerfile" %}} +{{% /tab %}} +{{% tab name="Копіювання та вставлення URL" %}} - -Більше інформації про команду `docker build` ви знайдете у [документації Docker](https://docs.docker.com/engine/reference/commandline/build/). +Якщо ви не хочете, щоб minikube відкривав вебоглядач для вас, запустіть підкоманду `dashboard` з прапорцем `--url`. `minikube` виводить URL-адресу, яку ви можете відкрити у вибраному вами вебоглядачі. +Відкрийте __новий__ термінал та виконайте команду: +```shell +# Запустіть новий термінал та залиште його працювати. +minikube dashboard --url +``` - +Тепер поверніться до терміналу, де ви запустили `minikube start`. - -## Створення Minikube кластера - - -1. Натисніть кнопку **Запуск термінала** - - {{< kat-button >}} - - - {{< note >}}Якщо Minikube встановлений локально, виконайте команду `minikube start`.{{< /note >}} - - -2. Відкрийте Kubernetes дашборд у браузері: - - ```shell - minikube dashboard - ``` - - -3. Тільки для Katacoda: у верхній частині вікна термінала натисніть знак плюс, а потім -- **Select port to view on Host 1**. - - -4. Тільки для Katacoda: введіть `30000`, а потім натисніть **Display Port**. - - -## Створення Deployment - - -[*Pod*](/docs/concepts/workloads/pods/pod/) у Kubernetes -- це група з одного або декількох контейнерів, що об'єднані разом з метою адміністрування і роботи у мережі. У цьому навчальному матеріалі Pod має лише один контейнер. Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) перевіряє стан Pod'а і перезапускає контейнер Pod'а, якщо контейнер перестає працювати. Створювати і масштабувати Pod'и рекомендується за допомогою Deployment'ів. - - -1. За допомогою команди `kubectl create` створіть Deployment, який керуватиме Pod'ом. Pod запускає контейнер на основі наданого Docker образу. - - ```shell - kubectl create deployment hello-node --image=registry.k8s.io/echoserver:1.4 - ``` - - -2. Перегляньте інформацію про запущений Deployment: - - ```shell - kubectl get deployments - ``` - - - У виводі ви побачите подібну інформацію: - - ``` - NAME READY UP-TO-DATE AVAILABLE AGE - hello-node 1/1 1 1 1m - ``` - - -3. Перегляньте інформацію про запущені Pod'и: - - ```shell - kubectl get pods - ``` - - - У виводі ви побачите подібну інформацію: - - ``` - NAME READY STATUS RESTARTS AGE - hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m - ``` - - -4. Перегляньте події кластера: - - ```shell - kubectl get events - ``` - - -5. Перегляньте конфігурацію `kubectl`: - - ```shell - kubectl config view - ``` +{{% /tab %}} +{{< /tabs >}} + +## Створення Deployment {#create-deployment} + +[*Pod*](/docs/concepts/workloads/pods/) в Kubernetes — це група з одного або більше контейнерів, які повʼязуються один з одним для керування та використання мережевих ресурсів. Pod в цьому посібнику містить тільки один контейнер. Kubernetes [*Deployment*](/docs/concepts/workloads/controllers/deployment/) перевіряє життєздатність вашого Podʼу та, якщо він виходить з ладу, перезапускає його. Deployment є рекомендованим способом створення та масштабування Podʼів. + +1. Скористайтесь командою `kubectl create` для створення Deployment, що буде керувати Podʼом. Pod виконує контейнер, який міститься в образі Docker. - - {{< note >}}Більше про команди `kubectl` ви можете дізнатися зі статті [Загальна інформація про kubectl](/docs/user-guide/kubectl-overview/).{{< /note >}} - - -## Створення Service - - -За умовчанням, Pod доступний лише за внутрішньою IP-адресою у межах Kubernetes кластера. Для того, щоб контейнер `hello-node` став доступний за межами віртуальної мережі Kubernetes, Pod необхідно відкрити як Kubernetes [*Service*](/docs/concepts/services-networking/service/). - - -1. Відкрийте Pod для публічного доступу з інтернету за допомогою команди `kubectl expose`: - - ```shell - kubectl expose deployment hello-node --type=LoadBalancer --port=8080 - ``` - - - Прапорець `--type=LoadBalancer` вказує, що ви хочете відкрити доступ до Service за межами кластера. - - -2. Перегляньте інформацію про Service, який ви щойно створили: - - ```shell - kubectl get services - ``` - - - У виводі ви побачите подібну інформацію: - - ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - hello-node LoadBalancer 10.108.144.78 8080:30369/TCP 21s - kubernetes ClusterIP 10.96.0.1 443/TCP 23m - ``` - - - Для хмарних провайдерів, що підтримують балансування навантаження, доступ до Service надається через зовнішню IP-адресу. Для Minikube, тип `LoadBalancer` робить Service доступним ззовні за допомогою команди `minikube service`. - - -3. Виконайте наступну команду: - - ```shell - minikube service hello-node - ``` - - -4. Тільки для Katacoda: натисніть знак плюс, а потім -- **Select port to view on Host 1**. - - -5. Тільки для Katacoda: запишіть п'ятизначний номер порту, що відображається напроти `8080` у виводі сервісу. Номер цього порту генерується довільно і тому може бути іншим у вашому випадку. Введіть номер порту у призначене для цього текстове поле і натисніть Display Port. У нашому прикладі номер порту `30369`. - - - Це відкриє вікно браузера, в якому запущений ваш застосунок, і покаже повідомлення "Hello World". - - -## Увімкнення розширень - - -Minikube має ряд вбудованих {{< glossary_tooltip text="розширень" term_id="addons" >}}, які можна увімкнути, вимкнути і відкрити у локальному Kubernetes оточенні. - - -1. Перегляньте перелік підтримуваних розширень: - - ```shell - minikube addons list - ``` - - - У виводі ви побачите подібну інформацію: - - ``` - addon-manager: enabled - dashboard: enabled - default-storageclass: enabled - efk: disabled - freshpod: disabled - gvisor: disabled - helm-tiller: disabled - ingress: disabled - ingress-dns: disabled - logviewer: disabled - metrics-server: disabled - nvidia-driver-installer: disabled - nvidia-gpu-device-plugin: disabled - registry: disabled - registry-creds: disabled - storage-provisioner: enabled - storage-provisioner-gluster: disabled - ``` - - -2. Увімкніть розширення, наприклад `metrics-server`: - - ```shell - minikube addons enable metrics-server - ``` + ```shell + # Запустіть тестовий образ контейнера, який містить вебсервер + kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080 + ``` + +1. Перевірте, чи створено Deployment. + + ```shell + kubectl get deployments + ``` + + Ви маєте отримати вивід, подібний до такого: - - У виводі ви побачите подібну інформацію: - - ``` - metrics-server was successfully enabled - ``` - - -3. Перегляньте інформацію про Pod і Service, які ви щойно створили: - - ```shell - kubectl get pod,svc -n kube-system - ``` - - - У виводі ви побачите подібну інформацію: - - ``` - NAME READY STATUS RESTARTS AGE - pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m - pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m - pod/metrics-server-67fb648c5 1/1 Running 0 26s - pod/etcd-minikube 1/1 Running 0 34m - pod/influxdb-grafana-b29w8 2/2 Running 0 26s - pod/kube-addon-manager-minikube 1/1 Running 0 34m - pod/kube-apiserver-minikube 1/1 Running 0 34m - pod/kube-controller-manager-minikube 1/1 Running 0 34m - pod/kube-proxy-rnlps 1/1 Running 0 34m - pod/kube-scheduler-minikube 1/1 Running 0 34m - pod/storage-provisioner 1/1 Running 0 34m - - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - service/metrics-server ClusterIP 10.96.241.45 80/TCP 26s - service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m - service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s - service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s - ``` - - -4. Вимкніть `metrics-server`: - - ```shell - minikube addons disable metrics-server - ``` + ```output + NAME READY UP-TO-DATE AVAILABLE AGE + hello-node 1/1 1 1 1m + ``` + +1. Перевірте, чи створено Pod. + + ```shell + kubectl get pods + ``` + + Ви маєте отримати вивід, подібний до такого: - - У виводі ви побачите подібну інформацію: + ```output + NAME READY STATUS RESTARTS AGE + hello-node--5f76cf6ccf-br9b5 1/1 Running 0 1m + ``` + +1. Перегляд подій кластера: + + ```shell + kubectl get events + ``` + +1. Перегляд конфігурації `kubectl`: + + ```shell + kubectl config view + ``` + +1. Перегляд логів застосунку з контейнера в Podʼі: + + ```shell + kubectl logs hello-node-5f76cf6ccf-br9b5 + ``` + + Вивід має бути подібним до такого: + + ```output + I0911 09:19:26.677397 1 log.go:195] Started HTTP server on port 8080 + I0911 09:19:26.677586 1 log.go:195] Started UDP server on port 8081 + ``` + + {{< note >}} + Для ознайомлення з додатковими командами `kubectl` дивіться [Команди kubectl](/docs/reference/kubectl/). + {{< /note >}} + +## Створення Service {#create-service} - ``` - metrics-server was successfully disabled - ``` +Стандартно, Pod доступний лише за його внутрішньою IP-адресою в межах Kubernetes-кластера. Щоб зробити контейнер `hello-node` доступним назовні віртуальної мережі Kubernetes, вам потрібно подати Pod як [*Service*](/docs/concepts/services-networking/service/) Kubernetes. - -## Вивільнення ресурсів +1. Скористайтесь командою `kubectl expose` для пердставлення Podʼу у загальний доступ: - -Тепер ви можете видалити ресурси, які створили у вашому кластері: + ```shell + kubectl expose deployment hello-node --type=LoadBalancer --port=8080 + ``` + + Прапорець `--type=LoadBalancer` вказує, що ви хочете надати доступ до вашого Serviceʼу назовні кластера. + + Код застосунку всередині тестового образу контейнера тільки прослуховує порт 8080. Якщо ви використовуєте інший порт в `kubectl expose`, клієнти не зможуть отримати доступ до вашого застосунку. + +1. Перевірте, чи створено Service: + + ```shell + kubectl get services + ``` + + Ви маєте отримати вивід, подібний до такого: + + ```output + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + hello-node LoadBalancer 10.108.144.78 8080:30369/TCP 21s + kubernetes ClusterIP 10.96.0.1 443/TCP 23m + ``` + + Хмарні провайдери, які підтримують балансувальники навантаження, зовнішні IP-адреси можуть надаватись для доступу до Serviceʼу. В minikube `LoadBalancer` створює Service, доступний через команду `minikube service`. + +1. Виконайте наступну команду: + + ```shell + minikube service hello-node + ``` + + Це відкриє вікно вебоглядача, що показує відповідь застосунку. + +## Увімкнення додатків {#enable-addons} + +Інструменти minikube містять набір вбудованих {{< glossary_tooltip text="додатків" term_id="addons" >}}, які можна увімкнути, вимкнути та відкрити в локальному оточені Kubernetes. + +1. Перегляньте список доступних додатків: + + ```shell + minikube addons list + ``` + + Ви маєте отримати вивід, подібний до такого: + + ```output + addon-manager: enabled + dashboard: enabled + default-storageclass: enabled + efk: disabled + freshpod: disabled + gvisor: disabled + helm-tiller: disabled + ingress: disabled + ingress-dns: disabled + logviewer: disabled + metrics-server: disabled + nvidia-driver-installer: disabled + nvidia-gpu-device-plugin: disabled + registry: disabled + registry-creds: disabled + storage-provisioner: enabled + storage-provisioner-gluster: disabled + ``` + +1. Увімкніть додаток, наприклад, `metrics-server`: + + ```shell + minikube addons enable metrics-server + ``` + + Ви маєте отримати вивід, подібний до такого: + + ```output + The 'metrics-server' addon is enabled + ``` + +1. Перегляньте Podʼи та Serviceʼи, які щойно було створено: + + ```shell + kubectl get pod,svc -n kube-system + ``` + + Вивід має бути подібним до такого: + + ```output + NAME READY STATUS RESTARTS AGE + pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m + pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m + pod/metrics-server-67fb648c5 1/1 Running 0 26s + pod/etcd-minikube 1/1 Running 0 34m + pod/influxdb-grafana-b29w8 2/2 Running 0 26s + pod/kube-addon-manager-minikube 1/1 Running 0 34m + pod/kube-apiserver-minikube 1/1 Running 0 34m + pod/kube-controller-manager-minikube 1/1 Running 0 34m + pod/kube-proxy-rnlps 1/1 Running 0 34m + pod/kube-scheduler-minikube 1/1 Running 0 34m + pod/storage-provisioner 1/1 Running 0 34m + + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + service/metrics-server ClusterIP 10.96.241.45 80/TCP 26s + service/kube-dns ClusterIP 10.96.0.10 53/UDP,53/TCP 34m + service/monitoring-grafana NodePort 10.99.24.54 80:30002/TCP 26s + service/monitoring-influxdb ClusterIP 10.111.169.94 8083/TCP,8086/TCP 26s + ``` + + 1. Перевірте вивід з `metrics-server`: + + ```shell + kubectl top pods + ``` + + Ви маєте отримати вивід, подібний до такого: + + ```output + NAME CPU(cores) MEMORY(bytes) + hello-node-ccf4b9788-4jn97 1m 6Mi + ``` + + Якщо ви бачете наступне повідомлення, почекайте та спробуйте ще раз: + + ```output + error: Metrics API not available + ``` + +1. Вимкніть `metrics-server`: + + ```output + metrics-server was successfully disabled + ``` + +## Видалення кластера minikube {#clean-up} + +Тепер ви можете видалити ресурси, які ви створили в кластері: ```shell kubectl delete service hello-node kubectl delete deployment hello-node ``` - -За бажанням, зупиніть віртуальну машину (ВМ) з Minikube: +Зупиніть кластер minikube: ```shell minikube stop ``` - -За бажанням, видаліть ВМ з Minikube: +Необовʼязково, ви можете видалити кластер minikube: ```shell minikube delete ``` +Якщо ви бажаєте використовувати minikube знову для продовження вивчення Kubernetes, ви можете не видаляти його. +## Підсумки {#conclusion} -## {{% heading "whatsnext" %}} - - - -* Дізнайтеся більше про [об'єкти Deployment](/docs/concepts/workloads/controllers/deployment/). - -* Дізнайтеся більше про [розгортання застосунків](/docs/user-guide/deploying-applications/). - -* Дізнайтеся більше про [об'єкти Service](/docs/concepts/services-networking/service/). +Ця сторінка містить базові аспекти використання minikube для розгортання простого кластера Kubernetes та запуску тестового застосунку. Тепер ви готові до розгортання власних застосунків. +## {{% heading "whatsnext" %}} +* Посібник [Розгортання вашого першого застосунку в Kubernetes за допомогою kubectl](/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/). +* Дізнайтесь більше про [Розгортання застосунків](/docs/tasks/run-application/run-stateless-application-deployment/). +* Дізнайтесь більше про [Serviceʼи](/docs/concepts/services-networking/service/). diff --git a/content/uk/docs/tutorials/kubernetes-basics/_index.html b/content/uk/docs/tutorials/kubernetes-basics/_index.html index 9e4781b478a28..1deb10a01d123 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/_index.html +++ b/content/uk/docs/tutorials/kubernetes-basics/_index.html @@ -1,10 +1,10 @@ --- -title: Дізнатися про основи Kubernetes -linkTitle: Основи Kubernetes +title: Ознайомлення з основами Kubernetes +linkTitle: Ознайомлення з основами Kubernetes no_list: true weight: 10 card: - name: навчальні матеріали + name: tutorials weight: 20 title: Знайомство з основами --- @@ -15,40 +15,22 @@ - -
-

Основи Kubernetes

- -

Цей навчальний матеріал ознайомить вас з основами системи оркестрації Kubernetes кластера. Кожен модуль містить загальну інформацію щодо основної функціональності і концепцій Kubernetes, а також інтерактивний онлайн-урок. Завдяки цим інтерактивним урокам ви зможете самостійно керувати простим кластером і розгорнутими в ньому контейнеризованими застосунками.

- -

З інтерактивних уроків ви дізнаєтесь:

-
    - -
  • як розгорнути контейнеризований застосунок у кластері.
    • - -
  • як масштабувати Deployment.
    • - -
  • як розгорнути нову версію контейнеризованого застосунку.
    • - -
  • як відлагодити контейнеризований застосунок.
    • -
- -

Навчальні матеріали використовують Katacoda для запуску у вашому браузері віртуального термінала, в якому запущено Minikube - невеликий локально розгорнутий Kubernetes, що може працювати будь-де. Вам не потрібно встановлювати або налаштовувати жодне програмне забезпечення: кожен інтерактивний урок запускається просто у вашому браузері.

+

Цей посібник надає інструкції з основ системи оркестрування кластерів Kubernetes. Кожний модуль містить деяку вступну інформацію про основні функції та концепції Kubernetes, а також практичний посібник, за яким ви можете вчитися.

+

За допомогою цих посібників ви дізнаєтесь:

+
    +
  • як розгорнути контейнеризований застосунок в кластері.
    • +
  • як масштабувати Deployment.
    • +
  • як розгорнути нову версію контейнеризованого застосунку.
    • +
  • як налагодити контейнеризований застосунок.
    • +
+
@@ -56,21 +38,15 @@

Основи Kubernetes

-

Чим Kubernetes може бути корисний для вас?

- -

Від сучасних вебсервісів користувачі очікують доступності 24/7, а розробники - можливості розгортати нові версії цих застосунків по кілька разів на день. Контейнеризація, що допомагає упакувати програмне забезпечення, якнайкраще сприяє цим цілям. Вона дозволяє випускати і оновлювати застосунки легко, швидко та без простою. Із Kubernetes ви можете бути певні, що ваші контейнеризовані застосунки запущені там і тоді, де ви цього хочете, а також забезпечені усіма необхідними для роботи ресурсами та інструментами. Kubernetes - це висококласна платформа з відкритим вихідним кодом, в основі якої - накопичений досвід оркестрації контейнерів від Google, поєднаний із найкращими ідеями і практиками від спільноти.

+

З сучасними вебсервісами користувачі очікують доступності застосунків 24/7, а розробники прагнуть розгортати нові версії цих застосунків кілька разів на день. Контейнеризація допомагає упаковувати програмне забезпечення для досягнення цих цілей, дозволяючи випускати оновлення застосунків без перерви в роботі. Kubernetes допомагає забезпечити те, що контейнеризовані застосунки працюватимуть там і тоді, де це потрібно, та надає їм необхідні ресурси та інструменти для ефективної роботи. Kubernetes — це готова до використання, відкрита платформа, розроблена на основі здобутого Google досвіду в оркеструванні контейнерів, поєднаного з найкращими ідеями та практиками спільноти.


- -

Навчальні модулі "Основи Kubernetes"

+

Навчальні модулі «Основи Kubernetes»

@@ -78,7 +54,7 @@

Навчальні модулі "Основи Kubernetes"

-
1. Створення Kubernetes кластера
 +
1. Створення кластера Kubernetes
@@ -94,7 +70,7 @@

Навчальні модулі "Основи Kubernetes"

-
3. Вивчення застосунку
 +
3. Дослідить свій застосунок
diff --git a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/_index.md b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/_index.md index 9173c90d3448d..52f1deca667fd 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/_index.md +++ b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/_index.md @@ -2,3 +2,5 @@ title: Створення кластера weight: 10 --- + +Дізнайтесь про {{< glossary_tooltip text="кластери" term_id="cluster" length="all" >}} Kubernetes та створіть простий кластер за допомогою Minikube. diff --git a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 3ea6b82628f2f..0296c58f90fad 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -1,6 +1,11 @@ --- -title: Інтерактивний урок - Створення кластера +title: Інтерактивний урок — Створення кластера weight: 20 +headless: true +toc_hide: true +_build: + list: never + publishResources: false --- @@ -9,29 +14,18 @@ - - - +
-
- -
- -
-
- Для роботи з терміналом використовуйте комп'ютер або планшет -
-
-
-
-
- Перейти до модуля 2› -
+
+

+ Вміст недоступний +

+

+ Інтерактивний урок зі створення кластера недоступний. За додатковою інформацією звертайтеся до оголошення про закриття. +

-
- diff --git a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 088b185821ef7..65d765e06fb9d 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/uk/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -1,6 +1,10 @@ --- title: Використання Minikube для створення кластера weight: 10 +description: |- + Дізнайтесь, що таке Kubernetes кластер. + Дізнайтесь, що таке Minikube. + Запустіть кластер Kubernetes. --- @@ -9,8 +13,6 @@ - -
@@ -18,69 +20,38 @@
- -

Цілі

+

Мета

    - -
  • Зрозуміти, що таке Kubernetes кластер.
    • - -
  • Зрозуміти, що таке Minikube.
    • - -
  • Запустити Kubernetes кластер за допомогою онлайн-термінала.
    • +
  • Дізнатись, що таке кластер Kubernetes.
    • +
  • Дізнатись, що таке Minikube.
    • +
  • Запустити Kubernetes кластер на вашому компʼютері.
-

Kubernetes кластери

-

- Kubernetes координує високодоступний кластер комп'ютерів, з'єднаних таким чином, щоб працювати як одне ціле. Абстракції Kubernetes дозволяють вам розгортати контейнеризовані застосунки в кластері без конкретної прив'язки до окремих машин. Для того, щоб скористатися цією новою моделлю розгортання, застосунки потрібно упакувати таким чином, щоб звільнити їх від прив'язки до окремих хостів, тобто контейнеризувати. Контейнеризовані застосунки більш гнучкі і доступні, ніж попередні моделі розгортання, що передбачали встановлення застосунків безпосередньо на призначені для цього машини у вигляді програмного забезпечення, яке глибоко інтегрувалося із хостом. Kubernetes дозволяє автоматизувати розподіл і запуск контейнерів застосунку у кластері, а це набагато ефективніше. Kubernetes - це платформа з відкритим вихідним кодом, готова для використання у проді. -

- -

Kubernetes кластер складається з двох типів ресурсів: +

Кластер Kubernetes складається з двох типів ресурсів:

    -
  • master, що координує роботу кластера
    • -
  • вузли (nodes) - робочі машини, на яких запущені застосунки
    • +
  • Панелі управління (Control Plane), що координує роботу кластера
    • +
  • Вузлів (Nodes) — робочіх машин, на яких запущені застосунки

-

Зміст:

    - -
  • Kubernetes кластер
    • - +
  • Кластер Kubernetes
  • Minikube
-

- Kubernetes - це довершена платформа з відкритим вихідним кодом, що оркеструє розміщення і запуск контейнерів застосунку всередині та між комп'ютерними кластерами. + Kubernetes — це платформа з відкритим кодом промислового класу, яка оркеструє розташування (планування) та виконання контейнерів застосунків в межах та поміж компʼютерними кластерами.

@@ -102,45 +73,26 @@

Схема кластера

- -

Master відповідає за керування кластером. Master координує всі процеси у вашому кластері, такі як запуск застосунків, підтримка їх бажаного стану, масштабування застосунків і викатка оновлень.

- - -

Вузол (node) - це ВМ або фізичний комп'ютер, що виступає у ролі робочої машини в Kubernetes кластері. Кожен вузол має kubelet - агент для управління вузлом і обміну даними з Kubernetes master. Також на вузлі мають бути встановлені інструменти для виконання операцій з контейнерами, такі як Docker або rkt. Kubernetes кластер у проді повинен складатися як мінімум із трьох вузлів.

+

Панель управління (Control Plane) відповідає за керування кластером. Вона координує всі процеси у вашому кластері, такі як запуск застосунків, підтримка їх бажаного стану, масштабування застосунків та розгортання оновлень.

+

Вузол (Node) — це ВМ або фізичний компʼютер, що виступає у ролі робочої машини в кластері Kubernetes. Кожен вузол має kubelet — агента для управління вузлом та обміну даними з панеллю управління Kubernetes. Також на вузлі мають бути встановлені інструменти для виконання операцій з контейнерами, такі як {{< glossary_tooltip text="containerd" term_id="containerd" >}} або {{< glossary_tooltip term_id="cri-o" >}}. Кластер Kubernetes, що обслуговує операційний трафік має складатися як мінімум із трьох вузлів. Якщо один вузол вийде з ладу обидва члени etcd та панель управління будуть втрачені, а надмірність буде порушена. Ви можете зменшити ризик додаванням більше одного вузла з панеллю управління.

- -

Master'и керують кластером, а вузли використовуються для запуску застосунків.

+ +

Панелі управління керують кластером, а вузли призначені для запуску застосунків.

- -

Коли ви розгортаєте застосунки у Kubernetes, ви кажете master-вузлу запустити контейнери застосунку. Master розподіляє контейнери для запуску на вузлах кластера. Для обміну даними з master вузли використовують Kubernetes API, який надається master-вузлом. Кінцеві користувачі також можуть взаємодіяти із кластером безпосередньо через Kubernetes API.

- - -

Kubernetes кластер можна розгорнути як на фізичних, так і на віртуальних серверах. Щоб розпочати розробку під Kubernetes, ви можете скористатися Minikube - спрощеною реалізацією Kubernetes. Minikube створює на вашому локальному комп'ютері ВМ, на якій розгортає простий кластер з одного вузла. Існують версії Minikube для операційних систем Linux, macOS та Windows. Minikube CLI надає основні операції для роботи з вашим кластером, такі як start, stop, status і delete. Однак у цьому уроці ви використовуватимете онлайн термінал із вже встановленим Minikube.

+

Коли ви розгортаєте застосунки у Kubernetes, ви наказуєте панелі управління запустити контейнери застосунку. Панель управління розподіляє (планує) контейнери для запуску на вузлах кластера. Компоненти на рівні вузла, такі, як kubelet, спілкуються з панеллю управління за допомогою API Kubernetes, який надається панеллю управління. Кінцеві користувачі також можуть використовувати API Kubernetes для взаємодії з кластером.

- -

Тепер ви знаєте, що таке Kubernetes. Тож давайте перейдемо до інтерактивного уроку і створимо ваш перший кластер!

+

Кластер Kubernetes можна розгорнути як на фізичних, так й на віртуальних машинах. Щоб розпочати розробку під Kubernetes, ви можете скористатися Minikube — спрощеною реалізацією Kubernetes. Minikube створює на вашому локальному компʼютері ВМ, на якій розгортає простий кластер з одного вузла. Існують версії Minikube для операційних систем Linux, macOS та Windows. Minikube CLI надає основні операції для роботи з вашим кластером, такі як start, stop, status та delete.

-
-
-
+

Тепер ви знаєте, що таке Kubernetes. Тож відвідаємо сторінку Привіт Minikube та спробуємо його на вашому компʼютері.

-
-
- Почати інтерактивний урок ›
diff --git a/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 4f2b9876aa98c..acada87d248b2 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -1,6 +1,11 @@ --- -title: Інтерактивний урок - Розгортання застосунку +title: Інтерактивний урок — Розгортання застосунку weight: 20 +headless: true +toc_hide: true +_build: + list: never + publishResources: false --- @@ -9,28 +14,15 @@ - - - +
-
- -
- -
-
-
- Для роботи з терміналом використовуйте комп'ютер або планшет -
- -
-
- -
-
-
- Перейти до модуля 3› -
+
+

+ Вміст недоступний +

+

+ Інтерактивний урок зі створення кластера недоступний. За додатковою інформацією звертайтеся до оголошення про закриття. +

diff --git a/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 16fcf66bb77bb..1592ced80d04d 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/uk/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -1,80 +1,57 @@ --- -title: Використання kubectl для створення Deployment'а +title: Використання kubectl для створення Deploymentʼа weight: 10 +description: |- + Дізнайтесь, що таке Deployment застосунків. + Розгорніть свій перший застосунок у Kubernetes за допомогою kubectl. --- - - -
-
- -

Цілі

-
    - -
  • Дізнатися, що таке Deployment застосунків.
    • - -
  • Розгорнути свій перший застосунок у Kubernetes за допомогою kubectl.
    • +

    Мета

    +
      +
    • Дізнатися, що таке Deployment застосунків.
      • +
    • Розгорнути свій перший застосунок у Kubernetes за допомогою kubectl.
-

Процеси Kubernetes Deployment

- + + {{< note >}} +

Цей навчальний посібник використовує контейнер, який вимагає архітектури AMD64. Якщо ви використовуєте minikube на компʼютері з іншою архітектурою процесора, ви можете спробувати використовувати minikube з драйвером, який може емулювати AMD64. Наприклад, драйвер Docker Desktop може це зробити.

+ {{< /note >}} +

- Після того, як ви запустили Kubernetes кластер, ви можете розгортати в ньому контейнеризовані застосунки. Для цього вам необхідно створити Deployment конфігурацію. Вона інформує Kubernetes, як створювати і оновлювати Pod'и для вашого застосунку. Після того, як ви створили Deployment, Kubernetes master розподіляє ці Pod'и по окремих вузлах кластера. + Після створення працюючого кластера Kubernetes ви можете розгортати свої контейнеризовані застосунки на його основі. Для цього створіть розгортання (Deployment) Kubernetes. Deployment вказує Kubernetes, як створювати та оновлювати екземпляри вашого застосунку. Після створення Deployment панель управління Kubernetes розподіляє екземпляри застосунків, що включені в цей Deployment, для запуску на окремих вузлах в кластері.

- -

Після створення Pod'и застосунку безперервно моніторяться контролером Kubernetes Deployment. Якщо вузол, на якому розміщено Pod, зупинив роботу або був видалений, Deployment контролер переміщає цей Pod на інший вузол кластера. Так працює механізм самозцілення, що підтримує робочий стан кластера у разі апаратного збою чи технічних робіт.

+

Коли екземпляри застосунків створені, контролер розгортання Kubernetes безперервно відстежує їх стан. Якщо вузол, на якому запущено екземпляр, вимикається або видаляється, контролер розгортання замінює екземпляр новим на іншому вузлі в кластері. Це забезпечує механізм самовідновлення для розвʼязання проблем з відмовою або обслуговуванням вузлів.

- -

До появи оркестрації застосунки часто запускали за допомогою скриптів установлення. Однак скрипти не давали можливості відновити працездатний стан застосунку після апаратного збою. Завдяки створенню Pod'ів та їхньому запуску на вузлах кластера, Kubernetes Deployment надає цілковито інший підхід до управління застосунками.

+

У світі до-оркестрування часто використовувалися скрипти встановлення для запуску застосунків, але вони не дозволяли відновлення після відмови вузла. Шляхом як створення екземплярів застосунків, так і утримання їх в робочому стані на різних вузлах, розгортання Kubernetes забезпечує фундаментально відмінний підхід до управління застосунками.

-

Зміст:

    -
  • Deployment'и
  • Kubectl
-

- Deployment відповідає за створення і оновлення Pod'ів для вашого застосунку + Deployment відповідає за створення та оновлення Podʼів для вашого застосунку

@@ -83,7 +60,7 @@

Зміст:

-

Як розгорнути ваш перший застосунок у Kubernetes

+

Розгортання вашого першого застосунку в Kubernetes

@@ -97,22 +74,12 @@

Як розгорнути ваш перший зас
- -

Ви можете створити Deployment і керувати ним за допомогою командного рядка Kubernetes - kubectl. kubectl взаємодіє з кластером через API Kubernetes. У цьому модулі ви вивчите найпоширеніші команди kubectl для створення Deployment'ів, які запускатимуть ваші застосунки у Kubernetes кластері.

- - -

Коли ви створюєте Deployment, вам необхідно задати образ контейнера для вашого застосунку і скільки реплік ви хочете запустити. Згодом цю інформацію можна змінити, оновивши Deployment. У навчальних модулях 5 і 6 йдеться про те, як масштабувати і оновлювати Deployment'и.

- - - +

Ви можете створювати та управляти розгортанням (Deployment) за допомогою інтерфейсу командного рядка Kubernetes, kubectl. Kubectl використовує API Kubernetes для взаємодії з кластером. У цьому модулі ви вивчите найпоширеніші команди kubectl, які потрібні для створення розгортань та запуску застосунків в кластері Kubernetes.

+

Коли ви створюєте Deployment, вам необхідно вказати образ контейнера вашого застосунку та скільки його реплік ви бажаєте запустити. Згодом цю інформацію можна змінити, оновивши Deployment. В навчальних модулях 5 і 6 йдеться про те, як масштабувати і оновлювати Deployment'и.

-

Для того, щоб розгортати застосунки в Kubernetes, їх потрібно упакувати в один із підтримуваних форматів контейнерів

@@ -120,29 +87,72 @@

Як розгорнути ваш перший зас
- -

- Для створення Deployment'а ви використовуватимете застосунок, написаний на Node.js і упакований в Docker контейнер. (Якщо ви ще не пробували створити Node.js застосунок і розгорнути його у контейнері, радимо почати саме з цього; інструкції ви знайдете у навчальному матеріалі Привіт Minikube). -

- - -

Тепер ви знаєте, що таке Deployment. Тож давайте перейдемо до інтерактивного уроку і розгорнемо ваш перший застосунок!

+

Для вашого першого розгортання ви будете використовувати застосунок hello-node, який упакований в Docker-контейнер і використовує NGINX для відгуку на всі запити. (Якщо ви ще не пробували створити застосунок hello-node та розгортати його за допомогою контейнера, ви можете це зробити, слідуючи інструкціям з посібника Привіт Minikube).

+

Вам також потрібно мати `kubectl`. Якщо ви ще не встановили його, відвідайте встановлення інструментів.

+

Тепер ви знаєте, що таке Deployment. Тож розгорнемо ваш перший застосунок!


+
+
+

Основи kubectl

+

Загальний формат команди kubectl: kubectl дія ресурс

+

Тут виконується вказана дія (наприклад, create, describe або delete) для вказаного ресурсу (наприклад, node або deployment). Ви можете використовувати --help після команд для отримання додаткової інформації про можливі параметри (наприклад, kubectl get nodes --help).

+

Перевірте, що kubectl налаштовано для роботи з вашим кластером, виконавши команду kubectl version.

+

Перевірте, що kubectl встановлено і ви можете бачити як версію клієнта, так і версію сервера.

+

Щоб переглянути вузли в кластері, виконайте команду kubectl get nodes.

+

Ви побачите доступні вузли. Пізніше Kubernetes вибере, де розгорнути наш застосунок на основі ресурсів, доступних на вузлах.

+
+
+
+
+ +

Розгортання застосунку

+

Розгорнімо наш перший застосунок на Kubernetes за допомогою команди kubectl create deployment. Ми повинні вказати назву розгортання та розташування образу застосунку (вкажіть повну URL-адресу репозиторію образів, розміщених за межами Docker Hub).

+

kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

+

Відмінно! Ви щойно розгорнули свій перший застосунок, створивши Deployment. Це призвело до виконання для вас кількох дій:

+
    +
  • пошук відповідного вузла, де може бути запущений екземпляр застосунку (у нас доступний лише 1 вузол)
    • +
  • планування запуску застосунку на цьому вузлі
    • +
  • налаштування кластера для перепланування екземпляра на новому вузлі за необхідності
    • +
+

Щоб переглянути ваші розгортання, використовуйте команду kubectl get deployments:

+

kubectl get deployments

+

Ми бачимо, що є 1 розгортання, яке запускає один екземпляр вашого застосунку. Екземпляр працює в контейнері на вашому вузлі.

+
+
+
- Почати інтерактивний урок › +

Перегляд застосунку

+

Podʼи, які працюють всередині Kubernetes, запущені в ізольованій приватній мережі. Типово вони видимі з інших Podʼів та служб всередині того ж самого кластера Kubernetes, але не за межами цієї мережі. Коли ми використовуємо kubectl, ми взаємодіємо через кінцеву точку API для спілкування з нашим застосунком.

+

Розглянемо інші варіанти того, як вивести наш застосунок за межі кластера Kubernetes пізніше, в Модулі 4. Також, як у базовому посібнику, тут ми не пояснюємо докладно, що таке Podʼи, це буде розглянуто в подальших темах.

+

Команда kubectl proxy може створити проксі, який буде пересилати дані в мережу, що охоплює весь кластер. Роботу проксі можна завершити, натиснувши control-C, і він не виводитиме жодного результату під час роботи.

+

Вам потрібно відкрити друге вікно термінала для запуску проксі.

+

kubectl proxy

+

Тепер у нас є зʼєднання між вашим хостом (терміналом) та кластером Kubernetes. Проксі дозволяє безпосередній доступ до API з цих терміналів.

+

Ви можете побачити всі ці API, розміщені через проксі-endpoint. Наприклад, ми можемо запитати версію напряму через API, використовуючи команду curl:

+

curl http://localhost:8001/version

+ +

Сервер API автоматично створює кінцеву точку для кожного Podʼу на основі імені Podʼа, яка також доступна через проксі.

+

Спочатку нам потрібно отримати імʼя Podʼу, і ми збережемо його в змінну оточення POD_NAME:

+

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
+ echo Name of the Pod: $POD_NAME

+

Ви можете отримати доступ до Podʼу через проксі-API, запустивши:

+

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/

+

Для того, щоб нове розгортання було доступним без використання проксі, потрібен сервіс, про що буде розказано в Модулі 4.

+
+

+ Якщо ви готові, перейдіть до Перегляд Podʼів та Nodeʼів. +

+
+ + +

diff --git a/content/uk/docs/tutorials/kubernetes-basics/explore/_index.md b/content/uk/docs/tutorials/kubernetes-basics/explore/_index.md index 93ac6a77745f9..b025593f107b8 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/explore/_index.md +++ b/content/uk/docs/tutorials/kubernetes-basics/explore/_index.md @@ -1,4 +1,4 @@ --- -title: Вивчення застосунку +title: Дослідження застосунку weight: 30 --- diff --git a/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index 6722a495cb8e8..cbf7e4321f674 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/uk/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -1,6 +1,11 @@ --- -title: Інтерактивний урок - Вивчення застосунку +title: Інтерактивний урок — Дослідження застосунку weight: 20 +headless: true +toc_hide: true +_build: + list: never + publishResources: false --- @@ -9,33 +14,18 @@ - - - +
-
- -
- -
-
- -
- Для роботи з терміналом використовуйте комп'ютер або планшет -
- -
-
-
-
-
- Перейти до модуля 4› -
+
+

+ Вміст недоступний +

+

+ Інтерактивний урок зі створення кластера недоступний. За додатковою інформацією звертайтеся до оголошення про закриття. +

-
- diff --git a/content/uk/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/uk/docs/tutorials/kubernetes-basics/explore/explore-intro.html index 9f3d15e011ee2..a1649979b1e69 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/uk/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -1,6 +1,9 @@ --- -title: Ознайомлення з Pod'ами і вузлами (nodes) +title: Перегляд Podʼів та вузлів (Node) weight: 10 +description: |- + Дізнайтесь, як розвʼязувати проблеми з розгорнутими застосунками, + використовуючи kubectl get, kubectl describe, kubectl logs та kubectl exec. --- @@ -9,9 +12,6 @@ - - -
@@ -19,65 +19,39 @@
- -

Цілі

+

Мета

    - -
  • Дізнатися, що таке Pod'и Kubernetes.
    • - +
  • Дізнатися, що таке Podʼи Kubernetes.
  • Дізнатися, що таке вузли Kubernetes.
    • -
  • Діагностика розгорнутих застосунків.
- -

Pod'и Kubernetes

- -

Коли ви створили Deployment у модулі 2, Kubernetes створив Pod, щоб розмістити ваш застосунок. Pod - це абстракція в Kubernetes, що являє собою групу з одного або декількох контейнерів застосунку (як Docker або rkt) і ресурси, спільні для цих контейнерів. До цих ресурсів належать:

+

Podʼи Kubernetes

+

Коли ви створили Deployment у модулі 2, Kubernetes створив Pod, щоб розмістити ваш застосунок. Pod — це абстракція в Kubernetes, що являє собою групу з одного або декількох контейнерів застосунку (таких як Docker) та ресурсів, спільних для цих контейнерів. До цих ресурсів належать:

    -
  • Спільні сховища даних, або Volumes
    • -
  • Мережа, адже кожен Pod у кластері має унікальну IP-адресу
    • - -
  • Інформація з запуску кожного контейнера, така як версія образу контейнера або використання певних портів
    • +
  • Інформація про запуск кожного контейнера, така як версія образу контейнера або використання певних портів
- -

Pod моделює специфічний для даного застосунку "логічний хост" і може містити різні, але доволі щільно зв'язані контейнери. Наприклад, в одному Pod'і може бути контейнер з вашим Node.js застосунком та інший контейнер, що передає дані для публікації Node.js вебсерверу. Контейнери в межах Pod'а мають спільну IP-адресу і порти, завжди є сполученими, плануються для запуску разом і запускаються у спільному контексті на одному вузлі.

+

Pod моделює специфічний для даного застосунку "логічний хост" та може містити різні, але доволі щільно звʼязані один з одним контейнери. Наприклад, в одному Podʼі може бути контейнер з вашим Node.js застосунком та інший контейнер, що передає дані для публікації Node.js вебсерверу. Контейнери в межах Podʼа мають спільну IP-адресу та порти, завжди є сполученими, плануються для запуску разом та запускаються у спільному контексті на одному вузлі.

- -

Pod є неподільною одиницею платформи Kubernetes. Коли ви створюєте Deployment у Kubernetes, цей Deployment створює Pod'и вже з контейнерами всередині, на відміну від створення контейнерів окремо. Кожен Pod прив'язаний до вузла, до якого його було розподілено, і лишається на ньому до припинення роботи (згідно з політикою перезапуску) або видалення. У разі відмови вузла ідентичні Pod'и розподіляються по інших доступних вузлах кластера.

+

Pod є неподільною одиницею платформи Kubernetes. Коли ви створюєте Deployment у Kubernetes, цей Deployment створює Podʼи вже з контейнерами всередині, на відміну від створення контейнерів окремо. Кожен Pod привʼязаний до вузла, до якого його було розподілено, і лишається на ньому до припинення роботи (згідно з політикою перезапуску) або видалення. У разі відмови вузла ідентичні Podʼи розподіляються по інших доступних вузлах кластера.

Зміст:

    -
  • Pod'и
    • +
  • Podʼи
  • Вузли
  • Основні команди kubectl
-

- Pod - це група з одного або декількох контейнерів (таких як Docker або rkt), що має спільне сховище даних (volumes), унікальну IP-адресу і містить інформацію як їх запустити. + Pod — це група з одного або декількох контейнерів (таких як Docker), що має спільне сховище даних (volumes), унікальну IP-адресу і містить інформацію про те, як їх запустити.

@@ -86,7 +60,7 @@

Зміст:

-

Узагальнена схема Pod'ів

+

Узагальнена схема Podʼів

@@ -99,32 +73,22 @@

Узагальнена схема Pod'ів

- +

Вузли

- -

Pod завжди запускається на вузлі. Вузол - це робоча машина в Kubernetes, віртуальна або фізична, в залежності від кластера. Функціонування кожного вузла контролюється master'ом. Вузол може мати декілька Pod'ів. Kubernetes master автоматично розподіляє Pod'и по вузлах кластера з урахуванням ресурсів, наявних на кожному вузлі.

- - +

Pod завжди запускається на вузлі. Вузол — це робоча машина в Kubernetes, віртуальна або фізична, залежно від кластера. Функціонування кожного вузла контролюється панеллю управління. Вузол може мати декілька Podʼів, а панель управління автоматично призначає Podʼи вузлам в кластері. Панель управління Kubernetes автоматично розподіляє Podʼи по вузлах кластера з урахуванням ресурсів, наявних на кожному вузлі.

+

На кожному вузлі Kubernetes запущені як мінімум:

    - -
  • kubelet - процес, що забезпечує обмін даними між Kubernetes master і робочим вузлом; kubelet контролює Pod'и і контейнери, запущені на машині.
    • - -
  • оточення для контейнерів (таке як Docker, rkt), що забезпечує завантаження образу контейнера з реєстру, розпакування контейнера і запуск застосунку.
    • + +
  • Kubelet — процес, що забезпечує обмін даними між панеллю управління Kubernetes та робочим вузлом; kubelet керує Podʼами та контейнерами, запущеним на машині.
    • +
  • Оточення для запуску контейнерів (таке як Docker) забезпечує завантаження образу контейнера з реєстру, розпакування контейнера та запуск застосунку.
-
- -

Контейнери повинні бути разом в одному Pod'і, лише якщо вони щільно зв'язані і мають спільні ресурси, такі як диск.

+
+

Контейнери повинні бути разом в одному Podʼі, лише якщо вони щільно звʼязані і мають спільні ресурси, такі як диск.

@@ -146,52 +110,86 @@

Узагальнена схема вузлів

- -

Діагностика за допомогою kubectl

- -

У модулі 2 ви вже використовували інтерфейс командного рядка kubectl. У модулі 3 ви продовжуватимете користуватися ним для отримання інформації про застосунки та оточення, в яких вони розгорнуті. Нижченаведені команди kubectl допоможуть вам виконати наступні поширені дії:

+

Виправлення проблем за допомогою kubectl

+

У модулі 2 ви використовували інтерфейс командного рядка kubectl. Ви будете продовжувати його використовувати в модулі 3 для отримання інформації про розгорнуті застосунки та їхні середовища. За допомогою наступних підкоманд kubectl можна виконати найбільш поширені операції:

    - -
  • kubectl get - відобразити список ресурсів
    • - -
  • kubectl describe - показати детальну інформацію про ресурс
    • - -
  • kubectl logs - вивести логи контейнера, розміщеного в Pod'і
    • - -
  • kubectl exec - виконати команду в контейнері, розміщеному в Pod'і
    • +
  • kubectl get — показати перелік ресурсів
    • +
  • kubectl describe — виведення детальної інформації про ресурс
    • +
  • kubectl logs — виведення логів контейнера в Podʼі
    • +
  • kubectl exec — виконання команди в контейнері в Podʼі
- - -

За допомогою цих команд ви можете подивитись, коли і в якому оточенні був розгорнутий застосунок, перевірити його поточний статус і конфігурацію.

- - -

А зараз, коли ми дізналися більше про складові нашого кластера і командний рядок, давайте детальніше розглянемо наш застосунок.

- + +

Ви можете використовувати ці команди, щоб переглядати інформацію про те, коли були розгорнуті застосунки, який їхній поточний статус, де вони запущені та які їхні конфігурації.

+ +

Тепер, коли ми більше знаємо про компоненти нашого кластера та командний рядок, дослідімо наш застосунок.

+
- -

Вузол - це робоча машина в Kubernetes, віртуальна або фізична, в залежності від кластера. На одному вузлі можуть бути запущені декілька Pod'ів.

+

Вузол — це робоча машина в Kubernetes і може бути віртуальною машиною або фізичною машиною залежно від кластера. На одному вузлі може працювати кілька Podʼів.

-
- Почати інтерактивний урок › +

Перевірка конфігурації застосунку

+

Перевірмо, чи працює застосунок, який ми розгорнули в попередньому сценарії. Ми використаємо команду kubectl get і подивимося на наявні Podʼи:

+

kubectl get pods

+

Якщо Podʼи не запущені, зачекайте кілька секунд і знову спробуйте вивести список Podʼів. Ви можете продовжити, якщо ви бачите, що працює один Pod.

+

Далі, щоб переглянути, які контейнери є всередині цього Podʼа і які образи використовуються для створення цих контейнерів, ми використовуємо команду kubectl describe pods:

+

kubectl describe pods

+

Тут ми бачимо деталі про контейнер Podʼа: IP-адресу, порти та список подій, повʼязаних з життєвим циклом Podʼа.

+

Вивід підкоманди describe є розлогим і охоплює деякі концепції, які ми ще не пояснили, але не хвилюйтеся, вони стануть зрозумілими до кінця цього курсу.

+

Примітка: підкоманду describe можна використовувати для отримання детальної інформації про більшість примітивів Kubernetes, включаючи вузли, Podʼи та Deployment. Вивід команди describe призначений для сприйняття людиною, а не для сценаріїв.

+
+
+

Показати застосунок у терміналі

+

Пригадайте, що Podʼи працюють в ізольованій, приватній мережі — тому нам потрібно налаштувати проксі-доступ до них для налагодження та взаємодії з ними. Для цього ми використовуємо команду kubectl proxy для запуску проксі в іншому терміналі. Відкрийте нове вікно термінала і введіть у цьому новому терміналі:

+

kubectl proxy

+

Тепер ми знову отримаємо імʼя Podʼа та будемо звертатись до цього Podʼу безпосередньо через проксі. Щоб отримати імʼя Podʼа та зберегти його в змінну середовища POD_NAME:

+

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
+ echo Name of the Pod: $POD_NAME

+

Щоб переглянути вивід нашого застосунку, виконайте запит curl:

+

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

+

URL — це шлях до API Podʼа.

+
+
+ +
+
+

Перегляд логів контейнера

+

Все, що застосунок зазвичай виводить на стандартний вивід, стає логами контейнера всередині Podʼа. Ми можемо отримати ці логи, використовуючи команду kubectl logs:

+

kubectl logs "$POD_NAME"

+

Примітка: Нам не потрібно вказувати імʼя контейнера, оскільки у нас є лише один контейнер всередині Podʼа.

+
+
+ +
+
+

Виконання команди в контейнері

+

Ми можемо виконувати команди безпосередньо в контейнері після того, як Pod буде запущено та він працюватиме. Для цього ми використовуємо підкоманду exec і вказуємо імʼя Podʼа як параметр. Перегляньмо змінні середовища:

+

kubectl exec "$POD_NAME" -- env

+

Знову варто зазначити, що можна пропустити імʼя самого контейнера, оскільки у нас є лише один контейнер в Podʼі.

+

Далі розпочнім сеанс bash в контейнері Podʼа:

+

kubectl exec -ti $POD_NAME -- bash

+

Тепер у нас є відкрита консоль в контейнері, де запущений наш застосунок NodeJS. Вихідний код застосунку знаходиться у файлі server.js:

+

cat server.js

+

Ви можете перевірити, чи застосунок запущено, виконавши команду curl:

+

curl http://localhost:8080

+

Примітка: тут ми використовували localhost, оскільки ми виконали команду всередині Podʼа NodeJS. Якщо ви не можете підʼєднатися до localhost:8080, перевірте, чи ви виконали команду kubectl exec і запускаєте команду зсередини Podʼа

+

Щоб закрити підключення до контейнера, введіть exit.

+
+
+ +
+

+ Як тільки ви будете готові, переходьте до Використання Service для надання доступу до вашого застосунку. +

+
diff --git a/content/uk/docs/tutorials/kubernetes-basics/expose/_index.md b/content/uk/docs/tutorials/kubernetes-basics/expose/_index.md index ef49a1b632a48..79c5e7abbb67d 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/expose/_index.md +++ b/content/uk/docs/tutorials/kubernetes-basics/expose/_index.md @@ -1,4 +1,4 @@ --- -title: Відкриття доступу до застосунку за межами кластера +title: Доступ до застосунку зовні weight: 40 --- diff --git a/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index 0a7ae43353202..8bd070980461a 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -1,6 +1,11 @@ --- -title: Інтерактивний урок - Відкриття доступу до застосунку +title: Інтерактивний урок — Відкриття доступу до застосунку weight: 20 +headless: true +toc_hide: true +_build: + list: never + publishResources: false --- @@ -9,30 +14,18 @@ - - - +
-
- -
- -
-
- Для роботи з терміналом використовуйте комп'ютер або планшет -
-
-
-
-
-
- Перейти до модуля 5› -
+
+

+ Вміст недоступний +

+

+ Інтерактивний урок зі створення кластера недоступний. За додатковою інформацією звертайтеся до оголошення про закриття. +

-
- diff --git a/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 6e61ef4a3f0c9..c1fb3bd9ac6db 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -1,7 +1,10 @@ --- -#title: Using a Service to Expose Your App -title: Використання Cервісу для відкриття доступу до застосунку за межами кластера +title: Використання Service для доступу до застосунку weight: 10 +description: |- + Дізнайтесь про Service у Kubernetes. + Ознайомтесь з тим, як мітки та селектори повʼязані з Service. + Відкрийте доступ до застосунку по за межами Kubernetes кластера. --- @@ -10,88 +13,48 @@ - -
- -

Цілі

+

Мета

    - -
  • Дізнатись, що таке Cервіс у Kubernetes
    • - -
  • Зрозуміти, яке відношення до Cервісу мають мітки та LabelSelector
    • - -
  • Відкрити доступ до застосунку за межами Kubernetes кластера, використовуючи Cервіс
    • +
  • Дізнатись про Service у Kubernetes.
    • +
  • Ознайомитись з тим, як мітки та селектори повʼязані з Service.
    • +
  • Відкрити доступ до застосунку по за межами Kubernetes кластера.
-
- -

Загальна інформація про Kubernetes Cервіси

- - -

Pod'и Kubernetes "смертні" і мають власний життєвий цикл. Коли робочий вузол припиняє роботу, ми також втрачаємо всі Pod'и, запущені на ньому. ReplicaSet здатна динамічно повернути кластер до бажаного стану шляхом створення нових Pod'ів, забезпечуючи безперебійність роботи вашого застосунку. Як інший приклад, візьмемо бекенд застосунку для обробки зображень із трьома репліками. Ці репліки взаємозамінні; система фронтенду не повинна зважати на репліки бекенду чи на втрату та перестворення Pod'а. Водночас, кожний Pod у Kubernetes кластері має унікальну IP-адресу, навіть Pod'и на одному вузлі. Відповідно, має бути спосіб автоматично синхронізувати зміни між Pod'ами для того, щоб ваші застосунки продовжували працювати.

- - -

Service у Kubernetes - це абстракція, що визначає логічний набір Pod'ів і політику доступу до них. Services уможливлюють слабку зв'язаність між залежними Pod'ами. Для визначення Service використовують YAML-файл (рекомендовано) або JSON, як для решти об'єктів Kubernetes. Набір Pod'ів, призначених для Service, зазвичай визначається через LabelSelector (нижче пояснюється, чому параметр selector іноді не включають у специфікацію Service).

- - -

Попри те, що кожен Pod має унікальний IP, ці IP-адреси не видні за межами кластера без Service. Services уможливлюють надходження трафіка до ваших застосунків. Відкрити Service можна по-різному, вказавши потрібний type у ServiceSpec:

-
    - -
  • ClusterIP (типове налаштування) - відкриває доступ до Service у кластері за внутрішнім IP. Цей тип робить Service доступним лише у межах кластера.
    • - -
  • NodePort - відкриває доступ до Service на однаковому порту кожного обраного вузла в кластері, використовуючи NAT. Робить Service доступним поза межами кластера, використовуючи <NodeIP>:<NodePort>. Є надмножиною відносно ClusterIP.
    • - -
  • LoadBalancer - створює зовнішній балансувальник навантаження у хмарі (за умови хмарної інфраструктури) і призначає Service статичну зовнішню IP-адресу. Є надмножиною відносно NodePort.
    • - -
  • ExternalName - відкриває доступ до Service, використовуючи довільне ім'я (визначається параметром externalName у специфікації), повертає запис CNAME. Проксі не використовується. Цей тип потребує версії kube-dns 1.7 і вище.
    • -
- -

Більше інформації про різні типи Services ви знайдете у навчальному матеріалі Використання вихідної IP-адреси. Дивіться також Поєднання застосунків з Services.

- -

Також зауважте, що для деяких сценаріїв використання Services параметр selector не задається у специфікації Service. Service, створений без визначення параметра selector, також не створюватиме відповідного Endpoint об'єкта. Це дозволяє користувачам вручну спроектувати Service на конкретні кінцеві точки (endpoints). Інший випадок, коли Селектор може бути не потрібний - використання строго заданого параметра type: ExternalName.

-
+
+

Огляд Сервісів в Kubernetes

+

Існування Podʼів в Kubernetes є обмеженими за часом, також вони мають свій життєвий цикл. Коли робочий вузол припиняє існування, також втрачаються Podʼи, які виконуються на цьому вузлі. ReplicaSet може динамічно приводити кластер до бажаного стану шляхом створення нових Podʼів, щоб ваш застосунок продовжував працювати. Наприклад, розгляньмо обробник зображень, що має 3 копії. Ці копії (репліки) можуть бути взаємозамінні; система форонтенду не повинна перейматися репліками бекенду або навіть тим, чи Pod втрачено та створено наново. Проте кожен Pod в кластері Kubernetes має унікальну IP-адресу, навіть Podʼи на одному вузлі, тому потрібно мати спосіб автоматичного узгодження змін серед Podʼів, щоб ваші застосунки продовжували працювати.

+ +

Service в Kubernetes є абстракцією, яка визначає логічний набір Podʼів та політику доступу до них. Serviceʼи забезпечують слабку звʼязаність між залежними Podʼами. Service визначається за допомогою YAML або JSON, так само як і всі обʼєкти Kubernetes. Набір Podʼів, на які призначений Service, зазвичай визначається селектором міток (label selector) (див. нижче, чому selector іноді не включають у специфікацію Service).

+ +

Хоча кожний Pod має унікальну IP-адресу, ці IP не доступні за межі кластера без використання Service. Serviceʼи уможливлюють надходження трафіку до ваших застосунків. Serviceʼи можуть бути оприлюднені у різний спосіб, за допомогою type у spec Service:

+
    +
  • ClusterIP (типове значення) — відкриває доступ до внутрішнього IP Service в кластері. Цей тип робить Service доступним лише зсередини кластера.
    • +
  • NodePort — відкриває доступ до Service на тому ж порті кожного обраного вузла в кластері за допомогою NAT. Робить Service доступним ззовні кластера за допомогою <NodeIP>:<NodePort>. Є надмножиною відносно ClusterIP.
    • +
  • LoadBalancer — створює зовнішній балансувальник навантаження в поточному хмарному середовищі (якщо підтримується) та призначає фіксовану зовнішню IP-адресу для Service. Є надмножиною відносно NodePort.
    • +
  • ExternalName — звʼязує Service з вмістом поля externalName (наприклад, foo.bar.example.com), повертаючи запис CNAME із його значенням. Не встановлюється жодного проксі. Цей тип вимагає v1.7 або вище kube-dns або CoreDNS версії 0.0.8 або вище.
    • +
+

Додаткову інформацію про різновиди Service можна знайти у посібнику Використання IP-адреси джерела. Дивіться також Підключення застосунків до Service.

+

Крім того, слід зауважити, що існують випадки використання Service, при яких не визначається selector у специфікації. Service, створений без selector, також не створить відповідний обʼєкт Endpoints. Це дозволяє користувачам вручну відкривати доступ Service на конкретні кінцеві точки. Ще одна можливість, чому може бути відсутній селектор — використання виключно type: ExternalName.

+
+
-

Зміст

    - -
  • Відкриття Pod'ів для зовнішнього трафіка
    • - -
  • Балансування навантаження трафіка між Pod'ами
    • - +
  • Відкриття Podʼів для зовнішнього трафіка
    • +
  • Балансування навантаження трафіку між Podʼами
  • Використання міток
- -

Service Kubernetes - це шар абстракції, який визначає логічний набір Pod'ів і відкриває їх для зовнішнього трафіка, балансує навантаження і здійснює виявлення цих Pod'ів.

+

Service в Kubernetes – це рівень абстракції, який визначає логічний набір Podʼів і дозволяє експонування зовнішнього трафіку, балансування навантаження та виявлення служб для цих Podʼів.

@@ -99,69 +62,115 @@

Зміст

- -

Services і мітки

-
-
- -
-
-

+

Services та мітки (Labels)

-
-
- -

Service маршрутизує трафік між Pod'ами, що входять до його складу. Service - це абстракція, завдяки якій Pod'и в Kubernetes "вмирають" і відтворюються, не впливаючи на роботу вашого застосунку. Services в Kubernetes здійснюють виявлення і маршрутизацію між залежними Pod'ами (як наприклад, фронтенд- і бекенд-компоненти застосунку).

- -

Services співвідносяться з набором Pod'ів за допомогою міток і Селекторів -- примітивів групування, що роблять можливими логічні операції з об'єктами у Kubernetes. Мітки являють собою пари ключ/значення, що прикріплені до об'єктів і можуть використовуватися для різних цілей:

-
    - -
  • Позначення об'єктів для дев, тест і прод оточень
    • - -
  • Прикріплення тегу версії
    • - -
  • Класифікування об'єктів за допомогою тегів
    • -
- -
-
-
- -

Ви можете створити Service одночасно із Deployment, виконавши команду
--expose в kubectl.

-
-
-
+
+
+

Service маршрутизує трафік набору Podʼів. Service є абстракцією, яка дозволяє Podʼам зникати та реплікуватися в Kubernetes, не впливаючи на ваш застосунок. Виявлення та маршрутизація серед залежних Podʼів (таких як компоненти frontend та backend у застосунку) обробляються Serviceʼами Kubernetes.

+

Service визначають набір Podʼів за допомогою міток та селекторів, примітиву гуртування, який дозволяє логічно взаємодіяти з обʼєктами в Kubernetes. Мітки — це пари ключ/значення, призначені обʼєктам та можуть бути використані різними способами:

+
    +
  • Призначення обʼєктів до оточення розробки, тестування та експлуатації
    • +
  • Вбудовування теґів версій
    • +
  • Класифікація обʼєкта за допомогою теґів
    • +
+
+
-
+

-
-
-
- -

Мітки можна прикріпити до об'єктів під час створення або пізніше. Їх можна змінити у будь-який час. А зараз давайте відкриємо наш застосунок за допомогою Service і прикріпимо мітки.

-
-
-
-
-
- Почати інтерактивний урок› -
-
+
+ +
+
+

Мітки можна прикріплювати до обʼєктів при їх створенні або пізніше. Їх можна змінювати в будь-який час. Давайте зараз використаємо Service для надання доступу до нашого застосунку та застосуємо деякі мітки.

+
+
+ +
+
+

Крок 1: Створення нового Service

+

Перевіримо, що наш застосунок працює. Ми використовуватимемо команду kubectl get та переглядатимемо наявні Podʼи:

+

kubectl get pods

+

Якщо Podʼи не запущені, це означає, що обʼєкти з попередніх кроків були видалені. У цьому випадку поверніться та створіть Deployment з посібника Використання kubectl для створення Deployment. Зачекайте кілька секунд та перегляньте список Podʼів знову. Ви можете продовжити, як тільки побачите, що один Pod працює.

+

Далі виведемо список наявних Serviceʼів у нашому кластері:

+

kubectl get services

+

У нас є Service з назвою kubernetes, яка створюється стандартно, коли minikube запускає кластер. Щоб створити новий Service та зробити зовнішній трафік доступним для нього, ми використовуватимемо команду expose з параметром NodePort.

+

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

+

Давайте знову запустимо команду get services:

+

kubectl get services

+

Тепер у нас є робочий Service з назвою kubernetes-bootcamp. Тут ми бачимо, що Service отримав унікальний IP в кластері, внутрішній порт та зовнішній IP (IP вузла).

+

Щоб дізнатися, який порт був відкритий ззовні (для Serviceʼу з type: NodePort), ми запустимо команду describe service:

+

kubectl describe services/kubernetes-bootcamp

+

Створимо змінну середовища з назвою NODE_PORT, яка матиме значення порту вузла:

+

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
+ echo "NODE_PORT=$NODE_PORT"

+

Тепер ми можемо перевірити, що застосунок отримав доступ за межі кластера, використовуючи curl, IP-адресу вузла та зовнішній порт:

+

curl http://"$(minikube ip):$NODE_PORT"

+ + {{< note >}} +

Якщо ви використовуєте minikube з Docker Desktop як драйвер контейнера, потрібно використовувати minikube tunnel. Це тому, що контейнери всередині Docker Desktop ізольовані від вашого компʼютера.
+

В окремому вікні термінала виконайте:
+ minikube service kubernetes-bootcamp --url

+

Вивід виглядає так: + 

http://127.0.0.1:51082
!  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.

+

Потім використовуйте вказаний URL для доступу до застосунку:
+ curl 127.0.0.1:51082

+ {{< /note >}} + +

І, ми отримуємо відповідь від сервера. Service — працює.

+
+
+ +
+
+

Крок 2: Використання міток

+
+

Deployment автоматично створив мітку для нашого Podʼа. За допомогою команди describe deployment ви можете побачити ім'я (ключ) цієї мітки:

+

kubectl describe deployment

+

Використаємо цю мітку для отримання списку наших Podʼів. Ми використовуватимемо команду kubectl get pods з -l як параметр, за яким слідують значення мітки:

+

kubectl get pods -l app=kubernetes-bootcamp

+

Ви можете зробити те саме, щоб вивести список поточних служб:

+

kubectl get services -l app=kubernetes-bootcamp

+

Отримайте назву Podʼа та збережіть її в змінній середовища POD_NAME:

+

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
+ echo "Name of the Pod: $POD_NAME"

+

Для застосування нової мітки ми використовуємо команду label за якою слідує тип обʼєкта, назва обʼєкта та нова мітка:

+

kubectl label pods "$POD_NAME" version=v1

+

Це додасть нову мітку до нашого Podʼа (ми закріпили версію програми для Podʼа), і ми можемо перевірити це за допомогою команди describe pod:

+

kubectl describe pods "$POD_NAME"

+

Тут ми бачимо, що мітка тепер прикріплена до нашого Podʼа. І тепер ми можемо отримати список Podʼів, використовуючи нову мітку:

+

kubectl get pods -l version=v1

+

І, ми бачимо Pod.

+
+
+ +
+
+

Крок 3: Видалення Service

+

Для видалення Service ви можете використовувати команду delete service. Тут також можна використовувати мітки:

+

kubectl delete service -l app=kubernetes-bootcamp

+

Переконайтеся, що Service видалено:

+

kubectl get services

+

Це підтверджує, що наш Service видалено. Щоб переконатися, що маршрут більше не відкритий, ви можете перевірити раніше відкриті IP та порт за допомогою curl:

+

curl http://"$(minikube ip):$NODE_PORT"

+

Це доводить, що застосунок більше не доступний ззовні кластера. Ви можете переконатись, що застосунок все ще працює за допомогою curl зсередини Podʼа:

+

kubectl exec -ti $POD_NAME -- curl http://localhost:8080

+

Тут ми бачимо, що застосунок працює. Це тому, що Deployment управляє застосунком. Для припинення роботи застосунку вам слід видалити також й Deployment.

+
+
+ +
+

+ Одразу, як тільки ви будете готові, переходьте до Запуску кількох екземплярів вашого застосунку. +

+
diff --git a/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html index 393e5959a47b2..1b0ab80930224 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/uk/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -1,6 +1,11 @@ --- -title: Інтерактивний урок - Масштабування застосунку +title: Інтерактивний урок — Масштабування застосунку weight: 20 +headless: true +toc_hide: true +_build: + list: never + publishResources: false --- @@ -9,32 +14,18 @@ - - - +
-
- -
- -
-
- Для роботи з терміналом використовуйте комп'ютер або планшет -
-
-
-
-
-
- Перейти до модуля 6› -
+
+

+ Вміст недоступний +

+

+ Інтерактивний урок зі створення кластера недоступний. За додатковою інформацією звертайтеся до оголошення про закриття. +

- - -
- diff --git a/content/uk/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/uk/docs/tutorials/kubernetes-basics/scale/scale-intro.html index c23b912493004..cc6ff262f18df 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/uk/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -1,6 +1,8 @@ --- -title: Запуск вашого застосунку на декількох Pod'ах +title: Запуск кількох екземплярів вашого застосунку weight: 10 +description: |- + Масштабування застосунку вручну за допомогою kubectl. --- @@ -9,137 +11,187 @@ - - -
- -
- -
- -
- -

Цілі

-
    - -
  • Масштабувати застосунок за допомогою kubectl.
    • -
-
- -
- -

Масштабування застосунку

- - -

У попередніх модулях ми створили Deployment і відкрили його для зовнішнього трафіка за допомогою Service. Deployment створив лише один Pod для запуску нашого застосунку. Коли трафік збільшиться, нам доведеться масштабувати застосунок, аби задовольнити вимоги користувачів.

- - -

Масштабування досягається шляхом зміни кількості реплік у Deployment'і.

- -
-
-
- -

Зміст:

+
+ +
+ +
+ +
+

Мета

    - -
  • Масштабування Deployment'а
    • +
  • Масштабування застосунку за допомогою kubectl.
-
- -

Кількість Pod'ів можна вказати одразу при створенні Deployment'а за допомогою параметра --replicas, під час запуску команди kubectl run

+ +
+

Масштабування Застосунку

+ +

Раніше ми створили Deployment, а потім робили його загальнодоступним за допомогою Service. Deployment створив лише один Pod для запуску нашого pfcnjceyre. Зі збільшенням трафіку, нам потрібно масштабувати застосунок, щоб відповідати зростаючим вимогам користувачів.

+

Якщо ви ще не працювали над попередніми розділами, почніть з Використання minikube для створення кластера.

+ +

Масштабування досягається зміною кількості реплік в Deployment

+ {{< note >}} +

Якщо ви виконуєте це завдання після попереднього розділу, можливо, ви видалили Service, що надавав доступ до Deploymentʼу. У цьому випадку, будь ласка, надайте доступ до Deploymentʼу командою:

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

+ {{< /note >}} +
+
+
+

Зміст:

+
    +
  • Масштабування Deployment
    • +
+
+
+

Ви можете створити Deployment з початку з декількома екземплярами, використовуючи параметр --replicas для команди створення Deployment kubectl

+
-
-
- -
-
-

Загальна інформація про масштабування

+
+ +
+
+

Огляд масштабування

+
-
- -
-
-
-
- -
- + +
+

+ Якщо ви готові, переходьте до Виконання поступового оновлення. +

+
+ +
+ +
+ + diff --git a/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html index b502e26f26655..b32a564d33fa2 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/uk/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -1,6 +1,11 @@ --- -title: Інтерактивний урок - Оновлення застосунку +title: Інтерактивний урок — Оновлення застосунку weight: 20 +headless: true +toc_hide: true +_build: + list: never + publishResources: false --- @@ -9,29 +14,18 @@ - - - +
-
- -
- -
-
- Для роботи з терміналом використовуйте комп'ютер або планшет -
-
-
-
-
-
- Повернутися до "Основ Kubernetes"› -
+
+

+ Вміст недоступний +

+

+ Інтерактивний урок зі створення кластера недоступний. За додатковою інформацією звертайтеся до оголошення про закриття. +

-
-
+
diff --git a/content/uk/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/uk/docs/tutorials/kubernetes-basics/update/update-intro.html index eec8a17b3e66b..c7b9d5938c87d 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/uk/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -1,6 +1,8 @@ --- -title: Виконання послідовного оновлення (rolling update) +title: Виконання поступового оновлення weight: 10 +description: |- + Виконання поетапного оновлення застосунку (rolling update) за допомогою kubectl. --- @@ -9,160 +11,183 @@ - - - -
- -
- -
- -
- -

Цілі

-
    - -
  • Виконати послідовне оновлення, використовуючи kubectl.
    • -
-
- -
- -

Оновлення застосунку

- - -

Користувачі очікують від застосунків високої доступності у будь-який час, а розробники - оновлення цих застосунків декілька разів на день. У Kubernetes це стає можливим завдяки послідовному оновленню. Послідовні оновлення дозволяють оновити Deployment без простою, шляхом послідовної заміни одних Pod'ів іншими. Нові Pod'и розподіляються по вузлах з доступними ресурсами.

- - -

У попередньому модулі ми масштабували наш застосунок, запустивши його на декількох Pod'ах. Масштабування - необхідна умова для проведення оновлень без шкоди для доступності застосунку. За типовими налаштуваннями, максимальна кількість Pod'ів, недоступних під час оновлення, і максимальна кількість нових Pod'ів, які можуть бути створені, дорівнює одиниці. Обидві опції можна налаштувати в числовому або відсотковому (від кількості Pod'ів) еквіваленті. - У Kubernetes оновлення версіонуються, тому кожне оновлення Deployment'а можна відкотити до попередньої (стабільної) версії.

- -
-
-
- -

Зміст:

+
+ +
+ +
+ +
+

Мета

    - -
  • Оновлення застосунку
    • +
  • Виконати розгортання з оновленням за допомогою kubectl.
-
- -

Послідовне оновлення дозволяє оновити Deployment без простою шляхом послідовної заміни одних Pod'ів іншими.

+ +
+

Оновлення застосунку

+ +

Користувачі очікують, що застосунки будуть доступні цілодобово, і очікується, що розробники розгортатимуть нові версії кілька разів на день. У Kubernetes це робиться за допомогою розгортань з поступовим оновленням. Поступове оновлення (rolling update) дозволяє виконати оновлення Deployment без перерви в роботі застосунку. Це досягається поетапною заміною поточних Podʼів новими. Нові Podʼи призначаються вузлам з вільними ресурсами, а Kubernetes чекає, доки ці нові Podʼи не почнуть працювати, перш ніж вилучити старі Podʼи.

+ +

У попередньому розділі ми масштабували наш застосунок для запуску кількох екземплярів. Це є вимогою для виконання оновлень без впливу на доступність застосунку. Стандартно максимальна кількість Podʼів, які можуть бути недоступні під час оновлення, та максимальна кількість нових Podʼів, які можуть бути створені, дорівнює одному. Обидві опції можуть бути налаштовані як у вигляді точної кількості, так і у відсотках (від усіх Podʼів). + У Kubernetes оновлення мають версії, і будь-яке оновлення Deployment може бути повернуте до попередньої (стабільної) версії.

+ +
+
+
+

Зміст:

+
    +
  • Оновлення застосунку
    • +
+
+
+

Поступові оновлення дозволяють виконувати оновлення Deployment без зупинки роботи застосунку за допомогою поетапного оновлення екземплярів Podʼів.

+
-
-
- -
-
-

Загальна інформація про послідовне оновлення

+
+ +
+
+

Огляд поступового оновлення

+
-
-
-
-
-
- -
- +
+
+

Не забудьте очистити свій локальний кластер

+

kubectl delete deployments/kubernetes-bootcamp services/kubernetes-bootcamp +

+
+ +
+ +
+ diff --git a/content/uk/docs/tutorials/security/_index.md b/content/uk/docs/tutorials/security/_index.md new file mode 100644 index 0000000000000..49accadce320a --- /dev/null +++ b/content/uk/docs/tutorials/security/_index.md @@ -0,0 +1,8 @@ +--- +title: Безпека +weight: 40 +--- + +Безпека є важливою проблемою для більшості організацій та людей, які використовують кластери Kubernetes. Ви можете знайти базовий [список перевірок безпеки](/docs/concepts/security/security-checklist/) в іншому місці документації Kubernetes. + +Щоб дізнатися, як розгорнути та керувати аспектами безпеки Kubernetes, ви можете виконати практичні завдання в цьому розділі. diff --git a/content/uk/docs/tutorials/services/_index.md b/content/uk/docs/tutorials/services/_index.md new file mode 100644 index 0000000000000..6ce3d8b6b0865 --- /dev/null +++ b/content/uk/docs/tutorials/services/_index.md @@ -0,0 +1,4 @@ +--- +title: "Services" +weight: 70 +--- diff --git a/content/uk/docs/tutorials/stateful-application/_index.md b/content/uk/docs/tutorials/stateful-application/_index.md new file mode 100644 index 0000000000000..feadf6b5fa6d8 --- /dev/null +++ b/content/uk/docs/tutorials/stateful-application/_index.md @@ -0,0 +1,4 @@ +--- +title: "Stateful застосунки" +weight: 60 +--- diff --git a/content/uk/docs/tutorials/stateless-application/_index.md b/content/uk/docs/tutorials/stateless-application/_index.md new file mode 100644 index 0000000000000..5199373ffaedb --- /dev/null +++ b/content/uk/docs/tutorials/stateless-application/_index.md @@ -0,0 +1,4 @@ +--- +title: "Stateless застосунки" +weight: 50 +--- \ No newline at end of file diff --git a/content/uk/examples/README.md b/content/uk/examples/README.md new file mode 100644 index 0000000000000..cd79181c4e523 --- /dev/null +++ b/content/uk/examples/README.md @@ -0,0 +1,11 @@ +Щоб запустити тести для локалізації, скористайтеся наступною командою: + +```shell +go test k8s.io/website/content//examples +``` + +де `` — це двосимвольне позначення мови. Наприклад: + +```shell +go test k8s.io/website/content/en/examples +``` diff --git a/content/uk/examples/access/certificate-signing-request/clusterrole-approve.yaml b/content/uk/examples/access/certificate-signing-request/clusterrole-approve.yaml new file mode 100644 index 0000000000000..e5bcfdc44e2d8 --- /dev/null +++ b/content/uk/examples/access/certificate-signing-request/clusterrole-approve.yaml @@ -0,0 +1,28 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: csr-approver +rules: +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests + verbs: + - get + - list + - watch +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests/approval + verbs: + - update +- apiGroups: + - certificates.k8s.io + resources: + - signers + resourceNames: + - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain + verbs: + - approve + diff --git a/content/uk/examples/access/certificate-signing-request/clusterrole-create.yaml b/content/uk/examples/access/certificate-signing-request/clusterrole-create.yaml new file mode 100644 index 0000000000000..def1b879d8e88 --- /dev/null +++ b/content/uk/examples/access/certificate-signing-request/clusterrole-create.yaml @@ -0,0 +1,14 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: csr-creator +rules: +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests + verbs: + - create + - get + - list + - watch diff --git a/content/uk/examples/access/certificate-signing-request/clusterrole-sign.yaml b/content/uk/examples/access/certificate-signing-request/clusterrole-sign.yaml new file mode 100644 index 0000000000000..6d1a2f7882cd1 --- /dev/null +++ b/content/uk/examples/access/certificate-signing-request/clusterrole-sign.yaml @@ -0,0 +1,27 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: csr-signer +rules: +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests + verbs: + - get + - list + - watch +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests/status + verbs: + - update +- apiGroups: + - certificates.k8s.io + resources: + - signers + resourceNames: + - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain + verbs: + - sign diff --git a/content/uk/examples/access/deployment-replicas-policy.yaml b/content/uk/examples/access/deployment-replicas-policy.yaml new file mode 100644 index 0000000000000..e12a8a0961fad --- /dev/null +++ b/content/uk/examples/access/deployment-replicas-policy.yaml @@ -0,0 +1,19 @@ +apiVersion: admissionregistration.k8s.io/v1alpha1 +kind: ValidatingAdmissionPolicy +metadata: + name: "deploy-replica-policy.example.com" +spec: + paramKind: + apiVersion: rules.example.com/v1 + kind: ReplicaLimit + matchConstraints: + resourceRules: + - apiGroups: ["apps"] + apiVersions: ["v1"] + operations: ["CREATE", "UPDATE"] + resources: ["deployments"] + validations: + - expression: "object.spec.replicas <= params.maxReplicas" + messageExpression: "'object.spec.replicas must be no greater than ' + string(params.maxReplicas)" + reason: Invalid + diff --git a/content/uk/examples/access/endpoints-aggregated.yaml b/content/uk/examples/access/endpoints-aggregated.yaml new file mode 100644 index 0000000000000..d238820056afb --- /dev/null +++ b/content/uk/examples/access/endpoints-aggregated.yaml @@ -0,0 +1,20 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + annotations: + kubernetes.io/description: |- + Add endpoints write permissions to the edit and admin roles. This was + removed by default in 1.22 because of CVE-2021-25740. See + https://issue.k8s.io/103675. This can allow writers to direct LoadBalancer + or Ingress implementations to expose backend IPs that would not otherwise + be accessible, and can circumvent network policies or security controls + intended to prevent/isolate access to those backends. + EndpointSlices were never included in the edit or admin roles, so there + is nothing to restore for the EndpointSlice API. + labels: + rbac.authorization.k8s.io/aggregate-to-edit: "true" + name: custom:aggregate-to-edit:endpoints # you can change this if you wish +rules: + - apiGroups: [""] + resources: ["endpoints"] + verbs: ["create", "delete", "deletecollection", "patch", "update"] diff --git a/content/uk/examples/access/image-matches-namespace-environment.policy.yaml b/content/uk/examples/access/image-matches-namespace-environment.policy.yaml new file mode 100644 index 0000000000000..a68204aaa7945 --- /dev/null +++ b/content/uk/examples/access/image-matches-namespace-environment.policy.yaml @@ -0,0 +1,29 @@ +# Ця політика забезпечує виконання умови, що всі контейнери deployment мають співпадати з репозиторієм образів, яке відповідає мітці середовища його простору імен. +# За винятком розгортань, позначених як "exempt", або будь-яких контейнерів, які не належать організації "example.com" (наприклад, загальні sidecar). +# Наприклад, якщо у просторі імен є мітка {"environment": "staging"}, всі контейнери повинні мати репозиторій, який є або staging.example.com/* +# або не містить "example.com" взагалі, якщо розгортання має мітку {"exempt": "true"}. + +apiVersion: admissionregistration.k8s.io/v1beta1 +kind: ValidatingAdmissionPolicy +metadata: + name: "image-matches-namespace-environment.policy.example.com" +spec: + failurePolicy: Fail + matchConstraints: + resourceRules: + - apiGroups: ["apps"] + apiVersions: ["v1"] + operations: ["CREATE", "UPDATE"] + resources: ["deployments"] + variables: + - name: environment + expression: "'environment' in namespaceObject.metadata.labels ? namespaceObject.metadata.labels['environment'] : 'prod'" + - name: exempt + expression: "'exempt' in object.metadata.labels && object.metadata.labels['exempt'] == 'true'" + - name: containers + expression: "object.spec.template.spec.containers" + - name: containersToCheck + expression: "variables.containers.filter(c, c.image.contains('example.com/'))" + validations: + - expression: "variables.exempt || variables.containersToCheck.all(c, c.image.startsWith(variables.environment + '.'))" + messageExpression: "'only ' + variables.environment + ' images are allowed in namespace ' + namespaceObject.metadata.name" \ No newline at end of file diff --git a/content/uk/examples/access/validating-admission-policy-audit-annotation.yaml b/content/uk/examples/access/validating-admission-policy-audit-annotation.yaml new file mode 100644 index 0000000000000..5a7a20ac56af4 --- /dev/null +++ b/content/uk/examples/access/validating-admission-policy-audit-annotation.yaml @@ -0,0 +1,16 @@ +apiVersion: admissionregistration.k8s.io/v1alpha1 +kind: ValidatingAdmissionPolicy +metadata: + name: "demo-policy.example.com" +spec: + failurePolicy: Fail + matchConstraints: + resourceRules: + - apiGroups: ["apps"] + apiVersions: ["v1"] + operations: ["CREATE", "UPDATE"] + resources: ["deployments"] + validations: + - key: "high-replica-count" + expression: "object.spec.replicas > 50" + messageExpression: "'Deployment spec.replicas set to ' + string(object.spec.replicas)" diff --git a/content/uk/examples/access/validating-admission-policy-match-conditions.yaml b/content/uk/examples/access/validating-admission-policy-match-conditions.yaml new file mode 100644 index 0000000000000..9a49adf15212c --- /dev/null +++ b/content/uk/examples/access/validating-admission-policy-match-conditions.yaml @@ -0,0 +1,22 @@ +apiVersion: admissionregistration.k8s.io/v1alpha1 +kind: ValidatingAdmissionPolicy +metadata: + name: "demo-policy.example.com" +spec: + failurePolicy: Fail + matchConstraints: + resourceRules: + - apiGroups: ["*"] + apiVersions: ["*"] + operations: ["CREATE", "UPDATE"] + resources: ["*"] + matchConditions: + - name: 'exclude-leases' # Each match condition must have a unique name + expression: '!(request.resource.group == "coordination.k8s.io" && request.resource.resource == "leases")' # Match non-lease resources. + - name: 'exclude-kubelet-requests' + expression: '!("system:nodes" in request.userInfo.groups)' # Match requests made by non-node users. + - name: 'rbac' # Skip RBAC requests. + expression: 'request.resource.group != "rbac.authorization.k8s.io"' + validations: + - expression: "!object.metadata.name.contains('demo') || object.metadata.namespace == 'demo'" + diff --git a/content/uk/examples/admin/cloud/ccm-example.yaml b/content/uk/examples/admin/cloud/ccm-example.yaml new file mode 100644 index 0000000000000..16a22a22ca344 --- /dev/null +++ b/content/uk/examples/admin/cloud/ccm-example.yaml @@ -0,0 +1,73 @@ +# Це приклад налаштування cloud-controller-manager як Daemonset у вашому кластері. +# Він передбачає, що ваші мастери можуть запускати Podʼи та мають роль node-role.kubernetes.io/master. +# Зверніть увагу, що цей Daemonset не працюватиме безпосередньо з коробки для вашого хмарного середовища, це +# призначено як рекомендація. + +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: cloud-controller-manager + namespace: kube-system +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: system:cloud-controller-manager +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: cluster-admin +subjects: +- kind: ServiceAccount + name: cloud-controller-manager + namespace: kube-system +--- +apiVersion: apps/v1 +kind: DaemonSet +metadata: + labels: + k8s-app: cloud-controller-manager + name: cloud-controller-manager + namespace: kube-system +spec: + selector: + matchLabels: + k8s-app: cloud-controller-manager + template: + metadata: + labels: + k8s-app: cloud-controller-manager + spec: + serviceAccountName: cloud-controller-manager + containers: + - name: cloud-controller-manager + # for in-tree providers we use registry.k8s.io/cloud-controller-manager + # this can be replaced with any other image for out-of-tree providers + image: registry.k8s.io/cloud-controller-manager:v1.8.0 + command: + - /usr/local/bin/cloud-controller-manager + - --cloud-provider=[YOUR_CLOUD_PROVIDER] # Add your own cloud provider here! + - --leader-elect=true + - --use-service-account-credentials + # these flags will vary for every cloud provider + - --allocate-node-cidrs=true + - --configure-cloud-routes=true + - --cluster-cidr=172.17.0.0/16 + tolerations: + # this is required so CCM can bootstrap itself + - key: node.cloudprovider.kubernetes.io/uninitialized + value: "true" + effect: NoSchedule + # these tolerations are to have the daemonset runnable on control plane nodes + # remove them if your control plane nodes should not run pods + - key: node-role.kubernetes.io/control-plane + operator: Exists + effect: NoSchedule + - key: node-role.kubernetes.io/master + operator: Exists + effect: NoSchedule + # this is to restrict CCM to only run on master nodes + # the node selector may vary depending on your cluster setup + nodeSelector: + node-role.kubernetes.io/master: "" diff --git a/content/uk/examples/admin/dns/busybox.yaml b/content/uk/examples/admin/dns/busybox.yaml new file mode 100644 index 0000000000000..31f009d307291 --- /dev/null +++ b/content/uk/examples/admin/dns/busybox.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox + namespace: default +spec: + containers: + - name: busybox + image: busybox:1.28 + command: + - sleep + - "3600" + imagePullPolicy: IfNotPresent + restartPolicy: Always diff --git a/content/uk/examples/admin/dns/dns-horizontal-autoscaler.yaml b/content/uk/examples/admin/dns/dns-horizontal-autoscaler.yaml new file mode 100644 index 0000000000000..3182fed3c8052 --- /dev/null +++ b/content/uk/examples/admin/dns/dns-horizontal-autoscaler.yaml @@ -0,0 +1,87 @@ +kind: ServiceAccount +apiVersion: v1 +metadata: + name: kube-dns-autoscaler + namespace: kube-system +--- +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:kube-dns-autoscaler +rules: + - apiGroups: [""] + resources: ["nodes"] + verbs: ["list", "watch"] + - apiGroups: [""] + resources: ["replicationcontrollers/scale"] + verbs: ["get", "update"] + - apiGroups: ["apps"] + resources: ["deployments/scale", "replicasets/scale"] + verbs: ["get", "update"] +# Remove the configmaps rule once below issue is fixed: +# kubernetes-incubator/cluster-proportional-autoscaler#16 + - apiGroups: [""] + resources: ["configmaps"] + verbs: ["get", "create"] +--- +kind: ClusterRoleBinding +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:kube-dns-autoscaler +subjects: + - kind: ServiceAccount + name: kube-dns-autoscaler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:kube-dns-autoscaler + apiGroup: rbac.authorization.k8s.io + +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: kube-dns-autoscaler + namespace: kube-system + labels: + k8s-app: kube-dns-autoscaler + kubernetes.io/cluster-service: "true" +spec: + selector: + matchLabels: + k8s-app: kube-dns-autoscaler + template: + metadata: + labels: + k8s-app: kube-dns-autoscaler + spec: + priorityClassName: system-cluster-critical + securityContext: + seccompProfile: + type: RuntimeDefault + supplementalGroups: [ 65534 ] + fsGroup: 65534 + nodeSelector: + kubernetes.io/os: linux + containers: + - name: autoscaler + image: registry.k8s.io/cpa/cluster-proportional-autoscaler:1.8.4 + resources: + requests: + cpu: "20m" + memory: "10Mi" + command: + - /cluster-proportional-autoscaler + - --namespace=kube-system + - --configmap=kube-dns-autoscaler + # Should keep target in sync with cluster/addons/dns/kube-dns.yaml.base + - --target= + # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate. + # If using small nodes, "nodesPerReplica" should dominate. + - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true,"includeUnschedulableNodes":true}} + - --logtostderr=true + - --v=2 + tolerations: + - key: "CriticalAddonsOnly" + operator: "Exists" + serviceAccountName: kube-dns-autoscaler diff --git a/content/uk/examples/admin/dns/dnsutils.yaml b/content/uk/examples/admin/dns/dnsutils.yaml new file mode 100644 index 0000000000000..e1b3ace336f99 --- /dev/null +++ b/content/uk/examples/admin/dns/dnsutils.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dnsutils + namespace: default +spec: + containers: + - name: dnsutils + image: registry.k8s.io/e2e-test-images/jessie-dnsutils:1.3 + command: + - sleep + - "infinity" + imagePullPolicy: IfNotPresent + restartPolicy: Always diff --git a/content/uk/examples/admin/konnectivity/egress-selector-configuration.yaml b/content/uk/examples/admin/konnectivity/egress-selector-configuration.yaml new file mode 100644 index 0000000000000..590b03a7456ed --- /dev/null +++ b/content/uk/examples/admin/konnectivity/egress-selector-configuration.yaml @@ -0,0 +1,21 @@ +apiVersion: apiserver.k8s.io/v1beta1 +kind: EgressSelectorConfiguration +egressSelections: +# Оскільки ми хочемо контролювати вихідний трафік з кластеру, ми використовуємо +# "cluster" як назву. Інші підтримувані значення: "etcd" та "controlplane". +- name: cluster + connection: + # Це керує протоколом між API-сервером та сервером Konnectivity. + # Підтримувані значення: "GRPC" та "HTTPConnect". Між двома режимами + # немає відмінностей для кінцевого користувача. Вам потрібно встановити + # сервер Konnectivity в тому ж режимі. + proxyProtocol: GRPC + transport: + # Це керує транспортом, який використовує API-сервер для спілкування з + # сервером Konnectivity. Якщо сервер Konnectivity розташований на тому ж + # компʼютері, рекомендується використовувати UDS. Вам потрібно налаштувати + # сервер Konnectivity на прослуховування того самого UDS-сокету. + # Інший підтримуваний транспорт - "tcp". Вам потрібно налаштувати TLS-конфігурацію + # для захисту TCP-транспорту. + uds: + udsName: /etc/kubernetes/konnectivity-server/konnectivity-server.socket diff --git a/content/uk/examples/admin/konnectivity/konnectivity-agent.yaml b/content/uk/examples/admin/konnectivity/konnectivity-agent.yaml new file mode 100644 index 0000000000000..829fa07f2d7a7 --- /dev/null +++ b/content/uk/examples/admin/konnectivity/konnectivity-agent.yaml @@ -0,0 +1,54 @@ +apiVersion: apps/v1 +# Instead of this, you can deploy agents as Deployments. It is not necessary to have an agent on each node. +kind: DaemonSet +metadata: + labels: + addonmanager.kubernetes.io/mode: Reconcile + k8s-app: konnectivity-agent + namespace: kube-system + name: konnectivity-agent +spec: + selector: + matchLabels: + k8s-app: konnectivity-agent + template: + metadata: + labels: + k8s-app: konnectivity-agent + spec: + priorityClassName: system-cluster-critical + tolerations: + - key: "CriticalAddonsOnly" + operator: "Exists" + containers: + - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.37 + name: konnectivity-agent + command: ["/proxy-agent"] + args: [ + "--logtostderr=true", + "--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt", + # Оскільки сервер konnectivity працює з hostNetwork=true, + # це є IP-адреса машини-майстра. + "--proxy-server-host=35.225.206.7", + "--proxy-server-port=8132", + "--admin-server-port=8133", + "--health-server-port=8134", + "--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token" + ] + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: konnectivity-agent-token + livenessProbe: + httpGet: + port: 8134 + path: /healthz + initialDelaySeconds: 15 + timeoutSeconds: 15 + serviceAccountName: konnectivity-agent + volumes: + - name: konnectivity-agent-token + projected: + sources: + - serviceAccountToken: + path: konnectivity-agent-token + audience: system:konnectivity-server diff --git a/content/uk/examples/admin/konnectivity/konnectivity-rbac.yaml b/content/uk/examples/admin/konnectivity/konnectivity-rbac.yaml new file mode 100644 index 0000000000000..7687f49b77e82 --- /dev/null +++ b/content/uk/examples/admin/konnectivity/konnectivity-rbac.yaml @@ -0,0 +1,24 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: system:konnectivity-server + labels: + kubernetes.io/cluster-service: "true" + addonmanager.kubernetes.io/mode: Reconcile +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: system:auth-delegator +subjects: + - apiGroup: rbac.authorization.k8s.io + kind: User + name: system:konnectivity-server +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: konnectivity-agent + namespace: kube-system + labels: + kubernetes.io/cluster-service: "true" + addonmanager.kubernetes.io/mode: Reconcile diff --git a/content/uk/examples/admin/konnectivity/konnectivity-server.yaml b/content/uk/examples/admin/konnectivity/konnectivity-server.yaml new file mode 100644 index 0000000000000..b49685de1d7a6 --- /dev/null +++ b/content/uk/examples/admin/konnectivity/konnectivity-server.yaml @@ -0,0 +1,73 @@ +apiVersion: v1 +kind: Pod +metadata: + name: konnectivity-server + namespace: kube-system +spec: + priorityClassName: system-cluster-critical + hostNetwork: true + containers: + - name: konnectivity-server-container + image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.37 + command: ["/proxy-server"] + args: [ + "--logtostderr=true", + # Це повинно збігатися зі значенням, встановленим у egressSelectorConfiguration. + "--uds-name=/etc/kubernetes/konnectivity-server/konnectivity-server.socket", + "--delete-existing-uds-file", + # Наступні два рядки передбачають, що сервер Konnectivity + # розгорнуто на тому ж компʼютері, що й apiserver, і сертифікати та + # ключ API-сервера знаходяться за вказаною шляхом. + "--cluster-cert=/etc/kubernetes/pki/apiserver.crt", + "--cluster-key=/etc/kubernetes/pki/apiserver.key", + # Це повинно збігатися зі значенням, встановленим у egressSelectorConfiguration. + "--mode=grpc", + "--server-port=0", + "--agent-port=8132", + "--admin-port=8133", + "--health-port=8134", + "--agent-namespace=kube-system", + "--agent-service-account=konnectivity-agent", + "--kubeconfig=/etc/kubernetes/konnectivity-server.conf", + "--authentication-audience=system:konnectivity-server" + ] + livenessProbe: + httpGet: + scheme: HTTP + host: 127.0.0.1 + port: 8134 + path: /healthz + initialDelaySeconds: 30 + timeoutSeconds: 60 + ports: + - name: agentport + containerPort: 8132 + hostPort: 8132 + - name: adminport + containerPort: 8133 + hostPort: 8133 + - name: healthport + containerPort: 8134 + hostPort: 8134 + volumeMounts: + - name: k8s-certs + mountPath: /etc/kubernetes/pki + readOnly: true + - name: kubeconfig + mountPath: /etc/kubernetes/konnectivity-server.conf + readOnly: true + - name: konnectivity-uds + mountPath: /etc/kubernetes/konnectivity-server + readOnly: false + volumes: + - name: k8s-certs + hostPath: + path: /etc/kubernetes/pki + - name: kubeconfig + hostPath: + path: /etc/kubernetes/konnectivity-server.conf + type: FileOrCreate + - name: konnectivity-uds + hostPath: + path: /etc/kubernetes/konnectivity-server + type: DirectoryOrCreate diff --git a/content/uk/examples/admin/logging/fluentd-sidecar-config.yaml b/content/uk/examples/admin/logging/fluentd-sidecar-config.yaml new file mode 100644 index 0000000000000..eea1849b033fa --- /dev/null +++ b/content/uk/examples/admin/logging/fluentd-sidecar-config.yaml @@ -0,0 +1,25 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: fluentd-config +data: + fluentd.conf: | + + type tail + format none + path /var/log/1.log + pos_file /var/log/1.log.pos + tag count.format1 + + + + type tail + format none + path /var/log/2.log + pos_file /var/log/2.log.pos + tag count.format2 + + + + type google_cloud + diff --git a/content/uk/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml b/content/uk/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml new file mode 100644 index 0000000000000..a621a9fb2acce --- /dev/null +++ b/content/uk/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml @@ -0,0 +1,39 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox:1.28 + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-agent + image: registry.k8s.io/fluentd-gcp:1.30 + env: + - name: FLUENTD_ARGS + value: -c /etc/fluentd-config/fluentd.conf + volumeMounts: + - name: varlog + mountPath: /var/log + - name: config-volume + mountPath: /etc/fluentd-config + volumes: + - name: varlog + emptyDir: {} + - name: config-volume + configMap: + name: fluentd-config diff --git a/content/uk/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml b/content/uk/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml new file mode 100644 index 0000000000000..ac19efe4a2350 --- /dev/null +++ b/content/uk/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml @@ -0,0 +1,38 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox:1.28 + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-log-1 + image: busybox:1.28 + args: [/bin/sh, -c, 'tail -n+1 -F /var/log/1.log'] + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-log-2 + image: busybox:1.28 + args: [/bin/sh, -c, 'tail -n+1 -F /var/log/2.log'] + volumeMounts: + - name: varlog + mountPath: /var/log + volumes: + - name: varlog + emptyDir: {} diff --git a/content/uk/examples/admin/logging/two-files-counter-pod.yaml b/content/uk/examples/admin/logging/two-files-counter-pod.yaml new file mode 100644 index 0000000000000..31bbed3cf8683 --- /dev/null +++ b/content/uk/examples/admin/logging/two-files-counter-pod.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox:1.28 + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + volumes: + - name: varlog + emptyDir: {} diff --git a/content/uk/examples/admin/namespace-dev.json b/content/uk/examples/admin/namespace-dev.json new file mode 100644 index 0000000000000..cb3ed7cdc1efa --- /dev/null +++ b/content/uk/examples/admin/namespace-dev.json @@ -0,0 +1,10 @@ +{ + "apiVersion": "v1", + "kind": "Namespace", + "metadata": { + "name": "development", + "labels": { + "name": "development" + } + } +} diff --git a/content/uk/examples/admin/namespace-dev.yaml b/content/uk/examples/admin/namespace-dev.yaml new file mode 100644 index 0000000000000..5e753b693f03b --- /dev/null +++ b/content/uk/examples/admin/namespace-dev.yaml @@ -0,0 +1,6 @@ +apiVersion: v1 +kind: Namespace +metadata: + name: development + labels: + name: development diff --git a/content/uk/examples/admin/namespace-prod.json b/content/uk/examples/admin/namespace-prod.json new file mode 100644 index 0000000000000..878ba7866ca59 --- /dev/null +++ b/content/uk/examples/admin/namespace-prod.json @@ -0,0 +1,10 @@ +{ + "apiVersion": "v1", + "kind": "Namespace", + "metadata": { + "name": "production", + "labels": { + "name": "production" + } + } +} diff --git a/content/uk/examples/admin/namespace-prod.yaml b/content/uk/examples/admin/namespace-prod.yaml new file mode 100644 index 0000000000000..761d6325cb404 --- /dev/null +++ b/content/uk/examples/admin/namespace-prod.yaml @@ -0,0 +1,6 @@ +apiVersion: v1 +kind: Namespace +metadata: + name: production + labels: + name: production diff --git a/content/uk/examples/admin/resource/cpu-constraints-pod-2.yaml b/content/uk/examples/admin/resource/cpu-constraints-pod-2.yaml new file mode 100644 index 0000000000000..b5c7348f26ee0 --- /dev/null +++ b/content/uk/examples/admin/resource/cpu-constraints-pod-2.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-cpu-demo-2 +spec: + containers: + - name: constraints-cpu-demo-2-ctr + image: nginx + resources: + limits: + cpu: "1.5" + requests: + cpu: "500m" diff --git a/content/uk/examples/admin/resource/cpu-constraints-pod-3.yaml b/content/uk/examples/admin/resource/cpu-constraints-pod-3.yaml new file mode 100644 index 0000000000000..0a2083acd8ec6 --- /dev/null +++ b/content/uk/examples/admin/resource/cpu-constraints-pod-3.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-cpu-demo-3 +spec: + containers: + - name: constraints-cpu-demo-3-ctr + image: nginx + resources: + limits: + cpu: "800m" + requests: + cpu: "100m" diff --git a/content/uk/examples/admin/resource/cpu-constraints-pod-4.yaml b/content/uk/examples/admin/resource/cpu-constraints-pod-4.yaml new file mode 100644 index 0000000000000..3c102158db509 --- /dev/null +++ b/content/uk/examples/admin/resource/cpu-constraints-pod-4.yaml @@ -0,0 +1,8 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-cpu-demo-4 +spec: + containers: + - name: constraints-cpu-demo-4-ctr + image: vish/stress diff --git a/content/uk/examples/admin/resource/cpu-constraints-pod.yaml b/content/uk/examples/admin/resource/cpu-constraints-pod.yaml new file mode 100644 index 0000000000000..7db23f26c8842 --- /dev/null +++ b/content/uk/examples/admin/resource/cpu-constraints-pod.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-cpu-demo +spec: + containers: + - name: constraints-cpu-demo-ctr + image: nginx + resources: + limits: + cpu: "800m" + requests: + cpu: "500m" diff --git a/content/uk/examples/admin/resource/cpu-constraints.yaml b/content/uk/examples/admin/resource/cpu-constraints.yaml new file mode 100644 index 0000000000000..6fc4239027c86 --- /dev/null +++ b/content/uk/examples/admin/resource/cpu-constraints.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: cpu-min-max-demo-lr +spec: + limits: + - max: + cpu: "800m" + min: + cpu: "200m" + type: Container diff --git a/content/uk/examples/admin/resource/cpu-defaults-pod-2.yaml b/content/uk/examples/admin/resource/cpu-defaults-pod-2.yaml new file mode 100644 index 0000000000000..9ca216dee1557 --- /dev/null +++ b/content/uk/examples/admin/resource/cpu-defaults-pod-2.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-cpu-demo-2 +spec: + containers: + - name: default-cpu-demo-2-ctr + image: nginx + resources: + limits: + cpu: "1" diff --git a/content/uk/examples/admin/resource/cpu-defaults-pod-3.yaml b/content/uk/examples/admin/resource/cpu-defaults-pod-3.yaml new file mode 100644 index 0000000000000..214cdee34bfff --- /dev/null +++ b/content/uk/examples/admin/resource/cpu-defaults-pod-3.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-cpu-demo-3 +spec: + containers: + - name: default-cpu-demo-3-ctr + image: nginx + resources: + requests: + cpu: "0.75" diff --git a/content/uk/examples/admin/resource/cpu-defaults-pod.yaml b/content/uk/examples/admin/resource/cpu-defaults-pod.yaml new file mode 100644 index 0000000000000..56b06d9a690e5 --- /dev/null +++ b/content/uk/examples/admin/resource/cpu-defaults-pod.yaml @@ -0,0 +1,8 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-cpu-demo +spec: + containers: + - name: default-cpu-demo-ctr + image: nginx diff --git a/content/uk/examples/admin/resource/cpu-defaults.yaml b/content/uk/examples/admin/resource/cpu-defaults.yaml new file mode 100644 index 0000000000000..b53d297181683 --- /dev/null +++ b/content/uk/examples/admin/resource/cpu-defaults.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: cpu-limit-range +spec: + limits: + - default: + cpu: 1 + defaultRequest: + cpu: 0.5 + type: Container diff --git a/content/uk/examples/admin/resource/limit-mem-cpu-container.yaml b/content/uk/examples/admin/resource/limit-mem-cpu-container.yaml new file mode 100644 index 0000000000000..3c2b30f29ccef --- /dev/null +++ b/content/uk/examples/admin/resource/limit-mem-cpu-container.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: limit-mem-cpu-per-container +spec: + limits: + - max: + cpu: "800m" + memory: "1Gi" + min: + cpu: "100m" + memory: "99Mi" + default: + cpu: "700m" + memory: "900Mi" + defaultRequest: + cpu: "110m" + memory: "111Mi" + type: Container diff --git a/content/uk/examples/admin/resource/limit-mem-cpu-pod.yaml b/content/uk/examples/admin/resource/limit-mem-cpu-pod.yaml new file mode 100644 index 0000000000000..0ce0f69ac8130 --- /dev/null +++ b/content/uk/examples/admin/resource/limit-mem-cpu-pod.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: limit-mem-cpu-per-pod +spec: + limits: + - max: + cpu: "2" + memory: "2Gi" + type: Pod diff --git a/content/uk/examples/admin/resource/limit-memory-ratio-pod.yaml b/content/uk/examples/admin/resource/limit-memory-ratio-pod.yaml new file mode 100644 index 0000000000000..859fc20ecec38 --- /dev/null +++ b/content/uk/examples/admin/resource/limit-memory-ratio-pod.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: limit-memory-ratio-pod +spec: + limits: + - maxLimitRequestRatio: + memory: 2 + type: Pod diff --git a/content/uk/examples/admin/resource/limit-range-pod-1.yaml b/content/uk/examples/admin/resource/limit-range-pod-1.yaml new file mode 100644 index 0000000000000..b9bd20d06a2c7 --- /dev/null +++ b/content/uk/examples/admin/resource/limit-range-pod-1.yaml @@ -0,0 +1,37 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox1 +spec: + containers: + - name: busybox-cnt01 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt02 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + - name: busybox-cnt03 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt03; sleep 10;done"] + resources: + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt04 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt04; sleep 10;done"] diff --git a/content/uk/examples/admin/resource/limit-range-pod-2.yaml b/content/uk/examples/admin/resource/limit-range-pod-2.yaml new file mode 100644 index 0000000000000..40da19c1aee05 --- /dev/null +++ b/content/uk/examples/admin/resource/limit-range-pod-2.yaml @@ -0,0 +1,37 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox2 +spec: + containers: + - name: busybox-cnt01 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt02 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + - name: busybox-cnt03 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt03; sleep 10;done"] + resources: + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt04 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt04; sleep 10;done"] diff --git a/content/uk/examples/admin/resource/limit-range-pod-3.yaml b/content/uk/examples/admin/resource/limit-range-pod-3.yaml new file mode 100644 index 0000000000000..5b6b835e38b62 --- /dev/null +++ b/content/uk/examples/admin/resource/limit-range-pod-3.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox3 +spec: + containers: + - name: busybox-cnt01 + image: busybox:1.28 + command: ["sleep", "3600"] + resources: + limits: + memory: "300Mi" + requests: + memory: "100Mi" diff --git a/content/uk/examples/admin/resource/memory-available-cgroupv2.sh b/content/uk/examples/admin/resource/memory-available-cgroupv2.sh new file mode 100644 index 0000000000000..804e29d051016 --- /dev/null +++ b/content/uk/examples/admin/resource/memory-available-cgroupv2.sh @@ -0,0 +1,30 @@ +#!/bin/bash + +# Цей скрипт відтворює те, що робить kubelet +# для розрахунку доступної памʼяті відносно kubepods cgroup. + +# поточне використання памʼяті +memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}') +memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024)) +memory_usage_in_bytes=$(cat /sys/fs/cgroup/kubepods.slice/memory.current) +memory_total_inactive_file=$(cat /sys/fs/cgroup/kubepods.slice/memory.stat | grep inactive_file | awk '{print $2}') + +memory_working_set=${memory_usage_in_bytes} +if [ "$memory_working_set" -lt "$memory_total_inactive_file" ]; +then + memory_working_set=0 +else + memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file)) +fi + +memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set)) +memory_available_in_kb=$((memory_available_in_bytes / 1024)) +memory_available_in_mb=$((memory_available_in_kb / 1024)) + +echo "memory.capacity_in_bytes $memory_capacity_in_bytes" +echo "memory.usage_in_bytes $memory_usage_in_bytes" +echo "memory.total_inactive_file $memory_total_inactive_file" +echo "memory.working_set $memory_working_set" +echo "memory.available_in_bytes $memory_available_in_bytes" +echo "memory.available_in_kb $memory_available_in_kb" +echo "memory.available_in_mb $memory_available_in_mb" diff --git a/content/uk/examples/admin/resource/memory-available.sh b/content/uk/examples/admin/resource/memory-available.sh new file mode 100644 index 0000000000000..de97a5bf607d2 --- /dev/null +++ b/content/uk/examples/admin/resource/memory-available.sh @@ -0,0 +1,31 @@ +#!/bin/bash +#!/usr/bin/env bash + +# Цей скрипт відтворює те, що робить kubelet +# для розрахунку доступної памʼяті відносно root cgroup. + +# поточне використання памʼяті +memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}') +memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024)) +memory_usage_in_bytes=$(cat /sys/fs/cgroup/memory/memory.usage_in_bytes) +memory_total_inactive_file=$(cat /sys/fs/cgroup/memory/memory.stat | grep total_inactive_file | awk '{print $2}') + +memory_working_set=${memory_usage_in_bytes} +if [ "$memory_working_set" -lt "$memory_total_inactive_file" ]; +then + memory_working_set=0 +else + memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file)) +fi + +memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set)) +memory_available_in_kb=$((memory_available_in_bytes / 1024)) +memory_available_in_mb=$((memory_available_in_kb / 1024)) + +echo "memory.capacity_in_bytes $memory_capacity_in_bytes" +echo "memory.usage_in_bytes $memory_usage_in_bytes" +echo "memory.total_inactive_file $memory_total_inactive_file" +echo "memory.working_set $memory_working_set" +echo "memory.available_in_bytes $memory_available_in_bytes" +echo "memory.available_in_kb $memory_available_in_kb" +echo "memory.available_in_mb $memory_available_in_mb" diff --git a/content/uk/examples/admin/resource/memory-constraints-pod-2.yaml b/content/uk/examples/admin/resource/memory-constraints-pod-2.yaml new file mode 100644 index 0000000000000..0b1ae569c4962 --- /dev/null +++ b/content/uk/examples/admin/resource/memory-constraints-pod-2.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-mem-demo-2 +spec: + containers: + - name: constraints-mem-demo-2-ctr + image: nginx + resources: + limits: + memory: "1.5Gi" + requests: + memory: "800Mi" diff --git a/content/uk/examples/admin/resource/memory-constraints-pod-3.yaml b/content/uk/examples/admin/resource/memory-constraints-pod-3.yaml new file mode 100644 index 0000000000000..f97cd4a8ac07f --- /dev/null +++ b/content/uk/examples/admin/resource/memory-constraints-pod-3.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-mem-demo-3 +spec: + containers: + - name: constraints-mem-demo-3-ctr + image: nginx + resources: + limits: + memory: "800Mi" + requests: + memory: "100Mi" diff --git a/content/uk/examples/admin/resource/memory-constraints-pod-4.yaml b/content/uk/examples/admin/resource/memory-constraints-pod-4.yaml new file mode 100644 index 0000000000000..657530c41e7fc --- /dev/null +++ b/content/uk/examples/admin/resource/memory-constraints-pod-4.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-mem-demo-4 +spec: + containers: + - name: constraints-mem-demo-4-ctr + image: nginx + diff --git a/content/uk/examples/admin/resource/memory-constraints-pod.yaml b/content/uk/examples/admin/resource/memory-constraints-pod.yaml new file mode 100644 index 0000000000000..06954d10d65ad --- /dev/null +++ b/content/uk/examples/admin/resource/memory-constraints-pod.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-mem-demo +spec: + containers: + - name: constraints-mem-demo-ctr + image: nginx + resources: + limits: + memory: "800Mi" + requests: + memory: "600Mi" diff --git a/content/uk/examples/admin/resource/memory-constraints.yaml b/content/uk/examples/admin/resource/memory-constraints.yaml new file mode 100644 index 0000000000000..3a2924c032e50 --- /dev/null +++ b/content/uk/examples/admin/resource/memory-constraints.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: mem-min-max-demo-lr +spec: + limits: + - max: + memory: 1Gi + min: + memory: 500Mi + type: Container diff --git a/content/uk/examples/admin/resource/memory-defaults-pod-2.yaml b/content/uk/examples/admin/resource/memory-defaults-pod-2.yaml new file mode 100644 index 0000000000000..aa80610d84492 --- /dev/null +++ b/content/uk/examples/admin/resource/memory-defaults-pod-2.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-mem-demo-2 +spec: + containers: + - name: default-mem-demo-2-ctr + image: nginx + resources: + limits: + memory: "1Gi" diff --git a/content/uk/examples/admin/resource/memory-defaults-pod-3.yaml b/content/uk/examples/admin/resource/memory-defaults-pod-3.yaml new file mode 100644 index 0000000000000..09ee8b39a9b42 --- /dev/null +++ b/content/uk/examples/admin/resource/memory-defaults-pod-3.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-mem-demo-3 +spec: + containers: + - name: default-mem-demo-3-ctr + image: nginx + resources: + requests: + memory: "128Mi" diff --git a/content/uk/examples/admin/resource/memory-defaults-pod.yaml b/content/uk/examples/admin/resource/memory-defaults-pod.yaml new file mode 100644 index 0000000000000..ce7a50fb555e0 --- /dev/null +++ b/content/uk/examples/admin/resource/memory-defaults-pod.yaml @@ -0,0 +1,8 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-mem-demo +spec: + containers: + - name: default-mem-demo-ctr + image: nginx diff --git a/content/uk/examples/admin/resource/memory-defaults.yaml b/content/uk/examples/admin/resource/memory-defaults.yaml new file mode 100644 index 0000000000000..b98a5ae262561 --- /dev/null +++ b/content/uk/examples/admin/resource/memory-defaults.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: mem-limit-range +spec: + limits: + - default: + memory: 512Mi + defaultRequest: + memory: 256Mi + type: Container diff --git a/content/uk/examples/admin/resource/pvc-limit-greater.yaml b/content/uk/examples/admin/resource/pvc-limit-greater.yaml new file mode 100644 index 0000000000000..2d92bf92b3121 --- /dev/null +++ b/content/uk/examples/admin/resource/pvc-limit-greater.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: pvc-limit-greater +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 5Gi diff --git a/content/uk/examples/admin/resource/pvc-limit-lower.yaml b/content/uk/examples/admin/resource/pvc-limit-lower.yaml new file mode 100644 index 0000000000000..ef819b6292049 --- /dev/null +++ b/content/uk/examples/admin/resource/pvc-limit-lower.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: pvc-limit-lower +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 500Mi diff --git a/content/uk/examples/admin/resource/quota-mem-cpu-pod-2.yaml b/content/uk/examples/admin/resource/quota-mem-cpu-pod-2.yaml new file mode 100644 index 0000000000000..380e900fda52f --- /dev/null +++ b/content/uk/examples/admin/resource/quota-mem-cpu-pod-2.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: quota-mem-cpu-demo-2 +spec: + containers: + - name: quota-mem-cpu-demo-2-ctr + image: redis + resources: + limits: + memory: "1Gi" + cpu: "800m" + requests: + memory: "700Mi" + cpu: "400m" diff --git a/content/uk/examples/admin/resource/quota-mem-cpu-pod.yaml b/content/uk/examples/admin/resource/quota-mem-cpu-pod.yaml new file mode 100644 index 0000000000000..b0fd0a9451bf2 --- /dev/null +++ b/content/uk/examples/admin/resource/quota-mem-cpu-pod.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: quota-mem-cpu-demo +spec: + containers: + - name: quota-mem-cpu-demo-ctr + image: nginx + resources: + limits: + memory: "800Mi" + cpu: "800m" + requests: + memory: "600Mi" + cpu: "400m" diff --git a/content/uk/examples/admin/resource/quota-mem-cpu.yaml b/content/uk/examples/admin/resource/quota-mem-cpu.yaml new file mode 100644 index 0000000000000..5c4bcd81b8b35 --- /dev/null +++ b/content/uk/examples/admin/resource/quota-mem-cpu.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: ResourceQuota +metadata: + name: mem-cpu-demo +spec: + hard: + requests.cpu: "1" + requests.memory: 1Gi + limits.cpu: "2" + limits.memory: 2Gi diff --git a/content/uk/examples/admin/resource/quota-objects-pvc-2.yaml b/content/uk/examples/admin/resource/quota-objects-pvc-2.yaml new file mode 100644 index 0000000000000..2539c2d3093a8 --- /dev/null +++ b/content/uk/examples/admin/resource/quota-objects-pvc-2.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: pvc-quota-demo-2 +spec: + storageClassName: manual + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 4Gi diff --git a/content/uk/examples/admin/resource/quota-objects-pvc.yaml b/content/uk/examples/admin/resource/quota-objects-pvc.yaml new file mode 100644 index 0000000000000..728bb4d708c27 --- /dev/null +++ b/content/uk/examples/admin/resource/quota-objects-pvc.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: pvc-quota-demo +spec: + storageClassName: manual + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 3Gi diff --git a/content/uk/examples/admin/resource/quota-objects.yaml b/content/uk/examples/admin/resource/quota-objects.yaml new file mode 100644 index 0000000000000..e97748decd53a --- /dev/null +++ b/content/uk/examples/admin/resource/quota-objects.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: ResourceQuota +metadata: + name: object-quota-demo +spec: + hard: + persistentvolumeclaims: "1" + services.loadbalancers: "2" + services.nodeports: "0" diff --git a/content/uk/examples/admin/resource/quota-pod-deployment.yaml b/content/uk/examples/admin/resource/quota-pod-deployment.yaml new file mode 100644 index 0000000000000..86e85aa468e13 --- /dev/null +++ b/content/uk/examples/admin/resource/quota-pod-deployment.yaml @@ -0,0 +1,17 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: pod-quota-demo +spec: + selector: + matchLabels: + purpose: quota-demo + replicas: 3 + template: + metadata: + labels: + purpose: quota-demo + spec: + containers: + - name: pod-quota-demo + image: nginx diff --git a/content/uk/examples/admin/resource/quota-pod.yaml b/content/uk/examples/admin/resource/quota-pod.yaml new file mode 100644 index 0000000000000..0a07f055ca853 --- /dev/null +++ b/content/uk/examples/admin/resource/quota-pod.yaml @@ -0,0 +1,7 @@ +apiVersion: v1 +kind: ResourceQuota +metadata: + name: pod-demo +spec: + hard: + pods: "2" diff --git a/content/uk/examples/admin/resource/storagelimits.yaml b/content/uk/examples/admin/resource/storagelimits.yaml new file mode 100644 index 0000000000000..7f597e4dfe9b1 --- /dev/null +++ b/content/uk/examples/admin/resource/storagelimits.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: storagelimits +spec: + limits: + - type: PersistentVolumeClaim + max: + storage: 2Gi + min: + storage: 1Gi diff --git a/content/uk/examples/admin/sched/clusterrole.yaml b/content/uk/examples/admin/sched/clusterrole.yaml new file mode 100644 index 0000000000000..554b8659db5b0 --- /dev/null +++ b/content/uk/examples/admin/sched/clusterrole.yaml @@ -0,0 +1,37 @@ +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 diff --git a/content/uk/examples/admin/sched/my-scheduler.yaml b/content/uk/examples/admin/sched/my-scheduler.yaml new file mode 100644 index 0000000000000..fa1c65bf9a462 --- /dev/null +++ b/content/uk/examples/admin/sched/my-scheduler.yaml @@ -0,0 +1,113 @@ +apiVersion: v1 +kind: ServiceAccount +metadata: + name: my-scheduler + namespace: kube-system +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: my-scheduler-as-kube-scheduler +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:kube-scheduler + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: my-scheduler-as-volume-scheduler +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:volume-scheduler + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: my-scheduler-extension-apiserver-authentication-reader + namespace: kube-system +roleRef: + kind: Role + name: extension-apiserver-authentication-reader + apiGroup: rbac.authorization.k8s.io +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +--- +apiVersion: v1 +kind: ConfigMap +metadata: + name: my-scheduler-config + namespace: kube-system +data: + my-scheduler-config.yaml: | + apiVersion: kubescheduler.config.k8s.io/v1beta2 + kind: KubeSchedulerConfiguration + profiles: + - schedulerName: my-scheduler + leaderElection: + leaderElect: false +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + component: scheduler + tier: control-plane + name: my-scheduler + namespace: kube-system +spec: + selector: + matchLabels: + component: scheduler + tier: control-plane + replicas: 1 + template: + metadata: + labels: + component: scheduler + tier: control-plane + version: second + spec: + serviceAccountName: my-scheduler + containers: + - command: + - /usr/local/bin/kube-scheduler + - --config=/etc/kubernetes/my-scheduler/my-scheduler-config.yaml + image: gcr.io/my-gcp-project/my-kube-scheduler:1.0 + livenessProbe: + httpGet: + path: /healthz + port: 10259 + scheme: HTTPS + initialDelaySeconds: 15 + name: kube-second-scheduler + readinessProbe: + httpGet: + path: /healthz + port: 10259 + scheme: HTTPS + resources: + requests: + cpu: '0.1' + securityContext: + privileged: false + volumeMounts: + - name: config-volume + mountPath: /etc/kubernetes/my-scheduler + hostNetwork: false + hostPID: false + volumes: + - name: config-volume + configMap: + name: my-scheduler-config diff --git a/content/uk/examples/admin/sched/pod1.yaml b/content/uk/examples/admin/sched/pod1.yaml new file mode 100644 index 0000000000000..7183dd62c0f12 --- /dev/null +++ b/content/uk/examples/admin/sched/pod1.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: no-annotation + labels: + name: multischeduler-example +spec: + containers: + - name: pod-with-no-annotation-container + image: registry.k8s.io/pause:2.0 \ No newline at end of file diff --git a/content/uk/examples/admin/sched/pod2.yaml b/content/uk/examples/admin/sched/pod2.yaml new file mode 100644 index 0000000000000..b78ab64a4bc4a --- /dev/null +++ b/content/uk/examples/admin/sched/pod2.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: annotation-default-scheduler + labels: + name: multischeduler-example +spec: + schedulerName: default-scheduler + containers: + - name: pod-with-default-annotation-container + image: registry.k8s.io/pause:2.0 diff --git a/content/uk/examples/admin/sched/pod3.yaml b/content/uk/examples/admin/sched/pod3.yaml new file mode 100644 index 0000000000000..661414382913f --- /dev/null +++ b/content/uk/examples/admin/sched/pod3.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: annotation-second-scheduler + labels: + name: multischeduler-example +spec: + schedulerName: my-scheduler + containers: + - name: pod-with-second-annotation-container + image: registry.k8s.io/pause:2.0 diff --git a/content/uk/examples/admin/snowflake-deployment.yaml b/content/uk/examples/admin/snowflake-deployment.yaml new file mode 100644 index 0000000000000..21b6738ba4e6d --- /dev/null +++ b/content/uk/examples/admin/snowflake-deployment.yaml @@ -0,0 +1,20 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: snowflake + name: snowflake +spec: + replicas: 2 + selector: + matchLabels: + app: snowflake + template: + metadata: + labels: + app: snowflake + spec: + containers: + - image: registry.k8s.io/serve_hostname + imagePullPolicy: Always + name: snowflake diff --git a/content/uk/examples/application/cassandra/cassandra-service.yaml b/content/uk/examples/application/cassandra/cassandra-service.yaml new file mode 100644 index 0000000000000..31bee74b58732 --- /dev/null +++ b/content/uk/examples/application/cassandra/cassandra-service.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + labels: + app: cassandra + name: cassandra +spec: + clusterIP: None + ports: + - port: 9042 + selector: + app: cassandra diff --git a/content/uk/examples/application/cassandra/cassandra-statefulset.yaml b/content/uk/examples/application/cassandra/cassandra-statefulset.yaml new file mode 100644 index 0000000000000..a7bdbedc9c5aa --- /dev/null +++ b/content/uk/examples/application/cassandra/cassandra-statefulset.yaml @@ -0,0 +1,100 @@ +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: cassandra + labels: + app: cassandra +spec: + serviceName: cassandra + replicas: 3 + selector: + matchLabels: + app: cassandra + template: + metadata: + labels: + app: cassandra + spec: + terminationGracePeriodSeconds: 1800 + containers: + - name: cassandra + image: gcr.io/google-samples/cassandra:v13 + imagePullPolicy: Always + ports: + - containerPort: 7000 + name: intra-node + - containerPort: 7001 + name: tls-intra-node + - containerPort: 7199 + name: jmx + - containerPort: 9042 + name: cql + resources: + limits: + cpu: "500m" + memory: 1Gi + requests: + cpu: "500m" + memory: 1Gi + securityContext: + capabilities: + add: + - IPC_LOCK + lifecycle: + preStop: + exec: + command: + - /bin/sh + - -c + - nodetool drain + env: + - name: MAX_HEAP_SIZE + value: 512M + - name: HEAP_NEWSIZE + value: 100M + - name: CASSANDRA_SEEDS + value: "cassandra-0.cassandra.default.svc.cluster.local" + - name: CASSANDRA_CLUSTER_NAME + value: "K8Demo" + - name: CASSANDRA_DC + value: "DC1-K8Demo" + - name: CASSANDRA_RACK + value: "Rack1-K8Demo" + - name: POD_IP + valueFrom: + fieldRef: + fieldPath: status.podIP + readinessProbe: + exec: + command: + - /bin/bash + - -c + - /ready-probe.sh + initialDelaySeconds: 15 + timeoutSeconds: 5 + # These volume mounts are persistent. They are like inline claims, + # but not exactly because the names need to match exactly one of + # the stateful pod volumes. + volumeMounts: + - name: cassandra-data + mountPath: /cassandra_data + # These are converted to volume claims by the controller + # and mounted at the paths mentioned above. + # do not use these in production until ssd GCEPersistentDisk or other ssd pd + volumeClaimTemplates: + - metadata: + name: cassandra-data + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: fast + resources: + requests: + storage: 1Gi +--- +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: fast +provisioner: k8s.io/minikube-hostpath +parameters: + type: pd-ssd diff --git a/content/uk/examples/application/deployment-patch.yaml b/content/uk/examples/application/deployment-patch.yaml new file mode 100644 index 0000000000000..af12f4cb0c4ec --- /dev/null +++ b/content/uk/examples/application/deployment-patch.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: patch-demo +spec: + replicas: 2 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: patch-demo-ctr + image: nginx + tolerations: + - effect: NoSchedule + key: dedicated + value: test-team diff --git a/content/uk/examples/application/deployment-retainkeys.yaml b/content/uk/examples/application/deployment-retainkeys.yaml new file mode 100644 index 0000000000000..af63f46d37294 --- /dev/null +++ b/content/uk/examples/application/deployment-retainkeys.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: retainkeys-demo +spec: + selector: + matchLabels: + app: nginx + strategy: + rollingUpdate: + maxSurge: 30% + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: retainkeys-demo-ctr + image: nginx diff --git a/content/uk/examples/application/deployment-scale.yaml b/content/uk/examples/application/deployment-scale.yaml new file mode 100644 index 0000000000000..838576375ef6f --- /dev/null +++ b/content/uk/examples/application/deployment-scale.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 4 # Update the replicas from 2 to 4 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.16.1 + ports: + - containerPort: 80 diff --git a/content/uk/examples/application/deployment-sidecar.yaml b/content/uk/examples/application/deployment-sidecar.yaml new file mode 100644 index 0000000000000..3f1b841d31ebf --- /dev/null +++ b/content/uk/examples/application/deployment-sidecar.yaml @@ -0,0 +1,34 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: myapp + labels: + app: myapp +spec: + replicas: 1 + selector: + matchLabels: + app: myapp + template: + metadata: + labels: + app: myapp + spec: + containers: + - name: myapp + image: alpine:latest + command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done'] + volumeMounts: + - name: data + mountPath: /opt + initContainers: + - name: logshipper + image: alpine:latest + restartPolicy: Always + command: ['sh', '-c', 'tail -F /opt/logs.txt'] + volumeMounts: + - name: data + mountPath: /opt + volumes: + - name: data + emptyDir: {} \ No newline at end of file diff --git a/content/uk/examples/application/deployment-update.yaml b/content/uk/examples/application/deployment-update.yaml new file mode 100644 index 0000000000000..e212dcb4dcbc0 --- /dev/null +++ b/content/uk/examples/application/deployment-update.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.16.1 # Оновлення версії nginx з 1.14.2 до 1.16.1 + ports: + - containerPort: 80 diff --git a/content/uk/examples/application/deployment.yaml b/content/uk/examples/application/deployment.yaml new file mode 100644 index 0000000000000..6c42250ca1fd1 --- /dev/null +++ b/content/uk/examples/application/deployment.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 # вказує Deployment запустити 2 Podʼи, що відповідають шаблону + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 diff --git a/content/uk/examples/application/guestbook/frontend-deployment.yaml b/content/uk/examples/application/guestbook/frontend-deployment.yaml new file mode 100644 index 0000000000000..b4639929ad424 --- /dev/null +++ b/content/uk/examples/application/guestbook/frontend-deployment.yaml @@ -0,0 +1,29 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: apps/v1 +kind: Deployment +metadata: + name: frontend +spec: + replicas: 3 + selector: + matchLabels: + app: guestbook + tier: frontend + template: + metadata: + labels: + app: guestbook + tier: frontend + spec: + containers: + - name: php-redis + image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5 + env: + - name: GET_HOSTS_FROM + value: "dns" + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 80 diff --git a/content/uk/examples/application/guestbook/frontend-service.yaml b/content/uk/examples/application/guestbook/frontend-service.yaml new file mode 100644 index 0000000000000..e8cfef8c3d75b --- /dev/null +++ b/content/uk/examples/application/guestbook/frontend-service.yaml @@ -0,0 +1,19 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: v1 +kind: Service +metadata: + name: frontend + labels: + app: guestbook + tier: frontend +spec: + # якщо ваш кластер підтримує це, розкоментуйте наступне, щоб автоматично створити + # зовнішню IP-адресу з балансуванням навантаження для служби frontend. + # type: LoadBalancer + #type: LoadBalancer + ports: + # порт на якому має працювати цей Service + - port: 80 + selector: + app: guestbook + tier: frontend \ No newline at end of file diff --git a/content/uk/examples/application/guestbook/redis-follower-deployment.yaml b/content/uk/examples/application/guestbook/redis-follower-deployment.yaml new file mode 100644 index 0000000000000..c32a16e46c879 --- /dev/null +++ b/content/uk/examples/application/guestbook/redis-follower-deployment.yaml @@ -0,0 +1,30 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: apps/v1 +kind: Deployment +metadata: + name: redis-follower + labels: + app: redis + role: follower + tier: backend +spec: + replicas: 2 + selector: + matchLabels: + app: redis + template: + metadata: + labels: + app: redis + role: follower + tier: backend + spec: + containers: + - name: follower + image: us-docker.pkg.dev/google-samples/containers/gke/gb-redis-follower:v2 + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 6379 \ No newline at end of file diff --git a/content/uk/examples/application/guestbook/redis-follower-service.yaml b/content/uk/examples/application/guestbook/redis-follower-service.yaml new file mode 100644 index 0000000000000..913c4e6165311 --- /dev/null +++ b/content/uk/examples/application/guestbook/redis-follower-service.yaml @@ -0,0 +1,17 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: v1 +kind: Service +metadata: + name: redis-follower + labels: + app: redis + role: follower + tier: backend +spec: + ports: + # порт на якому повинен працювати цей Service + - port: 6379 + selector: + app: redis + role: follower + tier: backend \ No newline at end of file diff --git a/content/uk/examples/application/guestbook/redis-leader-deployment.yaml b/content/uk/examples/application/guestbook/redis-leader-deployment.yaml new file mode 100644 index 0000000000000..9c7547291c376 --- /dev/null +++ b/content/uk/examples/application/guestbook/redis-leader-deployment.yaml @@ -0,0 +1,30 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: apps/v1 +kind: Deployment +metadata: + name: redis-leader + labels: + app: redis + role: leader + tier: backend +spec: + replicas: 1 + selector: + matchLabels: + app: redis + template: + metadata: + labels: + app: redis + role: leader + tier: backend + spec: + containers: + - name: leader + image: "docker.io/redis:6.0.5" + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 6379 \ No newline at end of file diff --git a/content/uk/examples/application/guestbook/redis-leader-service.yaml b/content/uk/examples/application/guestbook/redis-leader-service.yaml new file mode 100644 index 0000000000000..e04cc183d09bf --- /dev/null +++ b/content/uk/examples/application/guestbook/redis-leader-service.yaml @@ -0,0 +1,17 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: v1 +kind: Service +metadata: + name: redis-leader + labels: + app: redis + role: leader + tier: backend +spec: + ports: + - port: 6379 + targetPort: 6379 + selector: + app: redis + role: leader + tier: backend \ No newline at end of file diff --git a/content/uk/examples/application/hpa/php-apache.yaml b/content/uk/examples/application/hpa/php-apache.yaml new file mode 100644 index 0000000000000..1c49aca6a1ff5 --- /dev/null +++ b/content/uk/examples/application/hpa/php-apache.yaml @@ -0,0 +1,18 @@ +apiVersion: autoscaling/v2 +kind: HorizontalPodAutoscaler +metadata: + name: php-apache +spec: + scaleTargetRef: + apiVersion: apps/v1 + kind: Deployment + name: php-apache + minReplicas: 1 + maxReplicas: 10 + metrics: + - type: Resource + resource: + name: cpu + target: + type: Utilization + averageUtilization: 50 diff --git a/content/uk/examples/application/job/cronjob.yaml b/content/uk/examples/application/job/cronjob.yaml new file mode 100644 index 0000000000000..78d0e2d314792 --- /dev/null +++ b/content/uk/examples/application/job/cronjob.yaml @@ -0,0 +1,19 @@ +apiVersion: batch/v1 +kind: CronJob +metadata: + name: hello +spec: + schedule: "* * * * *" + jobTemplate: + spec: + template: + spec: + containers: + - name: hello + image: busybox:1.28 + imagePullPolicy: IfNotPresent + command: + - /bin/sh + - -c + - date; echo Hello from the Kubernetes cluster + restartPolicy: OnFailure diff --git a/content/uk/examples/application/job/indexed-job-vol.yaml b/content/uk/examples/application/job/indexed-job-vol.yaml new file mode 100644 index 0000000000000..ed40e1cc44606 --- /dev/null +++ b/content/uk/examples/application/job/indexed-job-vol.yaml @@ -0,0 +1,27 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: 'indexed-job' +spec: + completions: 5 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + containers: + - name: 'worker' + image: 'docker.io/library/busybox' + command: + - "rev" + - "/input/data.txt" + volumeMounts: + - mountPath: /input + name: input + volumes: + - name: input + downwardAPI: + items: + - path: "data.txt" + fieldRef: + fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index'] \ No newline at end of file diff --git a/content/uk/examples/application/job/indexed-job.yaml b/content/uk/examples/application/job/indexed-job.yaml new file mode 100644 index 0000000000000..5b80d3526491f --- /dev/null +++ b/content/uk/examples/application/job/indexed-job.yaml @@ -0,0 +1,35 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: 'indexed-job' +spec: + completions: 5 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + initContainers: + - name: 'input' + image: 'docker.io/library/bash' + command: + - "bash" + - "-c" + - | + items=(foo bar baz qux xyz) + echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt + volumeMounts: + - mountPath: /input + name: input + containers: + - name: 'worker' + image: 'docker.io/library/busybox' + command: + - "rev" + - "/input/data.txt" + volumeMounts: + - mountPath: /input + name: input + volumes: + - name: input + emptyDir: {} diff --git a/content/uk/examples/application/job/job-sidecar.yaml b/content/uk/examples/application/job/job-sidecar.yaml new file mode 100644 index 0000000000000..9787ad88515b2 --- /dev/null +++ b/content/uk/examples/application/job/job-sidecar.yaml @@ -0,0 +1,26 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: myjob +spec: + template: + spec: + containers: + - name: myjob + image: alpine:latest + command: ['sh', '-c', 'echo "logging" > /opt/logs.txt'] + volumeMounts: + - name: data + mountPath: /opt + initContainers: + - name: logshipper + image: alpine:latest + restartPolicy: Always + command: ['sh', '-c', 'tail -F /opt/logs.txt'] + volumeMounts: + - name: data + mountPath: /opt + restartPolicy: Never + volumes: + - name: data + emptyDir: {} \ No newline at end of file diff --git a/content/uk/examples/application/job/job-tmpl.yaml b/content/uk/examples/application/job/job-tmpl.yaml new file mode 100644 index 0000000000000..d7dbbafd62bc5 --- /dev/null +++ b/content/uk/examples/application/job/job-tmpl.yaml @@ -0,0 +1,18 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: process-item-$ITEM + labels: + jobgroup: jobexample +spec: + template: + metadata: + name: jobexample + labels: + jobgroup: jobexample + spec: + containers: + - name: c + image: busybox:1.28 + command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"] + restartPolicy: Never diff --git a/content/uk/examples/application/job/rabbitmq/Dockerfile b/content/uk/examples/application/job/rabbitmq/Dockerfile new file mode 100644 index 0000000000000..50faab23f439c --- /dev/null +++ b/content/uk/examples/application/job/rabbitmq/Dockerfile @@ -0,0 +1,10 @@ +# Specify BROKER_URL and QUEUE when running +FROM ubuntu:18.04 + +RUN apt-get update && \ + apt-get install -y curl ca-certificates amqp-tools python \ + --no-install-recommends \ + && rm -rf /var/lib/apt/lists/* +COPY ./worker.py /worker.py + +CMD /usr/bin/amqp-consume --url=$BROKER_URL -q $QUEUE -c 1 /worker.py diff --git a/content/uk/examples/application/job/rabbitmq/job.yaml b/content/uk/examples/application/job/rabbitmq/job.yaml new file mode 100644 index 0000000000000..4e1a61892be6b --- /dev/null +++ b/content/uk/examples/application/job/rabbitmq/job.yaml @@ -0,0 +1,20 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: job-wq-1 +spec: + completions: 8 + parallelism: 2 + template: + metadata: + name: job-wq-1 + spec: + containers: + - name: c + image: gcr.io//job-wq-1 + env: + - name: BROKER_URL + value: amqp://guest:guest@rabbitmq-service:5672 + - name: QUEUE + value: job1 + restartPolicy: OnFailure diff --git a/content/uk/examples/application/job/rabbitmq/rabbitmq-service.yaml b/content/uk/examples/application/job/rabbitmq/rabbitmq-service.yaml new file mode 100644 index 0000000000000..2f7fb06dcfed6 --- /dev/null +++ b/content/uk/examples/application/job/rabbitmq/rabbitmq-service.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + labels: + component: rabbitmq + name: rabbitmq-service +spec: + ports: + - port: 5672 + selector: + app.kubernetes.io/name: task-queue + app.kubernetes.io/component: rabbitmq diff --git a/content/uk/examples/application/job/rabbitmq/rabbitmq-statefulset.yaml b/content/uk/examples/application/job/rabbitmq/rabbitmq-statefulset.yaml new file mode 100644 index 0000000000000..502598ddf947e --- /dev/null +++ b/content/uk/examples/application/job/rabbitmq/rabbitmq-statefulset.yaml @@ -0,0 +1,36 @@ +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + component: rabbitmq + name: rabbitmq +spec: + replicas: 1 + serviceName: rabbitmq-service + selector: + matchLabels: + app.kubernetes.io/name: task-queue + app.kubernetes.io/component: rabbitmq + template: + metadata: + labels: + app.kubernetes.io/name: task-queue + app.kubernetes.io/component: rabbitmq + spec: + containers: + - image: rabbitmq + name: rabbitmq + ports: + - containerPort: 5672 + resources: + requests: + memory: 16M + limits: + cpu: 250m + memory: 512M + volumeMounts: + - mountPath: /var/lib/rabbitmq + name: rabbitmq-data + volumes: + - name: rabbitmq-data + emptyDir: {} diff --git a/content/uk/examples/application/job/rabbitmq/worker.py b/content/uk/examples/application/job/rabbitmq/worker.py new file mode 100644 index 0000000000000..2761453aff675 --- /dev/null +++ b/content/uk/examples/application/job/rabbitmq/worker.py @@ -0,0 +1,7 @@ +#!/usr/bin/env python + +# Просто виводить стандартний вивід і очікує протягом 10 секунд. +import sys +import time +print("Processing " + sys.stdin.readlines()[0]) +time.sleep(10) diff --git a/content/uk/examples/application/job/redis/Dockerfile b/content/uk/examples/application/job/redis/Dockerfile new file mode 100644 index 0000000000000..2de23b3c98340 --- /dev/null +++ b/content/uk/examples/application/job/redis/Dockerfile @@ -0,0 +1,6 @@ +FROM python +RUN pip install redis +COPY ./worker.py /worker.py +COPY ./rediswq.py /rediswq.py + +CMD python worker.py diff --git a/content/uk/examples/application/job/redis/job.yaml b/content/uk/examples/application/job/redis/job.yaml new file mode 100644 index 0000000000000..ee7a06c732986 --- /dev/null +++ b/content/uk/examples/application/job/redis/job.yaml @@ -0,0 +1,14 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: job-wq-2 +spec: + parallelism: 2 + template: + metadata: + name: job-wq-2 + spec: + containers: + - name: c + image: gcr.io/myproject/job-wq-2 + restartPolicy: OnFailure diff --git a/content/uk/examples/application/job/redis/redis-pod.yaml b/content/uk/examples/application/job/redis/redis-pod.yaml new file mode 100644 index 0000000000000..ae0c43a793570 --- /dev/null +++ b/content/uk/examples/application/job/redis/redis-pod.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: redis-master + labels: + app: redis +spec: + containers: + - name: master + image: redis + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 diff --git a/content/uk/examples/application/job/redis/redis-service.yaml b/content/uk/examples/application/job/redis/redis-service.yaml new file mode 100644 index 0000000000000..85f2ca2271d0b --- /dev/null +++ b/content/uk/examples/application/job/redis/redis-service.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Service +metadata: + name: redis +spec: + ports: + - port: 6379 + targetPort: 6379 + selector: + app: redis diff --git a/content/uk/examples/application/job/redis/rediswq.py b/content/uk/examples/application/job/redis/rediswq.py new file mode 100644 index 0000000000000..2b8e81ceab79d --- /dev/null +++ b/content/uk/examples/application/job/redis/rediswq.py @@ -0,0 +1,130 @@ +#!/usr/bin/env python + +# Based on http://peter-hoffmann.com/2012/python-simple-queue-redis-queue.html +# and the suggestion in the redis documentation for RPOPLPUSH, at +# http://redis.io/commands/rpoplpush, which suggests how to implement a work-queue. + + +import redis +import uuid +import hashlib + +class RedisWQ(object): + """Simple Finite Work Queue with Redis Backend + + This work queue is finite: as long as no more work is added + after workers start, the workers can detect when the queue + is completely empty. + + The items in the work queue are assumed to have unique values. + + This object is not intended to be used by multiple threads + concurrently. + """ + def __init__(self, name, **redis_kwargs): + """The default connection parameters are: host='localhost', port=6379, db=0 + + The work queue is identified by "name". The library may create other + keys with "name" as a prefix. + """ + self._db = redis.StrictRedis(**redis_kwargs) + # The session ID will uniquely identify this "worker". + self._session = str(uuid.uuid4()) + # Work queue is implemented as two queues: main, and processing. + # Work is initially in main, and moved to processing when a client picks it up. + self._main_q_key = name + self._processing_q_key = name + ":processing" + self._lease_key_prefix = name + ":leased_by_session:" + + def sessionID(self): + """Return the ID for this session.""" + return self._session + + def _main_qsize(self): + """Return the size of the main queue.""" + return self._db.llen(self._main_q_key) + + def _processing_qsize(self): + """Return the size of the main queue.""" + return self._db.llen(self._processing_q_key) + + def empty(self): + """Return True if the queue is empty, including work being done, False otherwise. + + False does not necessarily mean that there is work available to work on right now, + """ + return self._main_qsize() == 0 and self._processing_qsize() == 0 + +# TODO: implement this +# def check_expired_leases(self): +# """Return to the work queueReturn True if the queue is empty, False otherwise.""" +# # Processing list should not be _too_ long since it is approximately as long +# # as the number of active and recently active workers. +# processing = self._db.lrange(self._processing_q_key, 0, -1) +# for item in processing: +# # If the lease key is not present for an item (it expired or was +# # never created because the client crashed before creating it) +# # then move the item back to the main queue so others can work on it. +# if not self._lease_exists(item): +# TODO: transactionally move the key from processing queue to +# to main queue, while detecting if a new lease is created +# or if either queue is modified. + + def _itemkey(self, item): + """Returns a string that uniquely identifies an item (bytes).""" + return hashlib.sha224(item).hexdigest() + + def _lease_exists(self, item): + """True if a lease on 'item' exists.""" + return self._db.exists(self._lease_key_prefix + self._itemkey(item)) + + def lease(self, lease_secs=60, block=True, timeout=None): + """Begin working on an item the work queue. + + Lease the item for lease_secs. After that time, other + workers may consider this client to have crashed or stalled + and pick up the item instead. + + If optional args block is true and timeout is None (the default), block + if necessary until an item is available.""" + if block: + item = self._db.brpoplpush(self._main_q_key, self._processing_q_key, timeout=timeout) + else: + item = self._db.rpoplpush(self._main_q_key, self._processing_q_key) + if item: + # Record that we (this session id) are working on a key. Expire that + # note after the lease timeout. + # Note: if we crash at this line of the program, then GC will see no lease + # for this item a later return it to the main queue. + itemkey = self._itemkey(item) + self._db.setex(self._lease_key_prefix + itemkey, lease_secs, self._session) + return item + + def complete(self, value): + """Complete working on the item with 'value'. + + If the lease expired, the item may not have completed, and some + other worker may have picked it up. There is no indication + of what happened. + """ + self._db.lrem(self._processing_q_key, 0, value) + # If we crash here, then the GC code will try to move the value, but it will + # not be here, which is fine. So this does not need to be a transaction. + itemkey = self._itemkey(value) + self._db.delete(self._lease_key_prefix + itemkey) + +# TODO: add functions to clean up all keys associated with "name" when +# processing is complete. + +# TODO: add a function to add an item to the queue. Atomically +# check if the queue is empty and if so fail to add the item +# since other workers might think work is done and be in the process +# of exiting. + +# TODO(etune): move to my own github for hosting, e.g. github.com/erictune/rediswq-py and +# make it so it can be pip installed by anyone (see +# http://stackoverflow.com/questions/8247605/configuring-so-that-pip-install-can-work-from-github) + +# TODO(etune): finish code to GC expired leases, and call periodically +# e.g. each time lease times out. + diff --git a/content/uk/examples/application/job/redis/worker.py b/content/uk/examples/application/job/redis/worker.py new file mode 100644 index 0000000000000..2347b562242c9 --- /dev/null +++ b/content/uk/examples/application/job/redis/worker.py @@ -0,0 +1,23 @@ +#!/usr/bin/env python + +import time +import rediswq + +host="redis" +# Якщо у вас немає працюючого Kube-DNS, розкоментуйте наступні два рядки. +# import os +# host = os.getenv("REDIS_SERVICE_HOST") + +q = rediswq.RedisWQ(name="job2", host=host) +print("Worker with sessionID: " + q.sessionID()) +print("Initial queue state: empty=" + str(q.empty())) +while not q.empty(): + item = q.lease(lease_secs=10, block=True, timeout=2) + if item is not None: + itemstr = item.decode("utf-8") + print("Working on " + itemstr) + time.sleep(10) # Put your actual work here instead of sleep. + q.complete(item) + else: + print("Waiting for work") +print("Queue empty, exiting") diff --git a/content/uk/examples/application/mongodb/mongo-deployment.yaml b/content/uk/examples/application/mongodb/mongo-deployment.yaml new file mode 100644 index 0000000000000..04908ce25b1dc --- /dev/null +++ b/content/uk/examples/application/mongodb/mongo-deployment.yaml @@ -0,0 +1,31 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: mongo + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend +spec: + selector: + matchLabels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend + replicas: 1 + template: + metadata: + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend + spec: + containers: + - name: mongo + image: mongo:4.2 + args: + - --bind_ip + - 0.0.0.0 + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 27017 diff --git a/content/uk/examples/application/mongodb/mongo-service.yaml b/content/uk/examples/application/mongodb/mongo-service.yaml new file mode 100644 index 0000000000000..b9cef607bcf79 --- /dev/null +++ b/content/uk/examples/application/mongodb/mongo-service.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Service +metadata: + name: mongo + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend +spec: + ports: + - port: 27017 + targetPort: 27017 + selector: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend diff --git a/content/uk/examples/application/mysql/mysql-configmap.yaml b/content/uk/examples/application/mysql/mysql-configmap.yaml new file mode 100644 index 0000000000000..9adb0344a31a6 --- /dev/null +++ b/content/uk/examples/application/mysql/mysql-configmap.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: mysql + labels: + app: mysql + app.kubernetes.io/name: mysql +data: + primary.cnf: | + # Apply this config only on the primary. + [mysqld] + log-bin + replica.cnf: | + # Apply this config only on replicas. + [mysqld] + super-read-only + diff --git a/content/uk/examples/application/mysql/mysql-deployment.yaml b/content/uk/examples/application/mysql/mysql-deployment.yaml new file mode 100644 index 0000000000000..419fbe03d3ff0 --- /dev/null +++ b/content/uk/examples/application/mysql/mysql-deployment.yaml @@ -0,0 +1,43 @@ +apiVersion: v1 +kind: Service +metadata: + name: mysql +spec: + ports: + - port: 3306 + selector: + app: mysql + clusterIP: None +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: mysql +spec: + selector: + matchLabels: + app: mysql + strategy: + type: Recreate + template: + metadata: + labels: + app: mysql + spec: + containers: + - image: mysql:5.6 + name: mysql + env: + # Use secret in real usage + - name: MYSQL_ROOT_PASSWORD + value: password + ports: + - containerPort: 3306 + name: mysql + volumeMounts: + - name: mysql-persistent-storage + mountPath: /var/lib/mysql + volumes: + - name: mysql-persistent-storage + persistentVolumeClaim: + claimName: mysql-pv-claim diff --git a/content/uk/examples/application/mysql/mysql-pv.yaml b/content/uk/examples/application/mysql/mysql-pv.yaml new file mode 100644 index 0000000000000..c89779a83fd23 --- /dev/null +++ b/content/uk/examples/application/mysql/mysql-pv.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: PersistentVolume +metadata: + name: mysql-pv-volume + labels: + type: local +spec: + storageClassName: manual + capacity: + storage: 20Gi + accessModes: + - ReadWriteOnce + hostPath: + path: "/mnt/data" +--- +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: mysql-pv-claim +spec: + storageClassName: manual + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 20Gi diff --git a/content/uk/examples/application/mysql/mysql-services.yaml b/content/uk/examples/application/mysql/mysql-services.yaml new file mode 100644 index 0000000000000..bc015066780c3 --- /dev/null +++ b/content/uk/examples/application/mysql/mysql-services.yaml @@ -0,0 +1,32 @@ +# Headless service for stable DNS entries of StatefulSet members. +apiVersion: v1 +kind: Service +metadata: + name: mysql + labels: + app: mysql + app.kubernetes.io/name: mysql +spec: + ports: + - name: mysql + port: 3306 + clusterIP: None + selector: + app: mysql +--- +# Client service for connecting to any MySQL instance for reads. +# For writes, you must instead connect to the primary: mysql-0.mysql. +apiVersion: v1 +kind: Service +metadata: + name: mysql-read + labels: + app: mysql + app.kubernetes.io/name: mysql + readonly: "true" +spec: + ports: + - name: mysql + port: 3306 + selector: + app: mysql diff --git a/content/uk/examples/application/mysql/mysql-statefulset.yaml b/content/uk/examples/application/mysql/mysql-statefulset.yaml new file mode 100644 index 0000000000000..67755dbb9e830 --- /dev/null +++ b/content/uk/examples/application/mysql/mysql-statefulset.yaml @@ -0,0 +1,168 @@ +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: mysql +spec: + selector: + matchLabels: + app: mysql + app.kubernetes.io/name: mysql + serviceName: mysql + replicas: 3 + template: + metadata: + labels: + app: mysql + app.kubernetes.io/name: mysql + spec: + initContainers: + - name: init-mysql + image: mysql:5.7 + command: + - bash + - "-c" + - | + set -ex + # Generate mysql server-id from pod ordinal index. + [[ $HOSTNAME =~ -([0-9]+)$ ]] || exit 1 + ordinal=${BASH_REMATCH[1]} + echo [mysqld] > /mnt/conf.d/server-id.cnf + # Add an offset to avoid reserved server-id=0 value. + echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf + # Copy appropriate conf.d files from config-map to emptyDir. + if [[ $ordinal -eq 0 ]]; then + cp /mnt/config-map/primary.cnf /mnt/conf.d/ + else + cp /mnt/config-map/replica.cnf /mnt/conf.d/ + fi + volumeMounts: + - name: conf + mountPath: /mnt/conf.d + - name: config-map + mountPath: /mnt/config-map + - name: clone-mysql + image: gcr.io/google-samples/xtrabackup:1.0 + command: + - bash + - "-c" + - | + set -ex + # Skip the clone if data already exists. + [[ -d /var/lib/mysql/mysql ]] && exit 0 + # Skip the clone on primary (ordinal index 0). + [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 + ordinal=${BASH_REMATCH[1]} + [[ $ordinal -eq 0 ]] && exit 0 + # Clone data from previous peer. + ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql + # Prepare the backup. + xtrabackup --prepare --target-dir=/var/lib/mysql + volumeMounts: + - name: data + mountPath: /var/lib/mysql + subPath: mysql + - name: conf + mountPath: /etc/mysql/conf.d + containers: + - name: mysql + image: mysql:5.7 + env: + - name: MYSQL_ALLOW_EMPTY_PASSWORD + value: "1" + ports: + - name: mysql + containerPort: 3306 + volumeMounts: + - name: data + mountPath: /var/lib/mysql + subPath: mysql + - name: conf + mountPath: /etc/mysql/conf.d + resources: + requests: + cpu: 500m + memory: 1Gi + livenessProbe: + exec: + command: ["mysqladmin", "ping"] + initialDelaySeconds: 30 + periodSeconds: 10 + timeoutSeconds: 5 + readinessProbe: + exec: + # Check we can execute queries over TCP (skip-networking is off). + command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"] + initialDelaySeconds: 5 + periodSeconds: 2 + timeoutSeconds: 1 + - name: xtrabackup + image: gcr.io/google-samples/xtrabackup:1.0 + ports: + - name: xtrabackup + containerPort: 3307 + command: + - bash + - "-c" + - | + set -ex + cd /var/lib/mysql + + # Determine binlog position of cloned data, if any. + if [[ -f xtrabackup_slave_info && "x$( change_master_to.sql.in + # Ignore xtrabackup_binlog_info in this case (it's useless). + rm -f xtrabackup_slave_info xtrabackup_binlog_info + elif [[ -f xtrabackup_binlog_info ]]; then + # We're cloning directly from primary. Parse binlog position. + [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1 + rm -f xtrabackup_binlog_info xtrabackup_slave_info + echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\ + MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in + fi + + # Check if we need to complete a clone by starting replication. + if [[ -f change_master_to.sql.in ]]; then + echo "Waiting for mysqld to be ready (accepting connections)" + until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done + + echo "Initializing replication from clone position" + mysql -h 127.0.0.1 \ + -e "$( + # /var/lib/docker/containers/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b-json.log + # The /var/log directory on the host is mapped to the /var/log directory in the container + # running this instance of Fluentd and we end up collecting the file: + # /var/log/containers/synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log + # This results in the tag: + # var.log.containers.synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log + # The record reformer is used is discard the var.log.containers prefix and + # the Docker container ID suffix and "kubernetes." is pre-pended giving the tag: + # kubernetes.synthetic-logger-0.25lps-pod_default-synth-lgr + # Tag is then parsed by google_cloud plugin and translated to the metadata, + # visible in the log viewer + + # Example: + # {"log":"[info:2016-02-16T16:04:05.930-08:00] Some log text here\n","stream":"stdout","time":"2016-02-17T00:04:05.931087621Z"} + + type tail + format json + time_key time + path /var/log/containers/*.log + pos_file /var/log/gcp-containers.log.pos + time_format %Y-%m-%dT%H:%M:%S.%N%Z + tag reform.* + read_from_head true + + + + type parser + format /^(?\w)(? + + + type record_reformer + enable_ruby true + tag raw.kubernetes.${tag_suffix[4].split('-')[0..-2].join('-')} + + + # Detect exceptions in the log output and forward them as one log entry. + + @type copy + + + @type prometheus + + + type counter + name logging_line_count + desc Total number of lines generated by application containers + + tag ${tag} + + + + + @type detect_exceptions + + remove_tag_prefix raw + message log + stream stream + multiline_flush_interval 5 + max_bytes 500000 + max_lines 1000 + + + system.input.conf: |- + # Example: + # Dec 21 23:17:22 gke-foo-1-1-4b5cbd14-node-4eoj startupscript: Finished running startup script /var/run/google.startup.script + + type tail + format syslog + path /var/log/startupscript.log + pos_file /var/log/gcp-startupscript.log.pos + tag startupscript + + + # Examples: + # time="2016-02-04T06:51:03.053580605Z" level=info msg="GET /containers/json" + # time="2016-02-04T07:53:57.505612354Z" level=error msg="HTTP Error" err="No such image: -f" statusCode=404 + + type tail + format /^time="(?