Kubernetes 1.13: обзор основных новшеств



    В начале этой недели состоялся очередной релиз Kubernetes, который окрестили «ангельским», — 1.13. Такое название связано с числом 113, которое считается «ангельским» и, со слов разработчиков Kubernetes, символизирует «новые начинания, трансформацию и конец одной главы перед открытием новых». Не вдаваясь в дальнейший анализ символизма происходящего, по уже сложившейся для нашего блога традиции, мы в седьмой раз расскажем о ключевых изменениях в новой версии Kubernetes, что призваны порадовать DevOps-/SRE-инженеров, работающих с этим продуктом.

    В качестве источников информации мы оперировали данными из таблицы Kubernetes enhancements tracking, CHANGELOG-1.13 и сооветствующих issues, pull requests, Kubernetes Enhancement Proposals (KEP).

    GA для kubeadm


    Одним из главных событий релиза Kubernetes 1.13 стало объявление стабильного статуса (General Availability, GA) для консольной утилиты kubeadm. В блоге K8s этому даже посвятили отдельную публикацию. Как многие знают, kubeadm — инструмент для создания кластеров Kubernetes согласно лучшим практикам проекта, а также их дальнейшего минимального сопровождения. Отличительная особенность в том, что разработчики стремятся сохранить его компактным и независимым от поставщика/инфраструктуры, не включая в него решение таких вопросов, как provisioning инфраструктуры, сторонние сетевые решения, дополнения (мониторинг, логирование и т.п.), специфичные интеграции с облачными провайдерами.

    Статус GA ознаменовал зрелость kubeadm в следующих вопросах:

    • стабильный консольный интерфейс, который следует политике Kubernetes по устареванию: команды и флаги, представленные в GA-релизе, должны поддерживаться не менее года после того, как объявлены устаревшими;
    • стабильная реализация «под капотом» благодаря тому, что кластер создаётся методами, которые не будут меняться в ближайшем времени: control plane запускается как множество статичных pod'ов, для kubeadm join используются bootstrap-токены, а для настройки kubelet задействован ComponentConfig;
    • схема конфигураций с новым API (v1beta1), которая позволяет декларативно описать практически все компоненты кластеров (становится возможным GitOps для создаваемых с kubeadm кластеров), — обновление до версии v1 запланировано с никакими или минимальными изменениями;
    • так называемые phases (или интерфейс toolbox) в kubeadm (kubeadm init phase), позволяющие выбирать, какие инициализирующие процедуры будут выполняться;
    • команда kubeadm upgrade гарантирует обновления кластера между релизами 1.10.x, 1.11.x, 1.12.x и 1.13.x (обновляет etcd, API Server, Controller Manager и Scheduler);
    • безопасная инсталляция etcd по умолчанию (повсеместно использует TLS) с возможностью расширения до HA-кластера при необходимости.

    Также можно отметить, что kubeadm теперь корректно распознает Docker 18.09.0 и его более новые версии. Наконец, разработчики просят пользователей kubeadm пройти небольшой онлайн-опрос, в котором можно высказать свои пожелания по использованию и развитию проекта.

    CoreDNS по умолчанию


    CoreDNS, получивший стабильный статус в релизе Kubernetes 1.11, пошёл ещё дальше и стал DNS-сервером по умолчанию в K8s (вместо использовавшегося до сих пор kube-dns). Планировалось, что это произойдёт ещё в 1.12, однако разработчики столкнулись с необходимостью проведения дополнительных оптимизаций в масштабируемости и потреблении памяти, которые были завершены только к нынешнему релизу.



    Поддержка kube-dns сохранится «как минимум на один следующий релиз», но разработчики говорят о необходимости начинать миграцию на актуальное решение уже сейчас.

    Из связанных с темой CoreDNS изменений в Kubernetes 1.13 можно также отметить появление плагина NodeLocal DNS Cache, призванного улучшить производительность работы DNS. Улучшение достигается благодаря запуску на узлах кластера агента для DNS-кэша, к которому будут напрямую обращаться pod'ы этого узла. По умолчанию функция отключена, а для её активации необходимо выставить KUBE_ENABLE_NODELOCAL_DNS=true.

    Хранилища


    Большое внимание в последних релизах Kubernetes уделяется работе с Container Storage Interface (CSI), что началась с альфа-версии CSI в K8s 1.9, продолжилась бета-версией в 1.10… Впрочем, мы уже писали о нём и не раз. В K8s 1.13 достигнута новая значимая веха: поддержка CSI объявлена стабильной (GA).

    image
    (Схема из статьи «Понимаем Container Storage Interface»)

    Вместе с этим, появилась поддержка спецификации CSI версии v1.0.0 и признана устаревшей поддержка старых версий стандарта (0.3 и более ранних). Это означает, что старым драйверам CSI для работы в Kubernetes 1.15 и старших версий потребуется обновление до CSI 1.0 (и перемещение в новый каталог регистрации плагинов Kubelet). К слову, из самих драйверов стоит отметить появление альфа-версии интерфейса CSI для управления жизненным циклом томов AWS EBS (Elastic Block Store).

    Новое дополнение в addon manager теперь производит автоматическую установку CRD от CSI, если активирован хотя бы один из двух feature gates: CSIDriverRegistry и CSINodeInfo. Оно имеет статус альфа-версии, а по сути является лишь временным решением задачи, подробно описанной как механизм установки CRD.

    Стало стабильным планирование томов с учётом топологии (Topology Aware Volume Scheduling), про которое мы рассказывали в контексте релиза Kubernetes 1.10. Если вкратце, то с ним планировщик в своей работе учитывает ограничения топологии тома pod'а (например, его зону и узел).

    Представленная ещё в Kubernetes 1.9 возможность использовать блочные raw-устройства (не сетевые) как Persistent Volumes переведена в бета-версию и отныне включена по умолчанию.

    Завершим тему хранилищ тем, что поддержка GCERegionalPersistentDisk объявлена стабильной.

    Узлы кластера


    Представлена альфа-версия поддержки сторонних плагинов для мониторинга устройств. Идея этой инициативы заключается в том, чтобы вынести из Kubelet специфичные для устройств знания вовне (out-of-tree). Администраторы кластеров получат метрики, сообщаемые плагинами устройств на уровне контейнера, а производители — возможность создавать эти метрики без необходимости вносить изменения в ядро Kubernetes. С подробностями о реализации можно ознакомиться в предложении, получившем название Kubelet Metadata API.

    Объявлен стабильным Kubelet Plugin Watcher (его же называли Kubelet Device Plugin Registration), позволяющий плагинам уровня узла (плагины устройств, CSI и CNI) сообщать о себе Kubelet и взаимодействовать с ним.

    Новая возможность в статусе альфа-версии — NodeLease. Если раньше «пульс» (heartbeat) узла определялся по NodeStatus, то с новой фичей у каждого узла появляется связанный с ним объект Lease (в пространстве имён kube-node-lease), который периодически обновляется узлом. «Пульс» же теперь задают оба параметра: и прежний NodeStatus, который сообщается мастеру только в случае изменений либо по фиксированному таймауту (по умолчанию это раз в минуту), и новый объект (он обновляется часто). Поскольку этот объект совсем небольшой, это значительно улучшит масштабируемость и производительность. Авторы взялись за создание нового «пульса» после тестирования кластеров с размером более 2000 узлов, которые во время своей работы могли упираться в лимиты etcd, — подробнее см. в KEP-0009.

    type Lease struct {
      metav1.TypeMeta `json:",inline"`
      // Standard object's metadata.
      // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
      // +optional
      ObjectMeta metav1.ObjectMeta `json:"metadata,omitempty"`
    
      // Specification of the Lease.
      // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status
      // +optional
      Spec LeaseSpec `json:"spec,omitempty"`
    }
    
    type LeaseSpec struct {
      HolderIdentity       string           `json:"holderIdentity"`
      LeaseDurationSeconds int32            `json:"leaseDurationSeconds"`
      AcquireTime          metav1.MicroTime `json:"acquireTime"`
      RenewTime            metav1.MicroTime `json:"renewTime"`
      LeaseTransitions     int32            `json:"leaseTransitions"`
    }

    (Компактная спецификация нового объекта для представления «пульса» узла — Lease — идентична LeaderElectionRecord)

    Безопасность


    Альфа-версия Dynamic Audit Control следует идеям Dynamic Admission Control и обеспечивает динамическую конфигурацию продвинутых возможностей аудита — для этого теперь можно зарегистрировать (динамически) webhook, который будет получать поток событий. Потребность в этой фиче объясняется тем, что аудит в Kubernetes предлагает очень мощные возможности, однако они сложны в настройке, а каждое изменение конфигурации до сих пор требовало перезагрузки apiserver.

    Шифрование данных в etcd (см. официальную документацию) переведено из экспериментального статуса в бета-версию.

    kind: EncryptionConfiguration
    apiVersion: apiserver.config.k8s.io/v1
    resources:
      - resources:
        - secrets
        providers:
        - identity: {}
        - aesgcm:
            keys:
            - name: key1
              secret: c2VjcmV0IGlzIHNlY3VyZQ==
            - name: key2
              secret: dGhpcyBpcyBwYXNzd29yZA==
        - aescbc:
            keys:
            - name: key1
              secret: c2VjcmV0IGlzIHNlY3VyZQ==
            - name: key2
              secret: dGhpcyBpcyBwYXNzd29yZA==
        - secretbox:
            keys:
            - name: key1
              secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=

    (Пример конфигурации с зашифрованными данными — взят из документации.)

    Среди менее значимых новшеств в этой категории:

    • Теперь apiserver можно настроить на отказ от запросов, которые не могут попасть в audit-логи.
    • Объектам PodSecurityPolicy добавили поддержку правила MayRunAs для опций fsGroup и supplementalGroups, позволяющего определять диапазон разрешённых идентификаторов групп (GID) для подов/контейнеров без принудительного установления GID по умолчанию. Кроме того, с PodSecurityPolicy теперь в спецификации pod'ов возможна стратегия RunAsGroup, т.е. можно контролировать основной GID для контейнеров.
    • Для kube-scheduler заменили прежний небезопасный порт (10251) на новый безопасный (10259) и включили его по умолчанию. Если никаких дополнительных флагов не указано, то при загрузке для него в памяти создаются самоподписанные сертификаты.

    CLI


    Команда kubectl diff, показывающая разницу между локальной конфигурацией и актуальным описанием работающего объекта (работает и рекурсивно для каталогов с конфигурациями), получила статус бета-версии.

    Фактически diff «предсказывает» изменения, которые будут внесены с выполнением команды kubectl apply, и для этого используется другая новая возможность — APIServer DryRun. Её суть — холостой запуск — должна быть ясна из названия, а более подробное описание доступно в документации Kubernetes. К слову, в релизе 1.13 функцию DryRun тоже «повысили» до бета-версии и включили по умолчанию.

    И ещё одно продвижение до бета-версии в консольном мире Kubernetes затронуло новый механизм плагинов. Попутно в нём исправили порядок вывода плагинов (kubectl plugin list), убрав оттуда дополнительную сортировку.

    Кроме того, в kubectl describe node добавили вывод используемых ресурсов ephemeral-storage, а в kubectl describe pod — томов типа projected.

    Другие изменения


    Функция планировщика Taint Based Eviction переведена в статус бета-версии и включена по умолчанию после долгого затишья в разработке. Её предназначение — автоматическое добавление taints на узлы (посредством NodeController или kubelet) при наступлении определённых условий, таких как, например, node.kubernetes.io/not-ready, что соответствует значению NodeCondition в Ready=False.

    Аннотация критически важных для работы кластера pod'ов — critical-podобъявлена устаревшей. Вместо неё предлагается использовать приоритеты (в бета-версии с Kubernetes 1.11).

    Для AWS впервые (в рамках альфа-версий) стали доступны:

    • интеграция для AWS ALB (Application Load Balancer) с ресурсами Kubernetes Ingress — aws-alb-ingress-controller (проект был изначально создан компаниями Ticketmaster и CoreOS для миграции первой в облако AWS);
    • внешний CCM (Cloud Controller Manager) для AWS — cloud-provider-aws, — который отвечает за запуск контроллеров со специфичной для облачного провайдера (AWS) функциональностью.

    В SIG Azure реализовали дополнительную поддержку для Azure Disk (Ultra SSD, Standard SSD и Premium Azure Files) и продвинули Cross resource group nodes до бета-версии. Кроме того, в CNI-плагинах для Windows появилась возможность настройки DNS в контейнере.

    Совместимость


    • Версия etcd — 3.2.24 (не изменилась с Kubernetes 1.12).
    • Проверенные версии Docker — 1.11.1, 1.12.1, 1.13.1, 17.03, 17.06, 17.09, 18.06 (тоже не изменились).
    • Версия Go — 1.11.2, совпадает с минимально поддерживаемой.
    • Версия CNI — 0.6.0.
    • Версия CSI — 1.0.0.
    • Версия CoreDNS — 1.2.6.

    P.S.


    Читайте также в нашем блоге:

    • +30
    • 4,8k
    • 3

    Флант

    296,00

    Специалисты по DevOps и высоким нагрузкам в вебе

    Поделиться публикацией
    Комментарии 3
      0

      Открыл в надежде прочитать что появилась нативная поддержка в макос. :(

        0

        Что вы имеете ввиду под нативной поддержкой? И чем вас нынешние варианты не устраивают?

          0
          Попробую объяснить на словах…

          В linux есть нативная поддержка слоев в файловой системе. Докер использует именно эту возможность для создания контейнера. Докер просто создает слой на существующую файловую систему. Тем самым имеет доступ к файлам напрямую. И также может создавать файлы в своем слое, который не видим для ОС. Скорость работы контейнера сохраняется на уровне скорости родительского сервера.

          Так как iOS основан на ядре Unix, в нем нет поддержки слоев в файловой системе. Чтобы обойти это ограничение iOS использует виртуальную машину.
          Связь между файловой системой и виртуалкой осуществляется через сеть (nfs или smb).
          Такая схема нагружает сетевой протокол при большом количестве запросов на чтение файлов. В определенный момент ОС при перегрузки сети просто рубит запрос и сервер получает ошибку «файл не найден». В результате в браузере мы видим ошибки загрузки множества статических файлов. Также скорость сети накладывает свой след на скорость обработки данных в виртуальной машине. Как следствие мы видим низкую скорость работы виртуалки. Что делает использование докера для дева на больших проектах проблематичным.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое