Промислове оточення

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

Аспекти промислової експлуатації

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

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

• Доступність: Одномашинне навчальне оточення Kubernetes має одну точку відмови. Створення високодоступного кластера передбачає розгляд таких аспектів:

  • Відокремлення панелі управління від робочих вузлів.
  • Реплікація компонентів панелі управління на кількох вузлах.
  • Балансування трафіку до API-сервера кластера.
  • Наявність достатньої кількості робочих вузлів або можливість їх швидкого введення в експлуатацію, коли цього вимагають зміни робочих навантажень.

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

• Безпека та управління доступом: У вас є повні привілеї адміністратора у власному навчальному кластері Kubernetes. Але спільні кластери з важливими робочими навантаженнями та більше ніж одним або двома користувачами вимагають більш витонченого підходу до того, хто і що може отримати доступ до ресурсів кластера. Ви можете використовувати керування доступом на основі ролей (RBAC) та інші механізми безпеки, щоб переконатися, що користувачі та робочі навантаження можуть отримати доступ до потрібних їм ресурсів, зберігаючи при цьому робочі навантаження та сам кластер у безпеці. Ви можете встановлювати обмеження на ресурси, до яких користувачі та робочі навантаження мають доступ, керуючи політиками та ресурсами контейнерів.

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

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

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

Налаштування промислового кластера

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

Панель управління промислового кластера

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

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

• Оберіть інструменти розгортання: Ви можете розгорнути панель управління за допомогою таких інструментів, як kubeadm, kops та kubespray. Перегляньте Встановлення Kubernetes за допомогою інструментів розгортання, щоб дізнатися поради щодо розгортань промислової якості з використанням кожного з цих методів розгортання. Для ваших розгортань доступні різні середовища виконання контейнерів.
• Керуйте сертифікатами: Безпечний звʼязок між службами панелі управління реалізується за допомогою сертифікатів. Сертифікати автоматично генеруються під час розгортання, або ви можете генерувати їх за допомогою власного центру сертифікації. Докладніше дивіться Сертифікати PKI та вимоги.
• Налаштуйте балансувальник навантаження для apiserver: Налаштуйте балансувальник навантаження для розподілу зовнішніх запитів API між екземплярами служби apiserver, що працюють на різних вузлах. Докладніше дивіться Створення зовнішнього балансувальника навантаження.
• Відокремте службу etcd та робіть її резервні копії: Служби etcd можуть працювати або на тих самих машинах, що й інші служби панелі управління, або на окремих машинах для додаткової безпеки та доступності. Оскільки etcd зберігає дані конфігурації кластера, резервне копіювання бази даних etcd слід виконувати регулярно, щоб мати змогу відновити цю базу даних у разі потреби. Докладніше про налаштування та використання etcd дивіться в ЧаПи etcd. Докладніше дивіться Управління кластерами etcd для Kubernetes та Налаштування високодоступного кластера etcd за допомогою kubeadm.
• Створіть кілька систем панелі управління: Для забезпечення високої доступності панель управління не повинна обмежуватися однією машиною. Якщо служби панелі управління запускаються службою init (такою як systemd), кожна служба повинна працювати щонайменше на трьох машинах. Однак запуск служб панелі управління як Podʼів у Kubernetes гарантує, що запитана вами кількість реплік служб завжди буде доступною. Планувальник повинен бути стійким до збоїв, але не високодоступним. Деякі інструменти розгортання налаштовують алгоритм консенсусу Raft для обрання лідера серед служб Kubernetes. Якщо основна служба зникає, інша служба обирає себе лідером і перебирає контроль на себе.
• Використовуйте кілька зон: Якщо важливо, щоб ваш кластер був доступним у будь-який час, розгляньте можливість створення кластера, який працює у кількох центрах обробки даних, відомих як зони в хмарних середовищах. Групи зон називаються регіонами. Розподіливши кластер по кількох зонах в одному регіоні, ви можете покращити ймовірність того, що ваш кластер продовжуватиме працювати, навіть якщо одна зона стане недоступною. Докладніше дивіться Запуск у кількох зонах.
• Керуйте поточними функціями: Якщо ви плануєте тримати свій кластер протягом тривалого часу, є завдання, які вам потрібно виконувати для підтримання його справності та безпеки. Наприклад, якщо ви встановили кластер за допомогою kubeadm, є інструкції, які допоможуть вам з керуванням сертифікатами та оновленням кластерів kubeadm. Дивіться Адміністрування кластера для отримання більш докладного списку адміністративних завдань Kubernetes.

Щоб дізнатися про доступні опції під час запуску служб панелі управління, дивіться сторінки компонентів kube-apiserver, kube-controller-manager та kube-scheduler. Приклади високодоступної панелі управління дивіться в Варіанти топології високої доступності, Створення високодоступних кластерів за допомогою kubeadm та Управління кластерами etcd для Kubernetes. Інформацію щодо створення плану резервного копіювання etcd дивіться в Резервне копіювання кластера etcd.

Робочі вузли промислового кластера

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

• Налаштуйте вузли: Вузли можуть бути фізичними або віртуальними машинами. Якщо ви хочете створювати власні вузли та керувати ними, ви можете встановити підтримувану операційну систему, а потім додати та запустити відповідні служби вузла. Розгляньте такі питання:
  • Вимоги ваших робочих навантажень під час налаштування вузлів: наявність відповідного обсягу памʼяті, CPU, швидкості дисків та ємності сховища.
  • Чи підійдуть звичайні компʼютерні системи, чи у вас є робочі навантаження, які потребують процесорів GPU, вузлів Windows або ізоляції віртуальних машин.
• Перевірте вузли: Дивіться Правильне налаштування вузла для інформації про те, як переконатися, що вузол відповідає вимогам для приєднання до кластера Kubernetes.
• Додайте вузли до кластера: Якщо ви керуєте своїм власним кластером, ви можете додавати вузли, налаштовуючи свої власні машини та додаючи їх вручну або налаштувавши їх на самостійну реєстрацію в apiserver кластера. Дивіться розділ Вузли для інформації щодо того, як налаштувати Kubernetes для додавання вузлів цими способами.
• Масштабуйте вузли: Майте план розширення ємності, яка зрештою знадобиться вашому кластеру. Дивіться Міркування щодо великих кластерів, щоб визначити, скільки вузлів вам потрібно, виходячи з кількості Podʼів і контейнерів, які вам потрібно запустити. Якщо ви керуєте вузлами самостійно, це може означати придбання та встановлення власного фізичного обладнання.
• Автомасштабуйте вузли: Ознайомтесь з Автомасштабуванням вузлів, щоб дізнатись про інструменти, доступні для автоматизованого керування вашими вузлами та ємністю, яку вони надають.
• Налаштуйте перевірки справності вузлів: Для важливих робочих навантажень потрібно переконатися, що вузли та Podʼи, які працюють на цих вузлах, є справними. За допомогою демона Node Problem Detector ви можете забезпечити справність своїх вузлів.

Управління користувачами промислового кластера

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

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

• Автентифікація: apiserver може автентифікувати користувачів за допомогою клієнтських сертифікатів, токенів доступу, проксі автентифікації або базової HTTP-автентифікації. Ви можете вибрати методи автентифікації, які ви хочете використовувати. За допомогою втулків apiserver може використовувати наявні методи автентифікації вашої організації, такі як LDAP або Kerberos. Див. Автентифікація для опису різних методів автентифікації користувачів Kubernetes.
• Авторизація: Коли ви починаєте авторизовувати звичайних користувачів, ви, ймовірно, вибиратимете між авторизацією RBAC та ABAC. Див. Огляд авторизації для ознайомлення з різними режимами авторизації облікових записів користувачів (а також доступу службових облікових записів до вашого кластера):
  • Керування доступом на основі ролей (RBAC): Дозволяє вам призначати доступ до вашого кластера, надаючи конкретні набори дозволів автентифікованим користувачам. Дозволи можуть бути призначені для конкретного простору імен (Role) або для всього кластера (ClusterRole). Потім, використовуючи RoleBindings та ClusterRoleBindings, ці дозволи можна привʼязати до певних користувачів.
  • Керування доступом на основі атрибутів (ABAC): Дозволяє вам створювати політики на основі атрибутів ресурсів у кластері, які дозволятимуть або забороняти доступ на основі цих атрибутів. Кожен рядок файлу політики ідентифікує властивості версії (apiVersion та kind) та мапу властивостей spec для зіставлення з субʼєктом (користувачем або групою), властивістю ресурсу, властивістю нересурсу (/version або /apis) та readonly. Дивіться Приклади для отримання деталей.

