Глосарій
Даний словник створений як повний стандартизований список термінології Kubernetes. Він включає в себе технічні терміни, специфічні для Kubernetes, а також більш загальні терміни, необхідні для кращого розуміння контексту.
Відфільтрувати терміни за теґами
Натисність на [+] для отримання розширеного пояснення конкретного терміна.
Застосунок, який обслуговує функціонал Kubernetes через RESTful інтерфейс та зберігає стан кластера.
[+]Ресурси Kubernetes та "записи про наміри" зберігаються як обʼєкти API та модифікуються за допомогою RESTful викликів до API. API дозволяє керувати конфігурацією декларативним способом. Користувачі можуть взаємодіяти з API Kubernetes безпосередньо або за допомогою інструментів, таких як
kubectl. Ядро API Kubernetes є гнучким та може бути розширено для підтримки власних ресурсів користувачів.- Або також: kube-apiserver
Сервер API є компонентом панелі управління Kubernetes, який надає доступ до API Kubernetes. Сервер API є фронтендом для панелі управління Kubernetes.
[+]Основна реалізація сервера API Kubernetes — kube-apiserver. kube-apiserver спроєктований для горизонтального масштабування, тобто масштабується за допомогою розгортання додаткових екземплярів. Ви можете запустити кілька екземплярів kube-apiserver та балансувати трафік між ними.
- Або також: Gateway API
Різновид API для створення мережі Service в Kubernetes.
[+]API Шлюзу надає сімейство розширюваних, орієнтованих на ролі та орієнтованих на протоколи різновидів API для моделювання мережі Service в Kubernetes.
- Або також: API Group
Набір повʼязаних шляхів в API Kubernetes.
[+]Ви можете увімкнути або вимкнути кожну API-групу, змінивши конфігурацію свого API-сервера. Ви також можете вимкнути або увімкнути шляхи до конкретних ресурсів. API-група полегшує розширення API Kubernetes. API-група вказується в REST-шляху та в полі
apiVersionсеріалізованого обʼєкта.- Дивіться API-група для отримання додаткової інформації.
- Або також: Container Advisor
cAdvisor (Container Advisor) надає користувачам контейнерів розуміння використання ресурсів і характеристик продуктивності роботи контейнерів.
[+]Це працююча фонова служба (демон), що збирає, агрегує, обробляє та експортує інформацію про запущені контейнери. Зокрема, для кожного контейнера зберігаються параметри ізоляції ресурсів, історичне використання ресурсів, гістограми повного історичного використання ресурсів і мережева статистика. Ці дані експортуються в контейнер і на всю машину.
Група процесів в середовищі Linux із можливістю ізоляції, обліку та встановлення обмежень ресурсів.
[+]cgroup є функцією ядра Linux, яка обмежує, обліковує та ізолює використання ресурсів (центральний процесор, памʼять, введення/виведення даних на диск, мережа) для колекції процесів.
CIDR (Classless Inter-Domain Routing) — це нотація для опису блоків IP-адрес широко використовується в налаштуваннях конфігурації мережі.
[+]Компонент панелі управління Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.
[+]Відокремлюючи логіку сумісності між Kubernetes і базовою хмарною інфраструктурою, компонент cloud-controller-manager дає змогу хмарним провайдерам випускати функції з іншою швидкістю порівняно з основним проєктом Kubernetes.
- Або також: CNCF
Cloud Native Computing Foundation (CNCF) створює стійку екосистему та сприяє розвитку спільноти навколо проєктів, які оркеструють контейнери як частину архітектури мікросервісів.
Kubernetes є проєктом CNCF.
[+]Фундація CNCF є частиною Linux Foundation. Її місія — зробити хмарні обчислення повсюдними.
Обʼєкт API, призначений для зберігання неконфіденційних даних у вигляді пар ключ-значення. Podʼи можуть використовувати ConfigMap як змінні середовища, аргументи командного рядка чи файли конфігурації у томі.
[+]ConfigMap дозволяє відділити конфігурацію, специфічну для середовища, від образів контейнерів, щоб ваші застосунки були легко переносимими.
Середовище виконання контейнера з акцентом на простоту, надійність та переносимість.
[+]containerd — це середовище виконання контейнера, яке працює як служба Linux або Windows. containerd відповідає за отримання та зберігання образів контейнерів, виконання контейнерів, забезпечення мережевого доступу та інше.
Інструмент, який дозволяє використовувати середовище виконання контейнерів OCI з Kubernetes CRI.
[+]CRI-O — це реалізація Інтерфейс середовища виконання контейнера (CRI), яка дозволяє використовувати середовище виконання контейнерів, сумісне зі специфікацією Open Container Initiative (OCI) runtime spec.
Використання CRI-O дозволяє Kubernetes використовувати будь-яке середовище виконання контейнерів, сумісне з OCI, як середовище виконання контейнерів для запуску Podʼів, а також завантажувати OCI образи контейнерів з віддалених реєстрів.
Власний код, який визначає ресурс для додавання до сервера API вашого кластера Kubernetes без створення власного сервера.
[+]Визначення власного ресурсу (Custom Resource Definitions) дозволяють розширювати API Kubernetes для вашого середовища, якщо публічно підтримувані ресурси API не можуть задовольнити ваші потреби.
- Шар, який надає контейнерам ресурси, такі як ЦПУ, памʼять, мережа і сховище даних для того, щоб контейнери могли працювати та підʼєднуватись до мережі. [+]
Шар, який надає контейнерам ресурси, такі як ЦПУ, памʼять, мережа і сховище даних для того, щоб контейнери могли працювати та підʼєднуватись до мережі.
Обʼєкт API, який керує реплікованим застосунком, зазвичай, запускаючи Podʼи без збереження стану.
[+]Кожна репліка представлена Podʼом; Podʼи розподіляються серед вузлів кластера. Для робочих навантажень, які дійсно вимагають збереження стану, розгляньте використання StatefulSet.
Docker (зокрема, Docker Engine) — це програмна технологія, яка забезпечує віртуалізацію на рівні операційної системи, також відому як контейнери.
[+]Docker використовує функції ізоляції ресурсів ядра Linux, такі як cgroups та простори імен ядра, а також файлову систему, здатну до обʼєднання, таку як OverlayFS та інші, щоб дозволити незалежним контейнерам працювати в одному екземплярі Linux, уникаючи накладних витрат на запуск та підтримку віртуальних машин (ВМ).
Dockershim є компонентом Kubernetes версії 1.23 та раніше. Він дозволяє kubelet взаємодіяти з Docker Engine.
[+]Починаючи з версії 1.24, dockershim був вилучений з Kubernetes. Докладніше дивіться в Dockershim FAQ.
Може вказувати на: код в екосистемі Kubernetes, який залежить від основної кодової бази Kubernetes або відгалуженого репозиторію.
[+]- У Спільноті Kubernetes: в розмові часто використовують термін downstream, щоб вказати на екосистему, код або інструменти сторонніх розробників, які залежать від основної кодової бази Kubernetes. Наприклад, нову функцію в Kubernetes можуть використовувати застосунки downstream для поліпшення їхньої функціональності.
- У GitHub чи git: зазвичай відгалужений репозиторій називається downstream, тоді як висхідний репозиторій, репозиторій від якого було здійснено відгалуження, вважається upstream.
Механізм Kubernetes для надання значень полів Podʼа та контейнера коду, що працює в контейнері
[+]Іноді контейнеру корисно мати інформацію про себе, без необхідності вносити зміни до коду контейнера, який безпосередньо зʼєднує його з Kubernetes.
Механізм downward API Kubernetes дозволяє контейнерам використовувати інформацію про себе або їхній контекст в кластері Kubernetes. Застосунки в контейнерах можуть мати доступ до цієї інформації, без потреби для них діяти як клієнт Kubernetes API.
Є два способи надання доступу до полів Podʼа та контейнера для робочого контейнера:
- використання змінних оточення
- використання томів
downwardAPI
Разом ці два способи надання доступу до полів Podʼів та контейнера називаються downward API.
- Або також: Точки доступу
Endpoints відстежують IP-адреси Podʼів з відповідними селекторами Serviceʼу.
[+]Endpoints можуть бути налаштовані вручну для Serviceʼів, які не мають визначених селекторів. Ресурс EndpointSlice надає масштабовану та розширювану альтернативу Endpoints.
Спосіб групування мережевих точок доступу разом із ресурсами Kubernetes.
[+]Масштабований та розширюваний спосіб групування мережевих точок доступу. Ці дані можуть використовуватися kube-proxy для встановлення мережевих маршрутів на кожному вузлі.
Сумісне та високодоступне сховище ключ-значення, яке використовується як сховище Kubernetes для резервування всіх даних кластера.
[+]Якщо ваш кластер Kubernetes використовує etcd як сховище для резервування, переконайтеся, що у вас є план резервного копіювання даних.
Ви можете знайти докладну інформацію про etcd в офіційній документації.
FlexVolume — інтерфейс, зараз визнаний застарілим, для створення втулків зовнішніх томів. Container Storage Interface — це новіший інтерфейс, який вирішує кілька проблем з FlexVolume.
[+]FlexVolumes дозволяють користувачам писати свої власні драйвери та додавати підтримку своїх томів в Kubernetes. Бінарні файли та залежності драйверів FlexVolume повинні бути встановлені на машинах-хостах. Це вимагає прав адміністратора. Група Storage SIG рекомендує використовувати CSI драйвер, якщо це можливо, оскільки він вирішує обмеження, повʼязані з FlexVolumes.
Набір попередньо налаштованих ресурсів Kubernetes, якими можна керувати за допомогою Helm.
[+]Чарти надають відтворюваний спосіб створення та обміну застосунками Kubernetes. Один чарт може бути використаний для розгортання чогось простого, наприклад, контейнера Memcached, або щось складного, наприклад, повного стека вебзастосунків з серверами HTTP, базами даних, кешем та іншими складовими.
HostAliases — це зіставлення між IP-адресою та імʼям хосту, яке додається у файл hosts Podʼа.
[+]HostAliases — це опціональний список імен хостів та IP-адрес, які будуть вставлені в файл hosts Podʼа, якщо вказано. Це є дійсним лише для Podʼів non-hostNetwork.
- Або також: Вхід
Обʼєкт API, який управляє зовнішнім доступом до служб в кластері, зазвичай HTTP.
[+]Ingress може надавати балансування навантаження, розшифровування SSL-трафіку та віртуальний хостинг на основі імен.
Відкрита платформа (призначення не тільки для Kubernetes), яка забезпечує уніфікований спосіб інтеграції мікросервісів, управління потоком трафіку, виконання політик та агрегацію телеметричних даних.
[+]Додавання Istio не вимагає зміни коду застосунку. Istio є шаром інфраструктури між Service та мережею, який, спільно з розгортанням служб, часто називається сервісною сіткою (service mesh). Панель управління Istio абстрагується від базової платформи управління кластером, якою може бути Kubernetes, Mesosphere і т.д.
Засіб представлення вимог для передачі між двома сторонами.
[+]JWT може бути підписаний та зашифрований цифровим підписом. Kubernetes використовує JWT як токени автентифікації для перевірки сутностей, які хочуть виконувати дії в кластері.
[+]kOpsне тільки допомагає створювати, оновлювати та підтримувати кластери Kubernetes промислового рівня з високою доступністю, але й надає необхідну хмарну інфраструктуру.Примітка:
На цей час офіційно підтримуються AWS (Amazon Web Services), DigitalOcean, GCE та OpenStack з підтримкою бета-версій, Azure — альфа-версій.kOps— це автоматизована система управління:- Повністю автоматизована установка
- Використовує DNS для ідентифікації кластерів
- Самовідновлення: все працює в групах автоматичного масштабування
- Підтримка різних операційних систем (Amazon Linux, Debian, Flatcar, RHEL, Rocky та Ubuntu)
- Підтримка високої доступності
- Може безпосередньо надавати інфраструктуру або генерувати маніфести terraform
Компонент панелі управління, який запускає процеси контролера.
[+]За логікою, кожен контролер є окремим процесом. Однак для спрощення їх збирають в один бінарний файл і запускають як єдиний процес.
kube-proxy є мережевим проксі, що запущений на кожному вузлі кластера і реалізує частину концепції Kubernetes Service.
[+]kube-proxy забезпечує підтримання мережевих правил на вузлах. Ці правила обумовлюють підключення мережею до ваших Podʼів всередині чи поза межами кластера.
kube-proxy використовує шар фільтрації пакетів операційної системи, за його наявності. В іншому випадку kube-proxy скеровує трафік самостійно.
Компонент панелі управління, що відстежує створені Podʼи, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть.
[+]При виборі вузла враховуються наступні фактори: індивідуальна і колективна потреба у ресурсах, обмеження за апаратним/програмним забезпеченням і політиками, характеристики affinity та anti-affinity, локальність даних, сумісність робочих навантажень і граничні терміни виконання.
Інструмент для швидкого встановлення Kubernetes та налаштування захищеного кластера.
[+]Ви можете використовувати kubeadm для встановлення як панелі управління, так і компонентів робочих вузлів.
- Або також: kubectl
Інструмент командного рядка для взаємодії із кластером Kubernetes, панеллю управління, використовуючи API Kubernetes.
[+]Ви можете використовувати
kubectlдля створення, перегляду, оновлення та видалення обʼєктів Kubernetes.Англійською,
kubectl(офіційно) вимовляється як /kjuːb/ /kənˈtɹəʊl/ (типу "cube control"). Агент, запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів в Podʼах.
[+]kubelet використовує специфікації PodSpecs, які надаються за допомогою різних механізмів, і забезпечує працездатність і справність усіх контейнерів, що описані у PodSpecs. kubelet керує лише тими контейнерами, що були створені Kubernetes.
Впроваджує ліміти для обмеження обсягу споживання ресурсів для кожного контейнера чи Podʼа в просторі імен.
[+]LimitRange обмежує кількість обʼєктів, які можна створити за типом, а також обсяг обчислювальних ресурсів, які можуть бути затребувані/спожиті окремими контейнерами чи Podʼами в просторі імен.
Програмне забезпечення, що підтримується стороннім постачальником.
[+]Деякі приклади Managed Services: AWS EC2, Azure SQL Database та GCP Pub/Sub, але це може бути будь-яке програмне забезпечення, що може бути використане застосунком.
Застарілий термін, використовується як синонім для вузлів, на яких розміщено панель управління.
[+]Цей термін все ще використовується деякими інструментами для надання послуг, такими як kubeadm, та сервісами, що надаються постачальниками послуг, для позначення мітками вузлів за допомогою
kubernetes.io/roleта контролю розташування панелі управління Podʼів.Інструмент для локального запуску Kubernetes.
[+]Minikube запускає кластер з одного вузла всередині віртуальної машини на вашому компʼютері. Ви можете використовувати Minikube для того, щоб ознайомитись з Kubernetes у навчальному середовищі.
- Або також: MVP
Функціонал, який дозволяє kube-apiserver перенаправити запит на ресурс до іншого API-сервера.
[+]Коли в кластері працюють різні версії Kubernetes на різних API-серверах, ця функція дозволяє правильно обслуговувати запити до ресурсів за допомогою відповідного API-сервера.
MVP стандартно вимкнено і може бути активовано, увімкненням функціонала
UnknownVersionInteroperabilityProxyпри запуску API-сервера. Наданий клієнтом рядок, який посилається на обʼєкт в URL ресурсу, наприклад
[+]/api/v1/pods/some-name.Тільки один обʼєкт вказаного виду (kind) може мати вказану назву одночасно. Проте, якщо ви видаляєте обʼєкт, ви можете створити новий обʼєкт з такою ж назвою.
- Або також: Простір імен
Абстракція, що використовується в Kubernetes для ізоляції груп ресурсів в межах одного кластера.
[+]Простори імен використовуються для організації обʼєктів в кластері та надають можливість поділу ресурсів кластера. Імена ресурсів повинні бути унікальними в межах простору імен, але не між просторами імен. Простори імен застосовуються лише до обʼєктів, які належать до простору імен (наприклад, Deployments, Services і т.д.), і не застосовуються до обʼєктів, які є загальними для кластера (наприклад, StorageClass, Nodes, PersistentVolumes, і т.д.).
- Або також: Мережева політика
Специфікація того, як дозволяється взаємодія групам Podʼів між собою та з іншими мережевими точками доступу.
[+]Мережеві політики дозволяють вам декларативно налаштовувати, які Podʼи мають право підключатися один до одного, які простори імен мають право взаємодіяти та більш конкретно, до яких портів слід застосовувати кожну політику. Ресурси
NetworkPolicyвикористовують мітки для вибору Podʼів та визначення правил, які вказують, який трафік дозволяється обраним Podʼам. Мережеві політики реалізовані за допомогою підтримуваного втулка мережі, який надає постачальник мережі. Зверніть увагу, що створення мережевого ресурсу без контролера для його виконання не матиме ефекту. Обʼєкт API, який являє собою частину системи зберігання в кластері. Доступний як загальний, підʼєднуваний ресурс, який існує поза життєвим циклом будь-якого окремого Podʼа.
[+]PersistentVolumes (PVs) надають API, який абстрагує деталі того, як забезпечується зберігання від того, як воно використовується. PVs використовуються безпосередньо в сценаріях, де сховище може бути створено заздалегідь (статичне розподілення). Для сценаріїв, які вимагають сховища на вимогу (динамічне розподілення), замість цього використовуються PersistentVolumeClaims (PVCs).
Запит на використання ресурсів зберігання, визначених у PersistentVolume, для їх монтування як томів в контейнері.
[+]Визначає обсяг сховища, спосіб доступу до сховища (тільки для читання, для читання та запису та/або виключний доступ) та спосіб його вилучення (збережений, перероблений або видалений). Деталі щодо самого сховища описані в обʼєкті PersistentVolume.
Найменший та найпростіший обʼєкт Kubernetes. Pod являє собою групу контейнерів, що запущені у вашому кластері.
[+]Pod зазвичай налаштовується для запуску одного основного контейнера. Він також може запускати додаткові sidecar контейнери, які додають додаткові функції, наприклад логування. Podʼами зазвичай керує Deployment.
- Або також: pod template
Обʼєкт API, який визначає шаблон для створення Podʼів. PodTemplate API також вбудований у визначення API для управління робочими навантаженнями, такими як Deployment або StatefulSets.
[+]Шаблони Podʼів дозволяють визначати загальні метадані (такі як мітки або шаблон для імені нового Podʼа), а також вказувати бажаний стан podʼа. Контролери управління робочим навантаженням використовують шаблони Podʼів (вбудовані в інший обʼєкт, такий як Deployment або StatefulSet) для визначення та управління одним або кількома Podʼами. Коли може бути кілька Podʼів на основі одного і того ж шаблону, вони називаються репліками. Хоча ви можете створити обʼєкт PodTemplate безпосередньо, вам рідко потрібно це робити.
PriorityClass — це іменований клас для пріоритету планування, який слід призначити Podʼу у цьому класі.
[+]PriorityClass — це обʼєкт, який не належить до жодного простору імен, який зіставляє назву з цілочисельним пріоритетом, що використовується для Podʼа. Назва вказується в полі
metadata.name, а значення пріоритету — у поліvalue. Пріоритети коливаються від -2147483648 до 1000000000 включно. Вищі значення вказують на вищий пріоритет.Копія або дублікат Podʼа або набору обʼєктів Pod. Репліки забезпечують високу доступність, масштабованість і стійкість до відмов шляхом утримання кількох ідентичних екземплярів обʼєкта Pod.
[+]У Kubernetes репліки широко використовуються для досягнення бажаного стану застосунку та надійності роботи. Вони дозволяють масштабування робочого навантаження та його розподіл по різних вузлах кластера.
Визначаючи кількість реплік в обʼєкті Deployment або ReplicaSet, Kubernetes переконується, що вказана кількість екземплярів працює, автоматично коригуючи кількість за необхідності.
Управління репліками дозволяє ефективно балансувати навантаження, виконувати поетапні оновлення та забезпечує можливості самовідновлення в кластері Kubernetes.
Обʼєкт ReplicaSet (має на меті) підтримувати набір реплік обʼєктів Pod, які завжди працюють в будь-який момент часу.
[+]Обʼєкти робочого навантаження, такі як Deployment, використовують ReplicaSet для забезпечення того, що налаштована кількість Podʼів працювала у вашому кластері на основі конфігурації цього ReplicaSet.
Ресурс робочого навантаження, який керує реплікованим застосунком, забезпечуючи наявність певної кількості екземплярів обʼекта Pod.
[+]Панель управління забезпечує, що визначена кількість екземплярів Pod працює, навіть якщо деякі Podʼи зазнають збою, якщо ви видаляєте Pod вручну або якщо помилково їх запускається забагато.
Примітка:
ReplicationController є застарілим. Див. Deployment, який є подібним.- Або також: Секрет
Зберігає конфіденційну інформацію, таку як паролі, токени OAuth та ключі SSH.
[+]Секрети дають вам більше контролю над тим, як використовується конфіденційна інформація і зменшують ризик випадкового її розголошення. Значення Secret кодуються як рядки base64 і зазвичай зберігаються в незашифрованому вигляді, але можуть бути налаштовані для шифрування в стані покою.
Pod може посилатися на Secret різними способами, такими як монтування тому, чи як змінна середовища. Secretʼи призначені для конфіденційних даних, а ConfigMaps призначені для неконфіденційних даних.
Метод надання доступу ззовні до мережевого застосунку, який працює як один чи кілька Podʼів у вашому кластері.
[+]Набір Podʼів, з якими працює Service, (зазвичай) визначається селектором. Якщо додаються чи видаляються деякі Podʼи, набір Podʼів, що відповідає селектору, буде змінено. Service переконується, що мережевий трафік може бути направлений на поточний набір Podʼів з робочим навантаженням.
Serviceʼи Kubernetes можуть використовувати IP-мережу (IPv4, IPv6 або обидві) або посилатися на зовнішнє імʼя в Domain Name System (DNS).
Абстракція Service дозволяє використовувати інші механізми, такі як Ingress та Gateway.
- Або також: Службовий обліковий запис
Забезпечує ідентифікацію для процесів, які працюють в Podʼі.
[+]Коли процеси всередині Podʼів отримують доступ до кластера, їх автентифікує сервер API як певний службовий обліковий запис, наприклад,
default. При створенні Podʼа, якщо ви не вказали службовий обліковий запис, йому автоматично буде призначений типовий службовий обліковий запис у тому ж Namespace. Техніка розподілу запитів до черг, яка забезпечує кращу ізоляцію, ніж хешування за модулем кількості черг.
[+]Ми часто переймаємось ізоляцією різних потоків запитів один від одного, щоб інтенсивний потік не витісняв менш інтенсивні потоки. Простий спосіб розміщення запитів у черзі — хешування деяких характеристик запиту за модулем кількості черг, щоб отримати індекс черги для використання. Хеш-функція використовує вхідні характеристики запиту, які відповідають потокам. Наприклад, в Інтернеті це часто кортеж з 5 елементів: адреси джерела та призначення, протоколу та порту джерела та призначення.
Ця проста схема, заснована на хешуванні, має властивість того, що будь-який інтенсивний потік витісняє всі менш інтенсивні потоки, які хешуються в ту ж чергу. Для забезпечення хорошої ізоляції для великої кількості потоків потрібна велика кількість черг, що є проблематичним. Shuffle-sharding — це легша техніка, яка може краще ізолювати менш інтенсивні потоки від більш інтенсивних. Термінологія shuffle-sharding використовує метафору роздачі карт з колоди; кожна черга — це метафорична карта. Техніка shuffle-sharding починається з хешування характеристик, які ідентифікують потік запитів, для створення хеш-значення з десятками або більше бітів. Потім значення хешу використовується як джерело ентропії для перемішування колоди та роздачі карт на руки (черг). Оглядаються всі роздані черги, і запит поміщається в одну з оглянутих черг з найкоротшою довжиною. З помірним розміром руки не треба оглядати всі роздані карти, і у менш інтенсивного потоку є хороші шанси уникнути впливів більш інтенсивного потоку. З великим розміром руки дорого оглядати роздані черги та складніше для менш інтенсивних потоків уникнути колективних ефектів набору більш інтенсивних потоків. Таким чином, розмір руки повинен бути розумно обраний.
Один чи кілька контейнерів, які зазвичай стартують до запуску будь-яких контейнерів застосунків.
[+]Sidecar контейнери схожі на звичайні контейнери застосунків, але вони мають інше призначення: sidecar контейнер надає локальні послуги для Podʼа основному контейнеру застосунку. На відміну від контейнерів ініціалізації, sidecar контейнери продовжують виконуватися після запуску Podʼа.
Докладніше дивіться Sidecar контейнери.
Члени спільноти, які спільно керують тривалим процесом або аспектом великого відкритого проєкту Kubernetes.
[+]Члени в межах SIG мають спільний інтерес у розвитку певної області, такої як архітектура, машинерія API або документація. SIG повинні дотримуватися настанов з управління, але вони можуть мати свої власні правила участі та канали комунікації.
Для отримання додаткової інформації див. репозиторій kubernetes/community та поточний список SIG та робочих груп.
- Або також: Специфікація
Визначає, як слід налаштовувати кожен обʼєкт, такий як Pod або Service, та його бажаний стан.
[+]Практично кожен обʼєкт Kubernetes має два вкладені поля обʼєкта, які визначають конфігурацію обʼєкта: spec та status. Для обʼєктів, які мають специфікацію (spec), ви повинні встановити її при створенні обʼєкта, надаючи опис характеристик, які ви хочете, щоб ресурс мав — його бажаний стан.
Специфікація різниться для різних обʼєктів, таких як Podʼи, StatefulSets та Services, надаючи налаштування, такі як контейнери, томи, репліки, порти та інші унікальні для кожного типу обʼєкта специфікації. Це поле вказує те, який стан Kubernetes повинен утримувати для визначеного обʼєкта.
StatefulSet керує розгортанням і масштабуванням групи Podʼів, і забезпечує гарантії щодо порядку та унікальності цих Podʼів.
[+]Схожий на Deployment, StatefulSet керує Podʼами, які базуються на ідентичній специфікації контейнерів. На відміну від Deployment, StatefulSet зберігає постійну ідентичність для кожного свого Podʼа. Ці Podʼи створюються за однаковою специфікацією, але не є взаємозамінними: у кожного є постійний ідентифікатор, який він утримує при переплануванні.
Якщо ви хочете використовувати томи для забезпечення постійності для вашого завдання, ви можете використовувати StatefulSet як частину рішення. Навіть якщо окремі Podʼи в StatefulSet можуть вийти з ладу, постійні ідентифікатори Podʼів полегшують відповідність наявних томів новим Podʼам, які замінюють ті, що вийшли з ладу.
Pod, яким управляє безпосередньо демон kubelet на певному вузлі,
[+]без його спостереження через сервер API.
Static Pod не підтримують ефемерні контейнери.
- Або також: Клас сховища
StorageClass надає можливість адміністраторам описати різні доступні типи сховищ.
[+]Класи сховища можуть відповідати рівням обслуговування, політиці резервного копіювання або довільними правилами, визначеними адміністраторами кластера. Кожен клас сховища містить поля
provisioner,parametersтаreclaimPolicy, які використовуються, коли динамічно резервується Persistent Volume, що належить класу. Користувачі можуть запитувати певний клас, використовуючи імʼя обʼєкта класу сховища.
[+]sysctl— це напівстандартизований інтерфейс для читання або зміни атрибутів ядра Unix.На подібних до Unix системах
sysctl— це назва інструмента, яким користуються адміністратори для перегляду та зміни цих параметрів, а також системних викликів, які використовують цей інструмент.Контейнер та мережеві втулки можуть покладатися на значення
sysctlвстановлені певним чином.Основний обʼєкт, що складається з трьох обовʼязкових властивостей: key, value, та effect. Taints (додаткові властивості) запобігають розміщенню Podʼів на вузлах чи групах вузлів.
[+]Taints та tolerations співпрацюють, щоб забезпечити те, що Podʼи не розміщуються на непридатних вузлах. Один чи декілька taint застосовуються до вузла. Вузол повинен розміщувати лише Podʼи з tolerations, що збігаються з налаштованими taints.
Рядок, створений системами Kubernetes для унікальної ідентифікації обʼєктів.
[+]Кожен обʼєкт, створений протягом усього життя кластера Kubernetes, має відмінний UID. Він призначений для відмінності між історичними випадками схожих сутностей.
Може вказувати на: основний код Kubernetes або вихідний репозитарій, з якого було зроблено форк репозиторію.
[+]- В Спільноті Kubernetes: В розмовах термін upstream часто використовується для позначення основного коду Kubernetes, на якому ґрунтуються загальна екосистема, інший код або інструменти сторонніх розробників. Наприклад, члени спільноти можуть пропонувати перемістити функцію в upstream, щоб вона була в основному коді, а не у втулку чи інструменті стороннього розробника. * В GitHub або git: Зазвичай вихідний репозитарій називається upstream, тоді як репозитарій, який був зроблений як форк, вважається downstream.
Функція ядра Linux для емуляції привілеїв суперкористувача. Використовується для "контейнерів без прав root".
[+]Простори імен користувача — це особливість ядра Linux, яка дозволяє користувачеві без прав root емулювати привілеї суперкористувача ("root"), наприклад, для запуску контейнерів без прав root поза контейнером.
Простір імен користувача ефективно застосовується для помʼякшення наслідків можливих атак на прорив з контейнера.
У контексті просторів імен користувача термін "простір імен" вказує на особливість ядра Linux, а не на простір імен у розумінні Kubernetes.
Втулок томів дозволяє інтеграцію сховища усередині Podʼа.
[+]Втулок томів дозволяє підʼєднувати та монтувати томи сховища для використання у Podʼі. Втулки томів можуть бути вбудовані або зовнішні. Вбудовані втулки є частиною репозиторію коду Kubernetes і слідують за його циклом випуску. Зовнішні втулки розробляються незалежно.
- Або також: Спостереження
Дієслово, яке використовується для відстеження змін обʼєкта в 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-initiated eviction
Виселення, ініційоване API — процес, під час якого використовується Eviction API для створення обʼєкта
[+]Eviction, який викликає належне завершення роботи Podʼа.Ви можете зробити запит на виселення, якщо ви напряму звертаєтесь до Eviction API з використанням клієнта kube-apiserver, такого як команда
kubectl drain. Коли створюється обʼєктEviction, сервер API завершує роботу Podʼа.Виселення, ініційоване API дотримуються параметрів
PodDisruptionBudgetsтаterminationGracePeriodSeconds.Виселення, ініційоване API не є тим самим, що й виселення через тиск на вузол.
- Дивіться Виселення, ініційоване API для отримання додаткової інформації.
Втулки пристроїв працюють на вузлах кластера (Nodes) та забезпечують Podʼам доступ до ресурсів, таких як локальне обладнання, яке вимагає вендор-специфічної ініціалізації чи налаштувань.
[+]Втулки пристроїв оголошують ресурси для kubelet, щоб робочі Podʼи мали доступ до апаратних можливостей, повʼязаних з вузлом, на якому запущений цей Pod. Ви можете розгортати втулок пристрою як DaemonSet, або встановлювати програмне забезпечення втулка пристрою безпосередньо на кожний відповідний вузол.
Докладніше дивіться в розділі Втулки пристроїв.
- Або також: Node
Вузол — це робоча машина в Kubernetes.
[+]Робочий вузол може бути віртуальною машиною або фізичною машиною, залежно від кластера. На ньому працюють локальні служби або служби, необхідні для виконання Podʼів, і ним керує панель управління. Демони на вузлі включають kubelet, kube-proxy та середовище виконання контейнерів, яке реалізує CRI, наприклад Docker.
В ранніх версіях Kubernetes вузли називалися "Minions" (Міньйони).
- Або також: 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.
- Або також: 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 Lifecycle
Послідовність станів, через які проходить Pod протягом свого існування.
[+]Життєвий цикл Podа визначається станами або фазами Podʼа. Існує пʼять можливих фаз Podʼа: Pending, Running, Succeeded, Failed та Unknown. Високорівневий опис стану Podʼа знаходиться в полі
phasePodStatus. - Або також: 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ʼі.
[+]Змінні середовища контейнера надають інформацію, необхідну для роботи контейнеризованих застосунків, разом із важливою інформацією про ресурси для контейнерів. Наприклад, деталі файлової системи, інформація про сам контейнер та інші ресурси кластера, такі як точки доступу сервісів.
- Або також: Container Storage Interface, CSI
Інтерфейс зберігання контейнерів (CSI) визначає стандартний інтерфейс для взаємодії з системами зберігання з контейнерами.
[+]CSI дозволяє вендорам створювати спеціальні втулки зберігання для Kubernetes, не включаючи їх до репозиторію Kubernetes (зовнішні втулки). Щоб використовувати драйвер CSI від постачальника зберігання, спочатку потрібно розгорнути його у вашому кластері. Після цього ви зможете створити клас зберігання (Storage Class), який використовує цей драйвер CSI.
Основний протокол для взаємодії між kubelet та середовищем виконання контейнерів.
[+]Інтерфейс виконання контейнерів Kubernetes (CRI) визначає основний gRPC протокол для звʼязку між компонентами вузла kubelet та середовищем виконання контейнерів.
Шар інфраструктури, що надає та забезпечує віртуальні машини, мережі, групи безпеки та інші елементи.
[+]- Або також: 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 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 і можуть бути "перевіряючими", "мутаційними" або обома. Будь-який контролер допуску може відхилити запит. Мутаційні контролери можуть модифікувати обʼєкти, які вони пропускають; перевіряючі контролери цього робити не можуть.
- Або також: Container Network Interface, CNI
Втулки мережевого інтерфейсу контейнера (CNI) є типом мережевих втулків, які відповідають специфікації appc/CNI.
[+]- Для отримання інформації про Kubernetes та CNI дивіться Мережеві втулки.
- Або також: Add-ons
Ресурси, які розширюють функціональність Kubernetes.
[+]Інструкції щодо встановлення надбудов надають більше інформації щодо використання надбудов у вашому кластері та перераховують деякі популярні надбудови.
- Або також: Immutable Infrastructure
Незмінна інфраструктура — це компʼютерна інфраструктура (віртуальні машини, контейнери, мережеві пристрої), яка не може бути змінена після розгортання.
[+]Незмінність може бути забезпечена автоматизованим процесом, який переписує несанкціоновані зміни або через систему, яка в першу чергу не дозволяє змін. Контейнери є хорошим прикладом незмінної інфраструктури, оскільки постійні зміни в контейнерах можуть бути внесені лише шляхом створення нової версії контейнера або перестворення поточного контейнера з його образу.
Запобігаючи або виявляючи несанкціоновані зміни, незмінні інфраструктури спрощують ідентифікацію та помʼякшення ризиків безпеки. Управління такою системою стає набагато очевиднішим, оскільки адміністратори можуть робити припущення що до неї. Вони знають, що ніхто не припустився помилки або змін, про які вони забули сповістити. Незмінна інфраструктура йде рука об руку з інфраструктурою як кодом, де вся автоматизація, необхідна для створення інфраструктури, зберігається у системі контролю версій (такій як Git). Ця комбінація незмінності та контролю версій означає, що є надійний лог аудиту кожної санкціонованої зміни в системі.
Сутність у системі Kubernetes. Керуючись цими сутностями, API Kubernetes представляє стан вашого кластера.
[+]Обʼєкт Kubernetes зазвичай є "записом наміру" — коли ви створюєте обʼєкт, панель управління Kubernetes постійно працює над тим, щоб забезпечити існування представленого ним елемента. Створюючи обʼєкт, ви повідомляєте системі Kubernetes, як ви хочете, щоб ця частина робочого навантаження вашого кластера виглядала; це бажаний стан вашого кластера.
- Або також: PDB, Pod Disruption Budget
Обмеження переривання роботи Podʼів дозволяє власникам застосунків створювати обʼєкт для реплікованого застосунку, який гарантує, що певна кількість або відсоток Podʼів з визначеною міткою не буде добровільно виселена в будь-який момент часу.
[+]PDB не можуть запобігти невільним розладам; однак вони зараховуються до бюджету.
- Або також: Image
Збережений екземпляр контейнера, що містить набір програмного забезпечення, необхідного для запуску застосунку.
[+]Спосіб упаковування програмного забезпечення, який дозволяє йому бути збереженим у реєстрі контейнерів, перенесеним на локальну систему та запущеним як застосунок. Образ містить метадані, які можуть вказувати, який виконавчий файл запускати, хто його зібрав та іншу інформацію.
Особа, яка налаштовує, керує та стежить за роботою кластера.
[+]Їхня основна відповідальність — забезпечення стабільної роботи кластера, що може охоплювати періодичні роботи з обслуговування чи оновлення.
Примітка:
Оператори кластера та шаблон "Оператор" це різні речі. Шаблон "Оператор" розширює Kubernetes API.- Або також: Control Plane, master
Шар оркестрування контейнерів, який надає API та інтерфейси для виявлення, розгортання та управління життєвим циклом контейнерів.
[+]Цей шар складається з багатьох різних компонентів, таких як (але не обмежуючись):
Ці компоненти можуть працювати як традиційні служби операційної системи (демони) або як контейнери. Хости, на яких працюють ці компоненти, історично називалися master.
- Або також: Event
Подія – це обʼєкт Kubernetes, який описує зміну стану або помітні події в системі.
[+]Події мають обмежений час зберігання, а причини та повідомлення можуть змінюватися з часом. Споживачі подій не повинні покладатися на терміни події із зазначеною причиною, що відображає стан основної причини, або продовження існування подій з цієї причини.
Події слід розглядати як інформаційні дані, що надаються як найкраще, та які є додатковими даними.
У Kubernetes аудит генерує інший вид Подій (API-група
audit.k8s.io). - Або також: 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ʼами — це важлива функція для навантажень операційних кластерів.
- Або також: Probe
Періодична перевірка, яку kubelet виконує для контейнера, що працює в Podʼі. Ця перевірка визначає стан та справність контейнера, і інформує про життєвий цикл контейнера.
[+]Для отримання додаткової інформації читайте проби контейнера.
- Або також: Proxy
У компʼютерних науках проксі — це сервер, який діє як посередник для віддалених служб.
[+]Клієнт взаємодіє з проксі; проксі копіює дані клієнта на реальний сервер; реальний сервер відповідає проксі; проксі надсилає відповідь реального сервера клієнту.
kube-proxy — це мережевий проксі, який працює на кожному вузлі вашого кластера, реалізуючи частину концепції Service в Kubernetes.
Ви можете запускати kube-proxy як звичайний сервіс проксі на рівні користувача. Якщо ваша операційна система це підтримує, ви можете запускати kube-proxy в гібридному режимі, який досягає того самого результату, використовуючи менше системних ресурсів.
- Або також: 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ʼи на вузлах припиняють роботу добровільно, або примусово.
[+]Добровільні розлади запускаються навмисно власниками застосунків або адміністраторами кластера. Примусові розлади є ненавмисними та можуть бути спричинені невідворотними проблемами, такими як вичерпання ресурсів вузлів, або випадковими видаленнями.
- Або також: Developer
Може вказувати на: Розробника застосунків, Учасника, який робіть внесок до коду Kubernetes, або Розробника платформ.
[+]Цей перевантажений термін може мати різні значення залежно від контексту.
- Або також: Application Developer
Особа, яка створює застосунок, який працює в кластері Kubernetes.
[+]Розробник застосунків фокусується на одній частині застосунку. Масштаб їх уваги може значно варіюватися.
- Або також: Platform Developer
Особа, яка налаштовує платформу Kubernetes, щоб вона відповідала потребам її власного проєкту.
[+]Розробник платформи може, наприклад, використовувати Власні Ресурси або Розширювати Kubernetes API за допомогою шару агрегації для додавання функціонала до свого екземпляра Kubernetes, зокрема для свого застосунку. Деякі розробники платформи також є учасниками проєкту Kubernetes і створюють розширення, які передаються спільноті Kubernetes. Інші розробляють комерційні розширення з закритим вихідним кодом або специфічні для певного сайту.
- Або також: Extension
Розширення — це компоненти програмного забезпечення, які розширюють і глибоко інтегруються з Kubernetes для підтримки нових типів обладнання.
[+]Багато адміністраторів кластерів використовують екземпляри Kubernetes, дистрибутиви встановлені самостійно чи надані постачальниками послуг. Ці кластери вже мають попередньо встановлені розширення. В результаті більшість користувачів Kubernetes можуть не потребувати встановлення розширень, і ще менше користувачів можуть потребувати створення нових.
- Або також: 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 pattern
Шаблон Operator — це системний дизайн, який повʼязує контролер з одним чи кількома власними ресурсами.
[+]Ви можете розширити функціонал Kubernetes, додаючи контролери до свого кластера, поза вбудованими контролерами, які поставляються разом з самим Kubernetes.
Якщо запущений застосунок діє як контролер та має доступ до API для виконання завдань відносно власного ресурсу, що визначений в панелі управління, це приклад шаблону Operator.
- Або також: Aggregation Layer
Шар агрегації дозволяє встановлювати додаткові API в стилі Kubernetes у вашому кластері.
[+]Коли ви налаштували API сервер Kubernetes для підтримки додаткових API, ви можете додавати обʼєкти
APIServiceякі "затребують" URL-адреси в API Kubernetes.
Ваша думка
Чи була ця сторінка корисною?
Дякуємо за ваш відгук. Якщо ви маєте конкретне запитання щодо використання Kubernetes, ви можете поставити його Stack Overflow. Створіть тікет в репозиторії GitHub якщо ви хочете повідомити про проблему або запропонувати покращення.