Глосарій

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

Відфільтрувати терміни за теґами

Внутрішні компоненти Kubernetes.
Повʼязана з Kubernetes розробка з відкритим кодом.
Типи ресурсів, які Kubernetes підтримує з коробки.
Підтримувані налаштування Kubernetes.
Актуально для тих, хто вперше користується Kubernetes.
Як компоненти Kubernetes спілкуються один з одним (та з програмами поза кластером).
Запуск і обслуговування Kubernetes.
Підтримання захищенності та безпечності застосунків Kubernetes.
Як програми Kubernetes працюють з постійними даними.
Програмне забезпечення, яке полегшує та покращує використання Kubernetes.
Представляє поширений тип користувачів Kubernetes.
Застосунки, що запускаються в Kubernetes.
Архітектура Спільнота Основні обʼєкти Розширення Основи Мережа Обслуговування Безпека Зберігання Інструменти Користувачі Навантаження Вибрати все Очистити вибір

Натисність на [+] для отримання розширеного пояснення конкретного терміна.

  • API Kubernetes

    Застосунок, який обслуговує функціонал Kubernetes через RESTful інтерфейс та зберігає стан кластера.

    [+]

    Ресурси Kubernetes та "записи про наміри" зберігаються як обʼєкти API та модифікуються за допомогою RESTful викликів до API. API дозволяє керувати конфігурацією декларативним способом. Користувачі можуть взаємодіяти з API Kubernetes безпосередньо або за допомогою інструментів, таких як kubectl. Ядро API Kubernetes є гнучким та може бути розширено для підтримки власних ресурсів користувачів.

  • API server
    Або також: kube-apiserver

    Сервер API є компонентом панелі управління Kubernetes, який надає доступ до API Kubernetes. Сервер API є фронтендом для панелі управління Kubernetes.

    [+]

    Основна реалізація сервера API Kubernetes — kube-apiserver. kube-apiserver спроєктований для горизонтального масштабування, тобто масштабується за допомогою розгортання додаткових екземплярів. Ви можете запустити кілька екземплярів kube-apiserver та балансувати трафік між ними.

  • API Шлюзу
    Або також: Gateway API

    Різновид API для створення мережі Service в Kubernetes.

    [+]

    API Шлюзу надає сімейство розширюваних, орієнтованих на ролі та орієнтованих на протоколи різновидів API для моделювання мережі Service в Kubernetes.

  • API-група
    Або також: API Group

    Набір повʼязаних шляхів в API Kubernetes.

    [+]

    Ви можете увімкнути або вимкнути кожну API-групу, змінивши конфігурацію свого API-сервера. Ви також можете вимкнути або увімкнути шляхи до конкретних ресурсів. API-група полегшує розширення API Kubernetes. API-група вказується в REST-шляху та в полі apiVersion серіалізованого обʼєкта.

    • Дивіться API-група для отримання додаткової інформації.
  • cAdvisor
    Або також: Container Advisor

    cAdvisor (Container Advisor) надає користувачам контейнерів розуміння використання ресурсів і характеристик продуктивності роботи контейнерів.

    [+]

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

  • cgroup (control group)

    Група процесів в середовищі Linux із можливістю ізоляції, обліку та встановлення обмежень ресурсів.

    [+]

    cgroup є функцією ядра Linux, яка обмежує, обліковує та ізолює використання ресурсів (центральний процесор, памʼять, введення/виведення даних на диск, мережа) для колекції процесів.

  • CIDR

    CIDR (Classless Inter-Domain Routing) — це нотація для опису блоків IP-адрес широко використовується в налаштуваннях конфігурації мережі.

    [+]

    У контексті Kubernetes кожному вузлу призначається діапазон IP-адрес за допомогою початкової адреси та маски підмережі за допомогою CIDR. Це дозволяє вузлам призначати кожному Podʼу унікальну IP-адресу. Попри те, що спочатку це була концепція для IPv4, CIDR також розширили на IPv6.

  • CLA
    Або також: Contributor License Agreemen, Ліцензійна угода учасника

    Умови, за якими учасник ліцензує свій внесок до проєкту з відкритими сирцями.

    [+]

    CLA допомагає вирішувати юридичні спори, повʼязані із наданим матеріалом та правами на інтелектуальну власність (IP, intellectual property).

  • Cloud Controller Manager

    Компонент панелі управління Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.

    [+]

    Відокремлюючи логіку сумісності між Kubernetes і базовою хмарною інфраструктурою, компонент cloud-controller-manager дає змогу хмарним провайдерам випускати функції з іншою швидкістю порівняно з основним проєктом Kubernetes.

  • Cloud Native Computing Foundation
    Або також: CNCF

    Cloud Native Computing Foundation (CNCF) створює стійку екосистему та сприяє розвитку спільноти навколо проєктів, які оркеструють контейнери як частину архітектури мікросервісів.

    Kubernetes є проєктом CNCF.

    [+]

    Фундація CNCF є частиною Linux Foundation. Її місія — зробити хмарні обчислення повсюдними.

  • ConfigMap

    Обʼєкт API, призначений для зберігання неконфіденційних даних у вигляді пар ключ-значення. Podʼи можуть використовувати ConfigMap як змінні середовища, аргументи командного рядка чи файли конфігурації у томі.

    [+]

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

  • containerd

    Середовище виконання контейнера з акцентом на простоту, надійність та переносимість.

    [+]

    containerd — це середовище виконання контейнера, яке працює як служба Linux або Windows. containerd відповідає за отримання та зберігання образів контейнерів, виконання контейнерів, забезпечення мережевого доступу та інше.

  • CRI-O

    Інструмент, який дозволяє використовувати середовище виконання контейнерів OCI з Kubernetes CRI.

    [+]

    CRI-O — це реалізація Інтерфейс середовища виконання контейнера, яка дозволяє використовувати середовище виконання контейнерів, сумісне зі специфікацією Open Container Initiative (OCI) runtime spec.

    Використання CRI-O дозволяє Kubernetes використовувати будь-яке середовище виконання контейнерів, сумісне з OCI, як середовище виконання контейнерів для запуску Podʼів, а також завантажувати OCI образи контейнерів з віддалених реєстрів.

  • CronJob

    Керує Job, який виконується за встановленим розкладом.

    [+]

    Подібно до рядка у файлі crontab, обʼєкт CronJob вказує розклад за допомогою формату cron.

  • CustomResourceDefinition

    Власний код, який визначає ресурс для додавання до сервера API вашого кластера Kubernetes без створення власного сервера.

    [+]

    Визначення власного ресурсу (Custom Resource Definitions) дозволяють розширювати API Kubernetes для вашого середовища, якщо публічно підтримувані ресурси API не можуть задовольнити ваші потреби.

  • DaemonSet

    Забезпечує запуск копії обʼєкта Pod на певному наборі вузлів у кластері.

    [+]

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

  • Data Plane
    Шар, який надає контейнерам ресурси, такі як ЦПУ, памʼять, мережа і сховище даних для того, щоб контейнери могли працювати та підʼєднуватись до мережі. [+]

    Шар, який надає контейнерам ресурси, такі як ЦПУ, памʼять, мережа і сховище даних для того, щоб контейнери могли працювати та підʼєднуватись до мережі.

  • Deployment

    Обʼєкт API, який керує реплікованим застосунком, зазвичай, запускаючи Podʼи без збереження стану.

    [+]

    Кожна репліка представлена Podʼом; Podʼи розподіляються серед вузлів кластера. Для робочих навантажень, які дійсно вимагають збереження стану, розгляньте використання StatefulSet.

  • Docker

    Docker (зокрема, Docker Engine) — це програмна технологія, яка забезпечує віртуалізацію на рівні операційної системи, також відому як контейнери.

    [+]

    Docker використовує функції ізоляції ресурсів ядра Linux, такі як cgroups та простори імен ядра, а також файлову систему, здатну до обʼєднання, таку як OverlayFS та інші, щоб дозволити незалежним контейнерам працювати в одному екземплярі Linux, уникаючи накладних витрат на запуск та підтримку віртуальних машин (ВМ).

  • Dockershim

    Dockershim є компонентом Kubernetes версії 1.23 та раніше. Він дозволяє kubelet взаємодіяти з Docker Engine.

    [+]

    Починаючи з версії 1.24, dockershim був вилучений з Kubernetes. Докладніше дивіться в Dockershim FAQ.

  • Downstream (розʼяснення)

    Може вказувати на: код в екосистемі Kubernetes, який залежить від основної кодової бази Kubernetes або відгалуженого репозиторію.

    [+]
    • У Спільноті Kubernetes: в розмові часто використовують термін downstream, щоб вказати на екосистему, код або інструменти сторонніх розробників, які залежать від основної кодової бази Kubernetes. Наприклад, нову функцію в Kubernetes можуть використовувати застосунки downstream для поліпшення їхньої функціональності.
    • У GitHub чи git: зазвичай відгалужений репозиторій називається downstream, тоді як висхідний репозиторій, репозиторій від якого було здійснено відгалуження, вважається upstream.
  • Downward API

    Механізм Kubernetes для надання значень полів Podʼа та контейнера коду, що працює в контейнері

    [+]

    Іноді контейнеру корисно мати інформацію про себе, без необхідності вносити зміни до коду контейнера, який безпосередньо зʼєднує його з Kubernetes.

    Механізм downward API Kubernetes дозволяє контейнерам використовувати інформацію про себе або їхній контекст в кластері Kubernetes. Застосунки в контейнерах можуть мати доступ до цієї інформації, без потреби для них діяти як клієнт Kubernetes API.

    Є два способи надання доступу до полів Podʼа та контейнера для робочого контейнера:

    Разом ці два способи надання доступу до полів Podʼів та контейнера називаються downward API.

  • Drain
    Або також: Злив, Очищення

    Процес безпечного виселення Podʼів з Node для підготовки до обслуговування або видалення з кластера.

    [+]

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

  • Endpoints
    Або також: Точки доступу

    Точка доступу Service — це один з Podʼів (або зовнішніх серверів), який реалізує Service.

    [+]

    Для Services з селекторами, контролер EndpointSlice автоматично створить один або кілька EndpointSlices з IP-адресами вибраних точок доступу Podʼів.

    EndpointSlices також можна створити вручну для позначення точок доступу Service, для яких не вказано селектор.

  • EndpointSlice

    EndpointSlices відстежують IP-адреси Podʼів з відповідними селекторами Service.

    [+]

    EndpointSlices можуть бути налаштовані вручну для Services без вказання селекторів.

  • etcd

    Сумісне та високодоступне сховище ключ-значення, яке використовується як сховище Kubernetes для резервування всіх даних кластера.

    [+]

    Якщо ваш кластер Kubernetes використовує etcd як сховище для резервування, переконайтеся, що у вас є план резервного копіювання даних.

    Ви можете знайти докладну інформацію про etcd в офіційній документації.

  • FlexVolume

    FlexVolume — інтерфейс, зараз визнаний застарілим, для створення втулків зовнішніх томів. Container Storage Interface — це новіший інтерфейс, який вирішує кілька проблем з FlexVolume.

    [+]

    FlexVolumes дозволяють користувачам писати свої власні драйвери та додавати підтримку своїх томів в Kubernetes. Бінарні файли та залежності драйверів FlexVolume повинні бути встановлені на машинах-хостах. Це вимагає прав адміністратора. Група Storage SIG рекомендує використовувати CSI драйвер, якщо це можливо, оскільки він вирішує обмеження, повʼязані з FlexVolumes.

  • Helm Chart

    Набір попередньо налаштованих ресурсів Kubernetes, якими можна керувати за допомогою Helm.

    [+]

    Чарти надають відтворюваний спосіб створення та обміну застосунками Kubernetes. Один чарт може бути використаний для розгортання чогось простого, наприклад, контейнера Memcached, або щось складного, наприклад, повного стека вебзастосунків з серверами HTTP, базами даних, кешем та іншими складовими.

  • HostAliases

    HostAliases — це зіставлення між IP-адресою та імʼям хосту, яке додається у файл hosts Podʼа.

    [+]

    HostAliases — це опціональний список імен хостів та IP-адрес, які будуть вставлені в файл hosts Podʼа, якщо вказано. Це є дійсним лише для Podʼів non-hostNetwork.

  • Ingress
    Або також: Вхід

    Обʼєкт API, який управляє зовнішнім доступом до служб в кластері, зазвичай HTTP.

    [+]

    Ingress може надавати балансування навантаження, розшифровування SSL-трафіку та віртуальний хостинг на основі імен.

  • Istio

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

    [+]

    Додавання Istio не вимагає зміни коду застосунку. Istio є шаром інфраструктури між Service та мережею, який, спільно з розгортанням служб, часто називається сервісною сіткою (service mesh). Панель управління Istio абстрагується від базової платформи управління кластером, якою може бути Kubernetes, Mesosphere і т.д.

  • Job
    Або також: Завдання

    Скінченне або пакетне завдання, яке виконується до завершення.

    [+]

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

  • JSON Web Token
    Або також: JWT

    Засіб представлення вимог для передачі між двома сторонами.

    [+]

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

  • kOps (Kubernetes Operations)

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

    [+]

    kOps — це автоматизована система управління:

    • Повністю автоматизована установка
    • Використовує DNS для ідентифікації кластерів
    • Самовідновлення: все працює в групах автоматичного масштабування
    • Підтримка різних операційних систем (Amazon Linux, Debian, Flatcar, RHEL, Rocky та Ubuntu)
    • Підтримка високої доступності
    • Може безпосередньо надавати інфраструктуру або генерувати маніфести terraform
  • kube-controller-manager

    Компонент панелі управління, який запускає процеси контролера.

    [+]

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

  • kube-proxy

    kube-proxy є мережевим проксі, що запущений на кожному вузлі кластера і реалізує частину концепції Kubernetes Service.

    [+]

    kube-proxy забезпечує підтримання мережевих правил на вузлах. Ці правила обумовлюють підключення мережею до ваших Podʼів всередині чи поза межами кластера.

    kube-proxy використовує шар фільтрації пакетів операційної системи, за його наявності. В іншому випадку kube-proxy скеровує трафік самостійно.

  • kube-scheduler

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

    [+]

    При виборі вузла враховуються наступні фактори: індивідуальна і колективна потреба у ресурсах, обмеження за апаратним/програмним забезпеченням і політиками, характеристики affinity та anti-affinity, локальність даних, сумісність робочих навантажень і граничні терміни виконання.

  • Kubeadm

    Інструмент для швидкого встановлення Kubernetes та налаштування захищеного кластера.

    [+]

    Ви можете використовувати kubeadm для встановлення як панелі управління, так і компонентів робочих вузлів.

  • Kubectl
    Або також: kubectl

    Інструмент командного рядка для взаємодії із кластером Kubernetes, панеллю управління, використовуючи API Kubernetes.

    [+]

    Ви можете використовувати kubectl для створення, перегляду, оновлення та видалення обʼєктів Kubernetes.

    Англійською, kubectl (офіційно) вимовляється як /kjuːb/ /kənˈtɹəʊl/ (типу "cube control").

  • Kubelet

    Агент, запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів в Podʼах.

    [+]

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

  • LimitRange

    Впроваджує ліміти для обмеження обсягу споживання ресурсів для кожного контейнера чи Podʼа в просторі імен.

    [+]

    LimitRange обмежує кількість обʼєктів, які можна створити за типом, а також обсяг обчислювальних ресурсів, які можуть бути затребувані/спожиті окремими контейнерами чи Podʼами в просторі імен.

  • Logging

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

    [+]

    Логи застосунків та системи можуть допомогти вам зрозуміти, що відбувається всередині вашого кластера. Ці логи особливо корисні для виправлення проблем та моніторингу активності кластера.

  • Managed Service

    Програмне забезпечення, що підтримується стороннім постачальником.

    [+]

    Деякі приклади Managed Services: AWS EC2, Azure SQL Database та GCP Pub/Sub, але це може бути будь-яке програмне забезпечення, що може бути використане застосунком.

  • Master

    Застарілий термін, використовується як синонім для вузлів, на яких розміщено панель управління.

    [+]

    Цей термін все ще використовується деякими інструментами для надання послуг, такими як kubeadm, та сервісами, що надаються постачальниками послуг, для позначення мітками вузлів за допомогою kubernetes.io/role та контролю розташування панелі управління Podʼів.

  • Minikube

    Інструмент для локального запуску Kubernetes.

    [+]

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

  • Mixed Version Proxy (MVP)
    Або також: MVP

    Функціонал, який дозволяє kube-apiserver перенаправити запит на ресурс до іншого API-сервера.

    [+]

    Коли в кластері працюють різні версії Kubernetes на різних API-серверах, ця функція дозволяє правильно обслуговувати запити до ресурсів за допомогою відповідного API-сервера.

    MVP стандартно вимкнено і може бути активовано, увімкненням функціонала UnknownVersionInteroperabilityProxy при запуску API-сервера.

  • Name

    Наданий клієнтом рядок, який посилається на обʼєкт в URL ресурсу, наприклад /api/v1/pods/some-name.

    [+]

    Тільки один обʼєкт вказаного виду (kind) може мати вказану назву одночасно. Проте, якщо ви видаляєте обʼєкт, ви можете створити новий обʼєкт з такою ж назвою.

  • Namespace
    Або також: Простір імен

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

    [+]

    Простори імен використовуються для організації обʼєктів в кластері та надають можливість поділу ресурсів кластера. Імена ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Простори імен застосовуються лише до обʼєктів, які належать до простору імен (наприклад, Deployments, Services і т.д.), і не застосовуються до обʼєктів, які є загальними для кластера (наприклад, StorageClass, Nodes, PersistentVolumes, і т.д.).

  • Network Policy
    Або також: Мережева політика

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

    [+]

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

  • Persistent Volume

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

    [+]

    PersistentVolumes (PVs) надають API, який абстрагує деталі того, як забезпечується зберігання від того, як воно використовується. PVs використовуються безпосередньо в сценаріях, де сховище може бути створено заздалегідь (статичне розподілення). Для сценаріїв, які вимагають сховища на вимогу (динамічне розподілення), замість цього використовуються PersistentVolumeClaims (PVCs).

  • Persistent Volume Claim

    Запит на використання ресурсів зберігання, визначених у PersistentVolume, для їх монтування як томів в контейнері.

    [+]

    Визначає обсяг сховища, спосіб доступу до сховища (тільки для читання, для читання та запису та/або виключний доступ) та спосіб його вилучення (збережений, перероблений або видалений). Деталі щодо самого сховища описані в обʼєкті PersistentVolume.

  • Pod

    Найменший та найпростіший обʼєкт Kubernetes. Pod являє собою групу контейнерів, що запущені у вашому кластері.

    [+]

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

  • PodTemplate
    Або також: pod template

    Обʼєкт API, який визначає шаблон для створення Podʼів. PodTemplate API також вбудований у визначення API для управління робочими навантаженнями, такими як Deployment або StatefulSets.

    [+]

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

  • PriorityClass

    PriorityClass — це іменований клас для пріоритету планування, який слід призначити Podʼу у цьому класі.

    [+]

    PriorityClass — це обʼєкт, який не належить до жодного простору імен, який зіставляє назву з цілочисельним пріоритетом, що використовується для Podʼа. Назва вказується в полі metadata.name, а значення пріоритету — у полі value. Пріоритети коливаються від -2147483648 до 1000000000 включно. Вищі значення вказують на вищий пріоритет.

  • Replica

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

    [+]

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

    Визначаючи кількість реплік в обʼєкті Deployment або ReplicaSet, Kubernetes переконується, що вказана кількість екземплярів працює, автоматично коригуючи кількість за необхідності.

    Управління репліками дозволяє ефективно балансувати навантаження, виконувати поетапні оновлення та забезпечує можливості самовідновлення в кластері Kubernetes.

  • ReplicaSet

    Обʼєкт ReplicaSet (має на меті) підтримувати набір реплік обʼєктів Pod, які завжди працюють в будь-який момент часу.

    [+]

    Обʼєкти робочого навантаження, такі як Deployment, використовують ReplicaSet для забезпечення того, що налаштована кількість Podʼів працювала у вашому кластері на основі конфігурації цього ReplicaSet.

  • ReplicationController

    Ресурс робочого навантаження, який керує реплікованим застосунком, забезпечуючи наявність певної кількості екземплярів обʼекта Pod.

    [+]

    Панель управління забезпечує, що визначена кількість екземплярів Pod працює, навіть якщо деякі Podʼи зазнають збою, якщо ви видаляєте Pod вручну або якщо помилково їх запускається забагато.

  • Secret
    Або також: Секрет

    Зберігає конфіденційну інформацію, таку як паролі, токени OAuth та ключі SSH.

    [+]

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

    Pod може посилатися на Secret різними способами, такими як монтування тому, чи як змінна середовища. Secretʼи призначені для конфіденційних даних, а ConfigMaps призначені для неконфіденційних даних.

  • Service

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

    [+]

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

    Serviceʼи Kubernetes можуть використовувати IP-мережу (IPv4, IPv6 або обидві) або посилатися на зовнішнє імʼя в Domain Name System (DNS).

    Абстракція Service дозволяє використовувати інші механізми, такі як Ingress та Gateway.

  • ServiceAccount
    Або також: Службовий обліковий запис

    Забезпечує ідентифікацію для процесів, які працюють в Podʼі.

    [+]

    Коли процеси всередині Podʼів отримують доступ до кластера, їх автентифікує сервер API як певний службовий обліковий запис, наприклад, default. При створенні Podʼа, якщо ви не вказали службовий обліковий запис, йому автоматично буде призначений типовий службовий обліковий запис у тому ж Namespace.

  • Shuffle-sharding

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

    [+]

    Ми часто переймаємось ізоляцією різних потоків запитів один від одного, щоб інтенсивний потік не витісняв менш інтенсивні потоки. Простий спосіб розміщення запитів у черзі — хешування деяких характеристик запиту за модулем кількості черг, щоб отримати індекс черги для використання. Хеш-функція використовує вхідні характеристики запиту, які відповідають потокам. Наприклад, в Інтернеті це часто кортеж з 5 елементів: адреси джерела та призначення, протоколу та порту джерела та призначення.

    Ця проста схема, заснована на хешуванні, має властивість того, що будь-який інтенсивний потік витісняє всі менш інтенсивні потоки, які хешуються в ту ж чергу. Для забезпечення хорошої ізоляції для великої кількості потоків потрібна велика кількість черг, що є проблематичним. Shuffle-sharding — це легша техніка, яка може краще ізолювати менш інтенсивні потоки від більш інтенсивних. Термінологія shuffle-sharding використовує метафору роздачі карт з колоди; кожна черга — це метафорична карта. Техніка shuffle-sharding починається з хешування характеристик, які ідентифікують потік запитів, для створення хеш-значення з десятками або більше бітів. Потім значення хешу використовується як джерело ентропії для перемішування колоди та роздачі карт на руки (черг). Оглядаються всі роздані черги, і запит поміщається в одну з оглянутих черг з найкоротшою довжиною. З помірним розміром руки не треба оглядати всі роздані карти, і у менш інтенсивного потоку є хороші шанси уникнути впливів більш інтенсивного потоку. З великим розміром руки дорого оглядати роздані черги та складніше для менш інтенсивних потоків уникнути колективних ефектів набору більш інтенсивних потоків. Таким чином, розмір руки повинен бути розумно обраний.

  • Sidecar контейнер

    Один чи кілька контейнерів, які зазвичай стартують до запуску будь-яких контейнерів застосунків.

    [+]

    Sidecar контейнери схожі на звичайні контейнери застосунків, але вони мають інше призначення: sidecar контейнер надає локальні послуги для Podʼа основному контейнеру застосунку. На відміну від контейнерів ініціалізації, sidecar контейнери продовжують виконуватися після запуску Podʼа.

    Докладніше дивіться Sidecar контейнери.

  • SIG
    Або також: Special Interest Group

    Члени спільноти, які спільно керують тривалим процесом або аспектом великого відкритого проєкту Kubernetes.

    [+]

    Члени в межах SIG мають спільний інтерес у розвитку певної області, такої як архітектура, машинерія API або документація. SIG повинні дотримуватися настанов з управління, але вони можуть мати свої власні правила участі та канали комунікації.

    Для отримання додаткової інформації див. репозиторій kubernetes/community та поточний список SIG та робочих груп.

  • Spec
    Або також: Специфікація

    Визначає, як слід налаштовувати кожен обʼєкт, такий як Pod або Service, та його бажаний стан.

    [+]

    Практично кожен обʼєкт Kubernetes має два вкладені поля обʼєкта, які визначають конфігурацію обʼєкта: spec та status. Для обʼєктів, які мають специфікацію (spec), ви повинні встановити її при створенні обʼєкта, надаючи опис характеристик, які ви хочете, щоб ресурс мав — його бажаний стан.

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

  • StatefulSet

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

    [+]

    Схожий на Deployment, StatefulSet керує Podʼами, які базуються на ідентичній специфікації контейнерів. На відміну від Deployment, StatefulSet зберігає постійну ідентичність для кожного свого Podʼа. Ці Podʼи створюються за однаковою специфікацією, але не є взаємозамінними: у кожного є постійний ідентифікатор, який він утримує при переплануванні.

    Якщо ви хочете використовувати томи для забезпечення постійності для вашого завдання, ви можете використовувати StatefulSet як частину рішення. Навіть якщо окремі Podʼи в StatefulSet можуть вийти з ладу, постійні ідентифікатори Podʼів полегшують відповідність наявних томів новим Podʼам, які замінюють ті, що вийшли з ладу.

  • Static Pod

    Pod, яким управляє безпосередньо демон kubelet на певному вузлі,

    [+]

    без його спостереження через сервер API.

    Static Pod не підтримують ефемерні контейнери.

  • Storage Class
    Або також: Клас сховища

    StorageClass надає можливість адміністраторам описати різні доступні типи сховищ.

    [+]

    Класи сховища можуть відповідати рівням обслуговування, політиці резервного копіювання або довільними правилами, визначеними адміністраторами кластера. Кожен клас сховища містить поля provisioner, parameters та reclaimPolicy, які використовуються, коли динамічно резервується Persistent Volume, що належить класу. Користувачі можуть запитувати певний клас, використовуючи імʼя обʼєкта класу сховища.

  • sysctl

    sysctl — це напівстандартизований інтерфейс для читання або зміни атрибутів ядра Unix.

    [+]

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

    Контейнер та мережеві втулки можуть покладатися на значення sysctl встановлені певним чином.

  • Taint
    Або також: Позначка, Заплямованість

    Основний обʼєкт, що складається з трьох обовʼязкових властивостей: key, value, та effect. Taints (додаткові властивості) запобігають розміщенню Podʼів на вузлах чи групах вузлів.

    [+]

    Taints та tolerations співпрацюють, щоб забезпечити те, що Podʼи не розміщуються на непридатних вузлах. Один чи декілька taint застосовуються до вузла. Вузол повинен розміщувати лише Podʼи з tolerations, що збігаються з налаштованими taints.

  • Toleration
    Або також: Толерантність

    Основний обʼєкт, що складається з трьох обовʼязкових властивостей: key, value, та effect. Toleration (дозвіл) дозволяє розміщення Podʼів на вузлах чи групах вузлів, які мають відповідні taints.

    [+]

    Tolerations та taints співпрацюють, щоб забезпечити те, що Podʼи не розміщуються на непридатних вузлах. Один чи декілька tolerations застосовуються до Podʼа. Toleration вказує, що Pod може (але не обовʼязково) бути розміщеним на вузлах чи групах вузлів із відповідними taints.

  • UID

    Рядок, створений системами Kubernetes для унікальної ідентифікації обʼєктів.

    [+]

    Кожен обʼєкт, створений протягом усього життя кластера Kubernetes, має відмінний UID. Він призначений для відмінності між історичними випадками схожих сутностей.

  • Upstream (розʼяснення)

    Може вказувати на: основний код Kubernetes або вихідний репозитарій, з якого було зроблено форк репозиторію.

    [+]
    • В Спільноті Kubernetes: В розмовах термін upstream часто використовується для позначення основного коду Kubernetes, на якому ґрунтуються загальна екосистема, інший код або інструменти сторонніх розробників. Наприклад, члени спільноти можуть пропонувати перемістити функцію в upstream, щоб вона була в основному коді, а не у втулку чи інструменті стороннього розробника. * В GitHub або git: Зазвичай вихідний репозитарій називається upstream, тоді як репозитарій, який був зроблений як форк, вважається downstream.
  • user namespace

    Функція ядра Linux для емуляції привілеїв суперкористувача. Використовується для "контейнерів без прав root".

    [+]

    Простори імен користувача — це особливість ядра Linux, яка дозволяє користувачеві без прав root емулювати привілеї суперкористувача ("root"), наприклад, для запуску контейнерів без прав root поза контейнером.

    Простір імен користувача ефективно застосовується для помʼякшення наслідків можливих атак на прорив з контейнера.

    У контексті просторів імен користувача термін "простір імен" вказує на особливість ядра Linux, а не на простір імен у розумінні Kubernetes.

  • Volume Plugin

    Втулок томів дозволяє інтеграцію сховища усередині Podʼа.

    [+]

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

  • Watch
    Або також: Спостереження

    Дієслово, яке використовується для відстеження змін обʼєкта в Kubernetes у вигляді потоку. Використовується для ефективного виявлення змін.

    [+]

    Дієслово, яке використовується для відстеження змін обʼєкта у Kubernetes у вигляді потоку. Watch дозволяє ефективно виявляти зміни; наприклад, контролер, якому потрібно знати, коли змінюється ConfigMap, може використовувати watch, а не опитування.

    Ознайомтесь з Ефективним виявленням змін у концепціях API для отримання додаткової інформації.

  • Анотація
    Або також: Annotation

    Ключ-значення, які використовуються для додавання довільних невизначених метаданих до обʼєктів.

    [+]

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

  • Архітектор застосунків
    Або також: Application Architect

    Особа, відповідальна за високорівневий дизайн застосунку.

    [+]

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

  • Архітектор кластера

    Особа, яка проєктує інфраструктуру, що включає один чи кілька кластерів Kubernetes.

    [+]

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

  • Випередження
    Або також: Preemption

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

    [+]

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

  • Виселення
    Або також: Eviction

    Виселення — це процес завершення роботи одного чи декількох Podʼів на Вузлах.

    [+]
  • Виселення через тиск на вузол
    Або також: kubelet eviction, Node-pressure eviction

    Виселення через тиск на вузол — це процес, при якому kubelet активно завершує роботу Podʼів для звільнення ресурсів на вузлах.

    [+]

    Kubelet веде моніторинг ресурсів, таких як ЦП, памʼять, місце на диску та inode файлової системи на вузлах вашого кластера. Коли один або кілька з цих ресурсів досягають певних рівнів використання, kubelet може активно завершувати роботу одного або кількох Podʼів на вузлі для звільнення ресурсів та запобігання їх нестачі.

    Виселення через тиск на вузол не є тим самим, що й Виселення, ініційоване API.

  • Виселення, ініційоване API
    Або також: API-initiated eviction

    Виселення, ініційоване API — процес, під час якого використовується Eviction API для створення обʼєкта Eviction, який викликає належне завершення роботи Podʼа.

    [+]

    Ви можете зробити запит на виселення, якщо ви напряму звертаєтесь до Eviction API з використанням клієнта kube-apiserver, такого як команда kubectl drain. Коли створюється обʼєкт Eviction, сервер API завершує роботу Podʼа.

    Виселення, ініційоване API дотримуються параметрів PodDisruptionBudgets та terminationGracePeriodSeconds.

    Виселення, ініційоване API не є тим самим, що й виселення через тиск на вузол.

  • Втулок пристрою
    Або також: device plugin

    Втулки пристроїв працюють на вузлах кластера (Nodes) та забезпечують Podʼам доступ до ресурсів, таких як локальне обладнання, яке вимагає вендор-специфічної ініціалізації чи налаштувань.

    [+]

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

    Докладніше дивіться в розділі Втулки пристроїв.

  • Вузол
    Або також: Node

    Вузол — це робоча машина в Kubernetes.

    [+]

    Робочий вузол може бути віртуальною машиною або фізичною машиною, залежно від кластера. На ньому працюють локальні служби або служби, необхідні для виконання Podʼів, і ним керує панель управління. Демони на вузлі включають kubelet, kube-proxy та середовище виконання контейнерів, яке реалізує CRI, наприклад Docker.

    В ранніх версіях Kubernetes вузли називалися "Minions" (Міньйони).

  • Горизонтальне автомасштабування Podʼа
    Або також: HPA, Horizontal Pod Autoscaler

    Ресурс API, який автоматично масштабує кількість реплік Podʼа на основі вказаних параметрів використання ЦП або власних метрик.

    [+]

    Горизонтальне автомасштабування Podʼа (HPA) зазвичай використовується з ReplicationControllers, Deployments або ReplicaSets. Його неможливо застосувати до обʼєктів, які не можна масштабувати, наприклад, DaemonSets.

  • Групова Версія Ресурсу
    Або також: GVR, Group Version Resource

    Спосіб представлення унікального ресурсу API Kubernetes.

    [+]

    Групова Версія Ресурсу (GVR) вказує API-групу, версію API та ресурс (імʼя для виду обʼєкта, як воно вказане в URI), повʼязана з доступом до певного ідентифікатора обʼєкта в Kubernetes. GVR дозволяють вам визначати та відрізняти різні обʼєкти Kubernetes та вказувати спосіб доступу до обʼєктів, який є стабільним навіть при зміні API.

  • Дзеркальний Pod
    Або також: Mirror Pod

    Pod, який kubelet використовує для представлення статичного Podʼа.

    [+]

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

    (Наприклад, видалення дзеркального Podʼа не зупинить демона kubelet від його запуску).

  • Динамічне створення томів сховища
    Або також: Dynamic Volume Provisioning

    Дозволяє користувачам автоматично створювати Томи сховища за запитом.

    [+]

    Динамічне створення томів усуває потребу в адміністраторів кластерів у попередньому їх створені. Замість цього сховища автоматично створюються за запитом користувача. Динамічне створення томів ґрунтується на обʼєкті API, StorageClass, який посилається на втулок тому, що створює Том, та набір параметрів для передачі до втулка тому.

  • Ефемерний Контейнер
    Або також: Ephemeral Container

    Тип контейнера, який можна тимчасово запустити всередині Podʼа.

    [+]

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

    Ефемерні контейнери не підтримуються статичними Podʼами.

  • Життєвий цикл Podʼа
    Або також: Pod Lifecycle

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

    [+]

    Життєвий цикл Podа визначається станами або фазами Podʼа. Існує пʼять можливих фаз Podʼа: Pending, Running, Succeeded, Failed та Unknown. Високорівневий опис стану Podʼа знаходиться в полі phase PodStatus.

  • Завершувач
    Або також: Finalizer

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

    [+]

    Коли ви наказуєте Kubernetes видалити обʼєкт, для якого є завершувачі, API Kubernetes позначає обʼєкт для видалення, заповнюючи поле .metadata.deletionTimestamp, і повертає статус-код 202 (HTTP "Accepted"). Цільовий обʼєкт залишається в стані завершення, поки панель управління чи інші компоненти виконують дії, визначені завершувачами. Після завершення цих дій контролер видаляє відповідні завершувачі з цільового обʼєкта. Коли поле metadata.finalizers порожнє, Kubernetes вважає видалення завершеним і видаляє обʼєкт.

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

  • Застосунки
    Або також: Applications
    Шар, в якому виконуються різноманітні контейнеризовані застосунки. [+]

    Шар, в якому виконуються різноманітні контейнеризовані застосунки.

  • Затверджувач
    Або також: Approver

    Особа, яка може переглядати та схвалювати внесок до коду Kubernetes.

    [+]

    Тоді як перевірка коду зосереджена на якості та правильності коду, схвалення зосереджено на цілісному прийнятті внеску. Цілісне прийняття включає зворотну/пряму сумісність, дотримання умов API та прапорців, неявні проблеми з продуктивністю та правильністю, взаємодію з іншими частинами системи та інші. Статус затверджувача поширюється на частину кодової бази. Затверджувачі раніше називалися супроводжувачами.

  • Збирання сміття
    Або також: Garbage Collection

    Збирання сміття — це загальний термін для різних механізмів, які Kubernetes використовує для очищення ресурсів кластера.

    [+]

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

  • Змінні середовища контейнера

    Змінні середовища контейнера — це пари name=value, які надають корисну інформацію контейнерам, які працюють у Podʼі.

    [+]

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

  • Інтерфейс зберігання контейнерів (CSI)
    Або також: Container Storage Interface, CSI

    Інтерфейс зберігання контейнерів (CSI) визначає стандартний інтерфейс для взаємодії з системами зберігання з контейнерами.

    [+]

    CSI дозволяє вендорам створювати спеціальні втулки зберігання для Kubernetes, не включаючи їх до репозиторію Kubernetes (зовнішні втулки). Щоб використовувати драйвер CSI від постачальника зберігання, спочатку потрібно розгорнути його у вашому кластері. Після цього ви зможете створити клас зберігання (Storage Class), який використовує цей драйвер CSI.

  • Інтерфейс середовища виконання контейнера
    Або також: Container Runtime Interface, CRI

    Основний протокол для взаємодії між kubelet та середовищем виконання контейнерів.

    [+]

    Інтерфейс виконання контейнерів Kubernetes (CRI) визначає основний gRPC протокол для звʼязку між компонентами вузла kubelet та середовищем виконання контейнерів.

  • Інфраструктура кластера

    Шар інфраструктури, що надає та забезпечує віртуальні машини, мережі, групи безпеки та інші елементи.

    [+]
  • Квоти ресурсів

    Впроваджує обмеження, які обмежують загальне споживання ресурсів для кожного Namespace.

    [+]

    Обмежує кількість обʼєктів, які можна створити в просторі імен за типом, а також загальний обсяг ресурсів обчислювального характеру, які можуть бути спожиті ресурсами в проєкті.

  • Керування доступом на основі ролей
    Або також: RBAC, Role-Based Access Control

    Управління рішеннями з авторизації, яке дозволяє адміністраторам динамічно налаштовувати політики доступу через API Kubernetes.

    [+]

    RBAC використовує чотири типи обʼєктів Kubernetes:

    Role
    Визначає правила дозволів у певному просторі імен.
    ClusterRole
    Визначає правила дозволів для всього кластера.
    RoleBinding
    Надає дозволи, визначені в ролі, набору користувачів у певному просторі імен.
    ClusterRoleBinding
    Надає дозволи, визначені в ролі, набору користувачів у всьому кластері.

    Докладніше дивіться RBAC.

  • Кількість
    Або також: Quantity, Обсяг

    Представлення цілих чисел малих або великих чисел за допомогою суфіксів SI.

    [+]

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

    Наприклад, число 1.5 представляється як 1500m, тоді як число 1000 можна представити як 1k, а 1000000 як 1M. Ви також можете вказати суфікси у бінарному форматі; число 2048 можна записати як 2Ki.

    Прийняті десяткові (за основою 10) одиниці — це m (мілі), k (кіло, свідомо в нижньому регістрі), M (мега), G (гіга), T (тера), P (пета), E (екса).

    Прийняті двійкові (за основою 2) одиниці — це Ki (кібі), Mi (мебі), Gi (гібі), Ti (тебі), Pi (пебі), Ei (ексбі).

  • Клас обслуговування QoS
    Або також: QoS Class

    Клас обслуговування QoS (Quality of Service Class) надає можливість Kubernetes класифікувати Podʼи в кластері в декілька класів і приймати рішення щодо їх планування та видалення.

    [+]

    Клас QoS Podʼа встановлюється під час створення на основі його налаштувань обчислювальних ресурсів (запити та обмеження). Класи QoS використовуються для прийняття рішень щодо планування та видалення Podʼів. Kubernetes може присвоїти один із наступних класів QoS Podʼу: Guaranteed, Burstable або BestEffort.

  • Кластер

    Набір робочих машин, що називаються вузлами, які виконують контейнеризовані застосунки. Кожен кластер має принаймні один робочий вузол.

    [+]

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

  • Контейнер

    Легкий та переносний виконуваний образ, який містить програмне забезпечення та всі його залежності.

    [+]

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

  • Контейнер застосунку

    Контейнери застосунків — це контейнери в Podʼі, які запускаються після завершення роботи будь-яких контейнерів ініціалізації.

    [+]

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

  • Контейнер ініціалізації
    Або також: Init Container

    Один чи кілька контейнерів ініціалізації, які повинні повністю виконати та завершити дію, перед тим як будь-які контейнери застосунків почнуть виконуватися

    [+]

    Контейнери ініціалізації (init) схожі на звичайні контейнери застосунків, з однією відмінністю: контейнери ініціалізації повинні завершити виконання, перед тим як будь-які контейнери застосунків почнуть виконуватись. Контейнери ініціалізації виконуються послідовно: кожен контейнер ініціалізації повинен закінчити виконання, перед тим як почнеться виконання наступного контейнера ініціалізації.

    На відміну від sidecar контейнерів контейнери ініціалізації не залишаються працювати після запуску Podʼа.

    Докладніше дивіться контейнери ініціалізації.

  • Контекст Безпеки
    Або також: Security Context

    Поле securityContext визначає налаштування привілеїв та контролю доступу для Podʼа або контейнера.

    [+]

    У securityContext можна визначити: користувача, яким виконуються процеси, групу, якою виконуються процеси, та налаштування привілеїв. Також можна налаштувати політики безпеки (наприклад: SELinux, AppArmor чи seccomp).

    Налаштування PodSpec.securityContext застосовується до всіх контейнерів в Podʼі.

  • Контролер

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

    [+]

    Контролери спостерігають за загальним станом вашого кластера через apiserver (частина Панелі управління).

    Деякі контролери також працюють всередині панелі управління, забезпечуючи цикли управління, які є ключовими для операцій Kubernetes. Наприклад, контролер Deployment, контролер DaemonSet, контролер Namespace та контролер постійних томів (і інші) всі працюють всередині kube-controller-manager.

  • Контролер допуску
    Або також: Admission Controller

    Фрагмент коду, який перехоплює запити до сервера API Kubernetes перед збереженням обʼєкта.

    [+]

    Контролери допуску налаштовуються для API сервера Kubernetes і можуть бути "перевіряючими", "мутаційними" або обома. Будь-який контролер допуску може відхилити запит. Мутаційні контролери можуть модифікувати обʼєкти, які вони пропускають; перевіряючі контролери цього робити не можуть.

  • Манфіест

    Специфікація обʼєкта API Kubernetes у форматі JSON або YAML.

    [+]

    Маніфест вказує бажаний стан обʼєкта, який Kubernetes буде підтримувати при застосуванні маніфесту. У випадку YAML, конфігураційний файл може містити кілька маніфестів.

  • Мережевий інтерфейс контейнера
    Або також: Container Network Interface, CNI

    Втулки мережевого інтерфейсу контейнера (CNI) є типом мережевих втулків, які відповідають специфікації appc/CNI.

    [+]
  • Мітка
    Або також: Label

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

    [+]

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

  • Надбудови
    Або також: Add-ons

    Ресурси, які розширюють функціональність Kubernetes.

    [+]

    Інструкції щодо встановлення надбудов надають більше інформації щодо використання надбудов у вашому кластері та перераховують деякі популярні надбудови.

  • Незмінна інфраструктура
    Або також: Immutable Infrastructure

    Незмінна інфраструктура — це компʼютерна інфраструктура (віртуальні машини, контейнери, мережеві пристрої), яка не може бути змінена після розгортання.

    [+]

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

    Запобігаючи або виявляючи несанкціоновані зміни, незмінні інфраструктури спрощують ідентифікацію та помʼякшення ризиків безпеки. Управління такою системою стає набагато очевиднішим, оскільки адміністратори можуть робити припущення що до неї. Вони знають, що ніхто не припустився помилки або змін, про які вони забули сповістити. Незмінна інфраструктура йде рука об руку з інфраструктурою як кодом, де вся автоматизація, необхідна для створення інфраструктури, зберігається у системі контролю версій (такій як Git). Ця комбінація незмінності та контролю версій означає, що є надійний лог аудиту кожної санкціонованої зміни в системі.

  • Обʼєкт

    Сутність у системі Kubernetes. Обʼєкт є ресурсом API, який API Kubernetes використовує для представлення стану вашого кластера.

    [+]

    Обʼєкт Kubernetes зазвичай є "записом наміру" — коли ви створюєте обʼєкт, панель управління Kubernetes постійно працює над тим, щоб забезпечити існування представленого ним елемента. Створюючи обʼєкт, ви повідомляєте системі Kubernetes, як ви хочете, щоб ця частина робочого навантаження вашого кластера виглядала; це бажаний стан вашого кластера.

  • Обмеження переривання роботи Podʼів
    Або також: PDB, Pod Disruption Budget

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

    [+]

    PDB не можуть запобігти невільним розладам; однак вони зараховуються до бюджету.

  • Образ
    Або також: Image

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

    [+]

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

  • Оператор кластера

    Особа, яка налаштовує, керує та стежить за роботою кластера.

    [+]

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

  • Панель управління
    Або також: Control Plane, master

    Шар оркестрування контейнерів, який надає API та інтерфейси для виявлення, розгортання та управління життєвим циклом контейнерів.

    [+]

    Цей шар складається з багатьох різних компонентів, таких як (але не обмежуючись):

    Ці компоненти можуть працювати як традиційні служби операційної системи (демони) або як контейнери. Хости, на яких працюють ці компоненти, історично називалися master.

  • Подія
    Або також: Event

    Подія – це обʼєкт Kubernetes, який описує зміну стану або помітні події в системі.

    [+]

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

    Події слід розглядати як інформаційні дані, що надаються як найкраще, та які є додатковими даними.

    У Kubernetes аудит генерує інший вид Подій (API-група audit.k8s.io).

  • Політики безпеки Podʼа
    Або також: Pod Security Policy

    Дозволяють деталізовану авторизацію створення та оновлення Podʼів.

    [+]

    Ресурс на рівні кластера, який контролює аспекти безпеки, що стосуються специфікації Podʼа. Обʼєкти PodSecurityPolicy визначають набір умов, якими повинен відповідати Pod, щоб його можна було прийняти в систему, а також стандартні значення для повʼязаних полів. Керування політикою безпеки Podʼа реалізується як додатковий контролер допуску.

    Починаючи з Kubernetes v1.21, PodSecurityPolicy визнано застарілими, а з v1.25 — видалено. Як альтернативу, використовуйте Pod Security Admission або сторонній втулок допуску.

  • Постачальник хмарних послуг
    Або також: Cloud Service Provider, Cloud Provider, CSP

    Бізнес або інша організація, яка пропонує платформу для хмарних обчислень.

    [+]

    Постачальники хмарних послуг (CSP, Cloud Service Providers), пропонують платформи або послуги хмарних обчислень.

    Багато хмарних постачальників пропонують керовану інфраструктуру (також називається Інфраструктура як Сервіс або IaaS). З керованою інфраструктурою хмарний постачальник відповідає за сервери, зберігання та мережу, тоді як ви керуєте рівнями поверх цього, такими як запуск кластера Kubernetes.

    Вони також можуть пропонувати Kubernetes як керований сервіс; іноді його називають Платформою як Сервіс, або PaaS. З управлінням Kubernetes ваш хмарний постачальник відповідає за панель управління Kubernetes, а також за вузли та інфраструктуру, на яку вони покладаються: мережа, зберігання, і, можливо, інші елементи, такі як балансувальники навантаження.

  • Пріоритет Podʼа

    Пріоритет Podʼа вказує на важливість Podʼа в порівнянні з іншими Podʼами.

    [+]

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

  • Проба
    Або також: Probe

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

    [+]

    Для отримання додаткової інформації читайте проби контейнера.

  • Проксі
    Або також: Proxy

    У компʼютерних науках проксі — це сервер, який діє як посередник для віддалених служб.

    [+]

    Клієнт взаємодіє з проксі; проксі копіює дані клієнта на реальний сервер; реальний сервер відповідає проксі; проксі надсилає відповідь реального сервера клієнту.

    kube-proxy — це мережевий проксі, який працює на кожному вузлі вашого кластера, реалізуючи частину концепції Service в Kubernetes.

    Ви можете запускати kube-proxy як звичайний сервіс проксі на рівні користувача. Якщо ваша операційна система це підтримує, ви можете запускати kube-proxy в гібридному режимі, який досягає того самого результату, використовуючи менше системних ресурсів.

  • Ресурс (інфраструктура)

    Можливості, що надаються одному або декільком вузлам (процесор, памʼять, графічні процесори тощо), і доступні для використання Podʼам, що працюють на цих вузлах.

    У Kubernetes також використовується термін ресурс для опису ресурсу API.

    [+]

    Компʼютери надають фундаментальні апаратні засоби: обчислювальні потужності, памʼять для зберігання даних, мережу тощо. Ці ресурси мають обмежений обсяг, який вимірюється в одиницях, що застосовуються до цього ресурсу (кількість процесорів, байт памʼяті тощо). Kubernetes абстрагує загальні ресурси для розподілу між робочими навантаженнями та використовує примітиви операційної системи (наприклад, Linux cgroups) для керування споживання робочих навантажень.

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

  • Ресурс API
    Або також: Resource

    Сутність у системі типів Kubernetes, що відповідає точці доступу у Kubernetes API. Ресурс зазвичай представляє обʼєкт. Деякі ресурси представляють операцію над іншими обʼєктами, наприклад, перевірку дозволів.

    [+]

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

  • Рецензент
    Або також: Reviewer

    Особа, яка перевіряє код для визначення його якості та коректності в певній частині проєкту.

    [+]

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

  • Робоча група
    Або також: Working Group, WG

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

    [+]

    Робочі групи є способом організації людей для виконання конкретного завдання.

    Для отримання додаткової інформації дивіться репозиторій kubernetes/community та поточний список SIGs та робочих груп.

  • Робоче навантаження
    Або також: Workload

    Робоче навантаження є застосунком, який запущено в Kubernetes.

    [+]

    Різноманітні основні обʼєкти, які представляють різні типи або частини робочого навантаження, включають обʼєкти DaemonSet, Deployment, Job, ReplicaSet та StatefulSet.

    Наприклад, робоче навантаження, що має вебсервер та базу даних має запускати базу даних в одному StatefulSet та вебсервер в Deployment.

  • Розлад
    Або також: Disruption

    Розлади — це події, які призводять до виходу з ладу одного чи кількох Podʼів. Розлад має наслідки для ресурсів робочого навантаження, таких як Deployment, які покладаються уражені Podʼі.

    [+]

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

    Докладніше дивіться в розділі Розлади.

  • Розлад в роботі Podʼа

    Розлад в роботі Podʼа — це процес, за якого Podʼи на вузлах припиняють роботу добровільно, або примусово.

    [+]

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

  • Розробник (розʼяснення)
    Або також: Developer

    Може вказувати на: Розробника застосунків, Учасника, який робіть внесок до коду Kubernetes, або Розробника платформ.

    [+]

    Цей перевантажений термін може мати різні значення залежно від контексту.

  • Розробник застосунків
    Або також: Application Developer

    Особа, яка створює застосунок, який працює в кластері Kubernetes.

    [+]

    Розробник застосунків фокусується на одній частині застосунку. Масштаб їх уваги може значно варіюватися.

  • Розробник платформи
    Або також: Platform Developer

    Особа, яка налаштовує платформу Kubernetes, щоб вона відповідала потребам її власного проєкту.

    [+]

    Розробник платформи може, наприклад, використовувати Власні Ресурси або Розширювати Kubernetes API за допомогою шару агрегації для додавання функціонала до свого екземпляра Kubernetes, зокрема для свого застосунку. Деякі розробники платформи також є учасниками проєкту Kubernetes і створюють розширення, які передаються спільноті Kubernetes. Інші розробляють комерційні розширення з закритим вихідним кодом або специфічні для певного сайту.

  • Розширення
    Або також: Extension

    Розширення — це компоненти програмного забезпечення, які розширюють і глибоко інтегруються з Kubernetes для підтримки нових типів обладнання.

    [+]

    Багато адміністраторів кластерів використовують екземпляри Kubernetes, дистрибутиви встановлені самостійно чи надані постачальниками послуг. Ці кластери вже мають попередньо встановлені розширення. В результаті більшість користувачів Kubernetes можуть не потребувати встановлення розширень, і ще менше користувачів можуть потребувати створення нових.

  • Селектор
    Або також: Selector

    Дозволяє користувачам фільтрувати ресурси за мітками.

    [+]

    Селектори застосовуються при створенні запитів для фільтрації ресурсів за мітками.

  • Сервісний Каталог
    Або також: Service Catalog

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

    [+]

    Це забезпечувало можливість переглядати, створювати та звʼязуватися з зовнішніми Managed Services, не потребуючи докладних знань того, як ці служби будуть створені чи управлятися.

  • Середовища виконання контейнерів
    Або також: Container Runtime

    Основний компонент, який дозволяє Kubernetes ефективно запускати контейнери. Він відповідає за керування виконанням і життєвим циклом контейнерів у середовищі Kubernetes.

    [+]

    Kubernetes підтримує середовища виконання контейнерів, такі як containerd, CRI-O, та будь-яку іншу реалізацію Kubernetes CRI (інтерфейс виконання контейнерів).

  • Сертифікат

    Криптографічно захищений файл, який використовується для підтвердження доступу до кластера Kubernetes.

    [+]

    Сертифікати дозволяють застосункам у межах кластера Kubernetes отримувати захищений доступ до API Kubernetes. Сертифікати перевіряють, чи клієнти мають дозвіл на доступ до API.

  • Спорідненість
    Або також: Affinity, Афінітет

    У Kubernetes Affinity — це набір правил, які дають підказки планувальнику, де розміщувати Podʼи.

    [+]

    Є два види спорідненості:

    Правила визначаються за допомогою міток, та селекторів, вказаних в Podʼах, і вони можуть бути обовʼязковими або бажаними, залежно від того, наскільки суворо ви хочете, щоб планувальник їх дотримувався.

  • Том
    Або також: Volume

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

    [+]

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

    Дивіться сховище для отримання додаткової інформації.

  • Тривалість
    Або також: Duration

    Рядкове значення, що представляє кількість часу.

    [+]

    Формат тривалості (Kubernetes) базується на типі time.Duration з мови програмування Go.

    У Kubernetes API, які використовують тривалість, значення виражається у вигляді ряду додатних цілих чисел у поєднанні з суфіксом одиниці часу. Ви можете мати більше одного значення часу і тривалість є сумою цих часових величин. Допустимими одиницями часу є ns, µs (або us), ms, s, m і h.

    Наприклад: 5s означає тривалість часу у пʼять секунд, а 1m30s означає тривалість часу в одну хвилину і тридцять секунд.

  • Управління кластером

    Робота, повʼязана з управлінням кластером Kubernetes: керування щоденними операціями та координація оновлень.

    [+]

    Приклади робіт з управління кластером включають: розгортання нових вузлів для масштабування кластера; виконання оновлень програмного забезпечення; впровадження заходів забезпечення безпеки; додавання чи видалення сховища; налаштування мережі кластера; управління загальнокластерною спостережуваністю та реагування на події.

  • Учасник
    Або також: Сontributor

    Особа, яка надає код, документацію або свій час для допомоги у проєкті чи спільноті Kubernetes.

    [+]

    Внесками можуть бути запити на втягування змін (PR, pull request), виправлення помилок, відгуки, участь в Special interest groups (SIG), організація заходів спільноти та інше.

  • Учасник, який робіть внесок до коду
    Або також: Code Contributor

    Особа, яка розробляє та вносить внески до відкритого коду Kubernetes.

    [+]

    Вони також є активним членами спільноти, які беруть участь в одній чи кількох групах Special Interest Groups (SIGs).

  • Функціональні можливості
    Або також: Feature gate

    Функціональні можливості містять набір ключів (прихованих значень), які ви можете використовувати для контролю того, які функції Kubernetes увімкнені у вашому кластері.

    [+]

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

  • Хуки життєвого циклу контейнера

    Хуки життєвого циклу надають події в життєвому циклі управління контейнером і дозволяють користувачеві виконувати код при настанні подій.

    [+]

    Для контейнерів доступні два хуки: PostStart, який виконується негайно після створення контейнера, і PreStop, який є блокуючим і викликається негайно перед завершенням роботи контейнера.

  • Член
    Або також: Member

    Постійний активний учасник чи учасниця спільноті Kubernetes.

    [+]

    Учасники можуть мати призначені до них тікети та запити на втягування (pull request) та брати участь у special interest groups (SIGs) (командах GitHub). Для запитів на втягування від учасників автоматично застосовуються тести перед злиттям їх змін. Очікується, що учасник залишатиметься активним учасником у спільноті.

  • Шаблон Operator
    Або також: Operator, Operator pattern

    Шаблон Operator — це системний дизайн, який повʼязує контролер з одним чи кількома власними ресурсами.

    [+]

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

    Якщо запущений застосунок діє як контролер та має доступ до API для виконання завдань відносно власного ресурсу, що визначений в панелі управління, це приклад шаблону Operator.

  • Шар агрегації
    Або також: Aggregation Layer

    Шар агрегації дозволяє встановлювати додаткові API в стилі Kubernetes у вашому кластері.

    [+]

    Коли ви налаштували API сервер Kubernetes для підтримки додаткових API, ви можете додавати обʼєкти APIService які "затребують" URL-адреси в API Kubernetes.

Змінено June 20, 2024 at 12:44 PM PST: Sync changest from andygol/k8s-website (36d05bc8a1)