Цієї ночі черговий реліз Kubernetes . За традицією, що склалася для нашого блогу, розповідаємо про ключові зміни в новій версії цього чудового Open Source-продукту.
Інформація, використана для підготовки цього матеріалу, взята з , і співвідносних issues, pull requests, Kubernetes Enhancement Proposals (KEP).
Почнемо з важливого введення від SIG cluster-lifecycle: динамічні відмовостійкі кластери Kubernetes (а якщо висловлюватися точніше, то self-hosted HA deployments) тепер за допомогою звичних (у контексті кластерів з одним вузлом) команд kubeadm (init и join). Якщо коротко, то для цього:
- сертифікати, що використовуються кластером, переносяться в секрети;
- для можливості використання кластера etcd усередині K8s-кластера (тобто позбавлення від існуючої досі зовнішньої залежності) задіяний ;
- документуються рекомендовані налаштування для зовнішнього балансувальника навантаження, що забезпечує стійку до відмови конфігурацію (надалі планується можливість відмови і від цієї залежності, але не на даному етапі).
Архітектура HA-кластера Kubernetes, створеного з kubeadm
З подробицями про реалізацію можна ознайомитись у . Ця фіча була по-справжньому довгоочікуваною: альфа-версія очікувалася ще K8s 1.9, але з'явилася тільки тепер.
API
Команда apply і взагалі декларативне управління об'єктами з kubectl в apiserver. Самі розробники коротко пояснюють своє рішення тим, що kubectl apply — фундаментальна частина роботи з конфігураціями в Kubernetes, проте «повна багів і складно піддається виправленням», у зв'язку з чим цю функціональність необхідно привести до нормального вигляду та перенести до control plane. Прості та наочні приклади існуючих сьогодні проблем:
Подробиці про реалізацію — у . Поточна готовність – альфа-версія (просування до бети заплановано на наступний реліз Kubernetes).
В альфа-версії стала доступною використання схеми OpenAPI v3 для створення та публікації OpenAPI-документації з CustomResources (CR), що використовуються для валідації (на стороні сервера) ресурсів K8s, які визначають користувач (CustomResourceDefinition, CRD). Публікація OpenAPI для CRD дозволяє клієнтам (наприклад, kubectl) виконувати валідацію на своїй стороні (у рамках kubectl create и kubectl apply) та видавати документацію за схемою (kubectl explain). Подробиці - в .
Існували раніше логи з прапором O_APPEND (а не O_TRUNC) щоб уникнути втрати логів у деяких ситуаціях і для зручності truncate'а логів зовнішніми утилітами для ротації.
Також у контексті Kubernetes API можна відзначити, що в PodSandbox и PodSandboxStatus поле runtime_handler для обліку інформації про RuntimeClass в pod'є (докладніше про нього читайте в тексті про , де цей клас і з'явився як альфа-версія), а в Admission Webhooks можливість визначати, які версії AdmissionReview вони підтримують. Зрештою, у правилах Admission Webhooks тепер масштаби їх застосування namespace'ами та рамками кластера.
сховища
, що мали статус бета-версії з релізу , стабільними (GA): цей feature gate більше не відключається і буде вилучений у Kubernetes 1.17.
використання змінних оточення так званого (наприклад, імені pod'а) для назв директорій, що монтуються як , отримала розвиток - у вигляді нового поля subPathExpr, за допомогою якого тепер визначається потрібне ім'я директорії. Спочатку фіча з'явилася у Kubernetes 1.11, але й для 1.14 залишилася у статусі альфа-версії.
Як і в минулий реліз Kubernetes, багато значущих змін представлено для CSI (Container Storage Interface), що активно розвивається:
CSI
Стала доступною (у рамках альфа-версії) зміни розміру для CSI-томів. Для її використання потрібно включити feature gate під назвою ExpandCSIVolumes, а також наявність підтримки цієї операції у конкретному CSI-драйвері.
Ще одна фіча для CSI в альфа-версії посилатися безпосередньо (тобто без використання PV/PVC) на CSI-томи у рамках специфікації pod'ів. Це знімає обмеження на використання CSI як виключно віддалених сховищ данихвідкриваючи для них двері у світ . Для використання () необхідно увімкнути CSIInlineVolume feature gate.
Намітився прогрес і у «начинках» Kubernetes, пов'язаних з CSI, які не такі помітні кінцевим користувачам (системним адміністраторам)… Зараз розробники змушені підтримувати дві версії кожного плагіна сховища: один — «на старий лад», всередині кодової бази K8s (in -tree), а другий - у рамках нового CSI (Докладніше про нього читайте, наприклад, в ). Це викликає зрозумілі незручності, які необхідно усунути у міру стабілізації CSI як такого. Просто взяти і оголосити застарілими (deprecated) API внутрішніх (in-tree) плагінів неможливо через .
Все це призвело до того, що альфа-версії досяг внутрішнього коду плагінів, що реалізуються як in-tree, в CSI plugins, завдяки чому турботи розробників будуть зведені до підтримки однієї версії їх плагінів, а сумісність зі старими API збережеться і їх можна буде оголосити застарілими за звичайним сценарієм. Очікується, що до наступного релізу Kubernetes (1.15) буде проведено міграцію всіх плагінів хмарних провайдерів, реалізація отримає статус бета-версії та активуватиметься в інсталяціях K8s за умовчанням. Подробиці див. . Наслідком цієї міграції також став від обмежень для томів, які визначаються конкретними хмарними провайдерами (AWS, Azure, GCE, Cinder).
Крім того, підтримка блокових пристроїв з CSI (CSIBlockVolume) у бета-версію.
Вузли / Kubelet
Представлено альфа-версію в Kubelet, призначений для віддачі метрик за основними ресурсами. Взагалі кажучи, якщо раніше Kubelet отримував статистику з використання контейнерів з cAdvisor, то тепер ці дані надходять з середовища контейнера через CRI (Container Runtime Interface), проте збережена і сумісність для роботи зі старими версіями Docker. Раніше зібрана в Kubelet статистика віддавалася через API, а тепер для цього використовується endpoint, розташований за адресою /metrics/resource/v1alpha1. Довгострокова ж стратегія розробників у тому, щоб мінімізувати набір метрик, що надаються Kubelet. До речі, самі ці метрики не "core metrics", а "resource metrics", і описують як "first-class resources, such as cpu, and memory".
Дуже цікавий нюанс: незважаючи на явну перевагу у продуктивності gRPC endpoint у порівнянні з різними випадками використання формату Prometheus (Результат одного з benchmark'ів див. нижче), автори віддали перевагу текстовому формату Prometheus через явне лідерство цієї системи моніторингу в спільноті.
«gRPC не сумісний із основними пайплайнами моніторингу. Endpoint ж буде корисним лише для поставки метрик в Metrics Server або компоненти моніторингу, які безпосередньо інтегруються з ним. При використанні кешування в Metrics Server продуктивність текстового формату Prometheus досить гарна для нас, щоб віддати перевагу Prometheus, а не gRPC, враховуючи широку поширеність Prometheus у спільноті. Коли формат OpenMetrics стане більш стабільним, ми зможемо наблизитись до продуктивності gRPC за допомогою формату на основі proto».
Один із порівняльних тестів продуктивності використання форматів gRPC та Prometheus у новому endpoint'і Kubelet для метрик. Більше графіків та інші подробиці можна знайти у .
Серед інших змін:
- Kubelet тепер (одноразово) контейнери в невідомому стані (unknown) перед операціями рестарту та видалення.
- Під час використання тепер init-контейнеру та сама інформація, як і звичайному контейнеру.
- Кубелет
usageNanoCoresз провайдера статистики CRI, а для вузлів та контейнерів у Windows мережна статистика. - Інформація про операційну систему та архітектуру тепер записується до лейблів
kubernetes.io/osиkubernetes.io/archоб'єктів Node (переведено з бети до GA). - Можливість вказівки конкретної системної групи користувачів для контейнерів у pod'і (
RunAsGroup, з'явилася в ) до бета-версії (за замовчуванням). - du і find, що використовуються в cAdvisor, на Go-реалізації.
CLI
У cli-runtime та kubectl прапор -k для інтеграції з (До речі, його технологія тепер ведеться в окремому репозиторії), тобто. для обробки додаткових YAML-файлів зі спеціальних директорій kustomization (подробиці про їх використання див. ):
Приклад простого використання файлу (можливе і більш складне застосування kustomize в рамках )
Крім того:
- нова команда
kubectl create cronjobназва якого говорить за себе. - В
kubectl logsтепер можна прапори-f(--followдля стрімінгу логів) та-l(--selectorдля label query). - кубектл копіювати файли, які вибираються за допомогою wild card.
- У команду
kubectl waitпрапор--allвибору всіх ресурсів у просторі імен зазначеного типу ресурсів.
Інші
Стабільний (GA) статус отримали такі можливості:
- , що використовується у специфікації pod'а для визначення додаткових умов, що враховуються у готовності pod'а;
- Підтримка великих сторінок (feature gate під назвою );
- ;
- PriorityClass API, .
Інші зміни, представлені в Kubernetes 1.14:
- RBAC за замовчуванням більше не дає доступу до API
discoveryиaccess-reviewкористувачам без аутентифікації (unauthenticated). - Офіційна підтримка CoreDNS тільки для Linux, тому при використанні kubeadm для його (CoreDNS) розгортання в кластері вузли повинні працювати тільки в Linux (для цього обмеження використовуються nodeSelectors).
- Конфігурація CoreDNS за замовчуванням замість proxy. Крім того, в CoreDNS readinessProbe, що запобігає балансуванню навантаження на відповідні (не готові до обслуговування) pod'и.
- У кубеадм, на фазах
initабоupload-certs, завантажувати сертифікати, потрібні для підключення нового control-plane до секрету kubeadm-certs (використовується прапор)--experimental-upload-certs). - Для Windows-інсталяцій з'явилася альфа-версія gMSA (Group Managed Service Account) — спеціальні облікові записи в Active Directory, які можуть використовуватися і контейнерами.
- Для GCE mTLS-шифрування між etcd та kube-apiserver.
- Оновлення у використовуваному/залежному програмному забезпеченні: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, підтримка Docker 18.09 у kubeadm, а мінімальною підтримуваною версією Docker API стала 1.26.
PS
Читайте також у нашому блозі:
- «»;
- «»;
- «»;
- «».
Джерело: habr.com