Этой ночью очередной релиз 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 статистика отдавалась через REST 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-контейнеру та же информация, что и обычному контейнеру.
- Kubelet
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). - kubectl копировать файлы, выбираемые с помощью 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’ы.
- В kubeadm, на фазах
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.
P.S.
Читайте также в нашем блоге:
- «»;
- «»;
- «»;
- «».
Источник: habr.com