Операційне середовище

Створіть кластер 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ʼа: Налаштуйте балансувальник навантаження, щоб розподілити зовнішні запити до екземплярів apiserver, що працюють на різних вузлах. Дивіться Створення зовнішнього балансувальника навантаження.
  • Відділіть та робіть резервні копії служби 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). Незалежно від того, чи керуєте ви власною панеллю управління, чи хмарний провайдер робить це за вас, вам все одно потрібно подумати, як ви хочете керувати своїми робочими вузлами (також їх просто називають вузлами).

  • Налаштування вузлів: Вузли можуть бути фізичними або віртуальними машинами. Якщо ви хочете створювати та управляти власними вузлами, ви можете встановити підтримувану операційну систему, додати та запустити відповідні Служби вузлів. Розгляньте такі питання:
    • Вимоги вашого робочого навантаження при налаштуванні вузлів, маючи відповідну кількість памʼяті, процесора та швидкості дискових операцій та обʼєму сховища.
    • Чи підійдуть загальні компʼютерні системи, чи у вас є завдання, які потребують процесорів GPU, вузлів з операційною системою Windows або ізоляції віртуальних машин.
  • Перевірка вузлів: Дивіться Правильне налаштування вузлів для інформації про те, як переконатися, що вузол відповідає вимогам для приєднання до кластера Kubernetes.
  • Додавання вузлів до кластера: Якщо ви керуєте своїм власним кластером, ви можете додавати вузли, налаштовуючи свої власні машини та додаючи їх вручну або реєструючи їх в службі apiserver кластера. Дивіться розділ Вузли для інформації щодо того, як налаштувати Kubernetes для додавання вузлів цими способами.
  • Масштабування вузлів: Майте план розширення потужності вашого кластера на майбутнє. Дивіться Рекомендації для великих кластерів, щоб визначити, скільки вузлів вам потрібно, виходячи з кількості podʼів і контейнерів, які вам потрібно запустити. Якщо ви керуєте вузлами самостійно, це може означати придбання та встановлення власного фізичного обладнання.
  • Автомасштабування вузлів: Ознайомтесь з Автомасштабуванням кластера, щоб дізнатись про інструменти доступні для автоматизованого керування вашими вузлами та ресурсами, які вони надають.
  • Налаштування перевірок справності вузлів: Для важливих завдань важливо переконатися, що Nodeʼи та 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, включають Автентифікацію токенів за допомогою вебхуків. Вебхуки та інші спеціальні типи авторизації повинні бути увімкнені додаванням Контролерів допуску (Admission Controllers) до сервера API.

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

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

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

Що далі

Змінено December 17, 2024 at 11:53 AM PST: Sync upstream after v1.32 release (d7b08bbf8e)