Команда розробників Kubernetes нещодавно вийшов через оголошення про випуск нова версія "Kubernetes 1.18" в якому команда розробників згадує, що це „підготовлена і довершена” версія.
У цій новій версії була проведена значна робота щодо вдосконалення бета-версії та стабільної функціональності гарантувати a кращий досвід користувачів. Подібні зусилля були докладені, щоб додати нові розробки та захоплюючі нові функції, які обіцяють ще більше покращити взаємодію з користувачем.
Для тих, хто не знає Кубернете, вони повинні це знати - це система з відкритим кодом для автоматизації розгортання, масштабування та управління контейнерні програми.
Це було спочатку розроблений Google, хоча згодом його розробку було доручено Фонду хмарних обчислень із відкритим кодом (CNCF), який сьогодні дозволив технології оркестровки контейнерів швидко дозрівати завдяки внеску технологічних гігантів.
Що нового в Kubernetes 1.18?
Ця нова версія виділяється наявністю можливість використовувати маркери службового рахунку як загальний метод автентифікації. Наприклад, якщо ви хочете, щоб стручок керував іншими ресурсами Kubernetes, такими як розгортання чи служба, він може бути пов’язаний із обліковим записом служби та створити необхідні ролі та прив’язки ролей.
Облікові записи служби Kubernetes (KSA) надсилають веб-маркери JSON (JWT) на сервер API для автентифікації. Це робить сервер API єдиним джерелом автентифікації для облікових записів послуг.
Кубернетес 1.18 сзабезпечує функціональність що дозволяє серверу API надавати документ виявлення OpenID Connect A, що містить відкриті ключі маркера на додаток до інших метаданих.
Ще однією зміною, яка відрізняється від Kubernetes 1.81, є можливість налаштування швидкості HPA для конкретних стручків. Використовували горизонтальний автомасштабтор стручків (HPA)a, щоб кластер Kubernetes автоматично реагував на високий / низький трафік. За допомогою HPA користувач може попросити контролер створити більше модулів у відповідь на стрибки процесора, інші вимірювання або вимірювання, передбачені додатком.
Kubernetes 1.18 має огляд профілів для запуску декількох конфігурацій планувальника. Як правило, у Kubernetes є два типи робочих навантажень: довгострокові послуги (наприклад, веб-сервери, API тощо) та завдання, які виконуються до завершення (більш відоме як ім'я Вакансії).
Через очевидні відмінності між типами робочого навантаження деякі користувачі вдаються до створення повних кластерів для різних потреб. Наприклад, один кластер для управління видобутком даних, а інший для обслуговування API додатків.
Причина полягає в тому, що їм потрібно, щоб процес прийняття рішень відрізнявся. Наприклад, налаштування планувальника за замовчуванням сприяють високій доступності.
З іншого боку, ми також можемо знайти можливість визначати правило трансляції стручків на рівні кластера, що дозволило гарантувати, що стручки будуть заплановані в зонах доступності (якщо ви використовуєте багатозоновий кластер), щоб забезпечити максимальну доступність та використання ресурсів.
Функціонал дозволяє специфікацію topologySpreadConstraints, яка ідентифікує області шляхом пошуку вузлів з однаковим тегом topologyKey. Вузли з однаковим тегом TopologyKey належать одній області. Конфігурація полягала в рівномірному розподілі стручків у різних областях. Однак недоліком є те, що це налаштування повинно застосовуватися на рівні стручка. Стручки, які не мають конфігурації, не будуть рівномірно розподілені між доменами несправностей.
Не в останню чергу, ми також можемо знайти можливість ігнорувати зміну властивості volume. За замовчуванням, коли том встановлений у контейнер кластера Kubernetes, усі файли та каталоги в цьому томі мають властивість, змінене на значення, надане через fsGroup.
Все це для того, щоб fsGroup читав і писав том. Однак у деяких випадках така поведінка виявляється небажаною.
Ця нова версія Kubernetes має ряд змін, і ми лише згадали кілька найважливіших. Якщо ви хочете дізнатися повний список, ви можете зробити це, відвідавши наступне посилання.