Якщо ви налаштовуєте автентифікацію та авторизацію на своєму промисловому кластері Kubernetes, ось кілька речей, які варто врахувати:

• Встановіть режим авторизації: Коли API-сервер Kubernetes (kube-apiserver) запускається, підтримувані режими авторизації повинні бути встановлені за допомогою файлу --authorization-config або прапорця --authorization-mode. Наприклад, цей прапорець у файлі kube-adminserver.yaml (в /etc/kubernetes/manifests) може бути встановлений у значення Node,RBAC. Це дозволить авторизацію Node та RBAC для автентифікованих запитів.
• Створіть сертифікати користувачів та привʼязки ролей (RBAC): Якщо ви використовуєте авторизацію RBAC, користувачі можуть створювати CertificateSigningRequest (CSR), які можуть бути підписані CA кластера. Потім ви можете привʼязувати Roles та ClusterRoles до кожного користувача. Дивіться Запити на підпис сертифікатів для отримання деталей.
• Створіть політики, що комбінують атрибути (ABAC): Якщо ви використовуєте авторизацію ABAC, ви можете призначати комбінації атрибутів для формування політик для авторизації обраних користувачів або груп для доступу до певних ресурсів (наприклад, Pod), просторів імен або apiGroup. Докладніше дивіться Приклади.
• Зверніть увагу на контролери допуску: Додаткові форми авторизації для запитів, які можуть надходити через API-сервер, включають автентифікацію токенів за допомогою вебхуків. Вебхуки та інші спеціальні типи авторизації потрібно увімкнути, додавши контролери допуску до API-сервера.

Встановлення обмежень на ресурси робочих навантажень

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

• Встановіть обмеження простору імен: Встановіть квоти для кожного простору імен на такі речі, як памʼять та CPU. Дивіться Керування ресурсами памʼяті, CPU та API для отримання деталей.
• Підготуйтесь до навантаження на DNS: Якщо ви очікуєте, що робочі навантаження значно масштабуватимуться, ваша служба DNS повинна бути готовою також масштабуватися. Дивіться Автоматичне масштабування служби DNS в кластері.
• Створюйте додаткові службові облікові записи: Облікові записи користувачів визначають, що користувачі можуть робити в кластері, тоді як службовий обліковий запис визначає доступ Podʼів у межах певного простору імен. Типово Pod отримує типовий службовий обліковий запис зі свого простору імен. Дивіться Управління службовими обліковими записами для інформації про створення нового службового облікового запису. Наприклад, ви можете:
  • Додати секрети, які Pod може використовувати для отримання образів з певного реєстру контейнерів. Дивіться Налаштування службових облікових записів для Podʼів для прикладу.
  • Призначити дозволи RBAC службовому обліковому запису. Дивіться Дозволи службового облікового запису для отримання деталей.

Що далі

• Вирішіть, чи хочете ви будувати свій власний промисловий кластер Kubernetes чи отримати його від доступних постачальників хмарних рішень під ключ чи партнерів Kubernetes.
• Якщо ви вирішите створити власний кластер, сплануйте, як ви хочете розвʼязувати питання сертифікатів та налаштувати високу доступність для функцій, таких як etcd та API-сервер.
• Виберіть методи розгортання з kubeadm, kops чи Kubespray.
• Налаштуйте управління користувачами, визначивши свої методи автентифікації та авторизації.
• Підготуйтеся до робочих навантажень застосунків, налаштувавши обмеження ресурсів, автомасштабування DNS та службові облікові записи.