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



    Большое и хорошо организованное Open Source-сообщество, стоящее за разработкой Kubernetes, приучило нас ждать значимых и многочисленных изменений от каждого релиза. И Kubernetes 1.8 не стал исключением, представив на радость DevOps-инженерам и всем сочувствующимучастникам улучшения и новые возможности практически во всех своих компонентах.

    Официальный релиз Kubernetes 1.8 был запланирован ещё на минувшую среду, однако официальные анонсы (в блоге проекта и CNCF) пока не состоялись. Тем не менее, сегодня в 3:35 ночи по MSK в Git-репозитории проекта было замечено изменение в CHANGELOG, которое сигнализирует о готовности Kubernetes 1.8 для скачивания и использования:



    Итак, что же нового принёс релиз Kubernetes 1.8?

    Сеть


    В kube-proxy добавлена альфа-версия поддержки режима IPVS для балансировки нагрузки (вместо iptables). В этом режиме kube-proxy следит за сервисами и endpoints в Kubernetes, создавая netlink-интерфейс (virtual server и real server соответственно). Кроме того, он периодически синхронизирует их, поддерживая консистентность состояния IPVS. При запросе на доступ к сервису трафик перенаправляется на один из подов бэкенда. При этом IPVS предлагает различные алгоритмы для балансировки нагрузки (round-robin, least connection, destination hashing, source hashing, shortest expected delay, never queue). Такую возможность часто запрашивали в тикетах Kubernetes, и мы сами тоже очень её ждали.

    Среди других сетевых новшеств — бета-версии поддержки политик для исходящего трафика EgressRules в NetworkPolicy API, а также возможность (в том же NetworkPolicy) применения правил по CIDR источника/получателя (через ipBlockRule).

    Планировщик


    Главное новшество в планировщике — возможность задавать подам приоритеты (в спецификации пода, PodSpec, пользователи определяют поле PriorityClassName, а Kubernetes на его основе выставляет Priority). Цель банальна: улучшить распределение ресурсов в случаях, когда их не хватает, а требуется одновременно выполнить по-настоящему критичные задачи и менее срочные/важные. Теперь поды с высоким приоритетом будут получать больший шанс на исполнение. Кроме того, при освобождении ресурсов в кластере (preemption) поды с меньшим приоритетом будут затронуты скорее подов с высоким приоритетом. В частности, для этого в kubelet была изменена стратегия по выборке подов (eviction strategy), в которой теперь учитываются одновременно и приоритет пода, и потребление им ресурсов. Реализация всех этих возможностей имеет статус альфа-версии. Приоритеты Kubernetes и работа с ними подробно описаны в документации по архитектуре.

    Ещё одно интересное новшество, представленное в альфа-версии, — более сложный механизм обработки поля условий (Condition, см. документацию) на узлах. Традиционно в этом поле фиксируются проблемные состояния узла — например, при отсутствии сети условие NetworkUnavailable ставится в True, в результате чего поды перестанут назначаться на этот узел. С помощью нового подхода Taints Node by Condition такая же ситуация приведёт к пометке узла определённым статусом (например, node.kubernetes.io/networkUnavailable=:NoSchedule), на основе которого (в спецификации пода) можно решить, что делать дальше (действительно ли не назначать под такому проблемному узлу).

    Хранилища


    Указание опций монтирования для томов стало стабильным, а одновременно с этим:

    • в спецификации PersistentVolume появилось новое поле MountOptions для указания опций монтирования (вместо annotations);
    • в спецификации StorageClass появилось аналогичное поле MountOptions для динамически создаваемых томов.

    В API метрики Kubernetes добавлена информация о доступном пространстве в постоянных томах (PV), а также метрики успешности выполнения и времени задержки для всех вызовов mount/unmount/attach/detach/provision/delete.

    В спецификации PersistentVolume для Azure File, CephFS, iSCSI, GlusterFS теперь можно ссылаться на ресурсы в пространствах имён.

    Среди нестабильных нововведений (в статусах альфа и бета):

    • в StorageClass добавлена бета-версия поддержки определения reclaim policy (аналогично PersistentVolume) вместо применения политики delete всегда по умолчанию;
    • в Kubernetes API добавлена возможность увеличения размера тома — альфа-версия этой фичи увеличивает размер только для тома (не делает resize для файловой системы) и поддерживает только Gluster;
    • началась работа над изоляцией/ограничениями для хранилищ данных — в статусе альфа представлен новый ресурс ephemeral-storage, который включает в себя всё дисковое пространство, доступное контейнеру, и позволяет устанавливать ограничения на возможный объём (quota management) и запросы к нему (limitrange) — подробнее см. в текущей документации;
    • новое поле VolumeMount.Propagation для VolumeMount в контейнерах пода (альфа-версия) позволяет устанавливать значение Bidirectional для возможности использования того же примонтированного каталога на хосте и в других контейнерах;
    • доступен ранний прототип создания снимков томов (volume snapshots) через Kubernetes API — пока эти снапшоты могут быть неконсистентными, и ответственный за них код вынесен из ядра Kubernetes во внешний репозиторий.

    kubelet


    В kubelet появилась альфа-версия нового компонента — CPU Manager, — взаимодействующего напрямую с kuberuntime и позволяющего назначать контейнерам подов выделенные ядра процессоров (т.е. CPU affinity policies на уровне контейнеров). Как уточняется в документации, его появление стало ответом на две проблемы:

    1. плохая или непредсказуемая производительность по сравнению с виртуальными машинами (из-за большого количества переключений контекста и недостаточно эффективного использования кэша),
    2. недопустимые задержки, относящиеся к планировщику процессов ОС, что особенно заметно в функциях виртуальных сетевых интерфейсов.

    Динамическая конфигурация kubelet — ещё одна фича в альфа-статусе, позволяющая обновлять конфигурацию этого агента во всех узлах «живого» кластера. Доведение её до стабильного состояния (GA) ожидается только в релизе 1.10.

    Метрики


    Поддержка пользовательских метрик в Horizontal Pod Autoscaler (HPA) получила статус бета-версии, и связанные с ней API переведены на v1beta1.

    metrics-server стал рекомендованным способом предоставления API для метрик ресурсов. Деплоится как дополнение по аналогии с Heapster. Прямое получение метрик из Heapster объявлено устаревшим.

    Cluster Autoscaler


    Утилита Cluster Autoscaler, созданная для автоматического изменения размера кластера Kubernetes (когда есть поды, которые не запускаются из-за недостатка ресурсов, или некоторые узлы плохо используются долгое время), получила стабильный статус (GA) и поддержку до 1000 узлов.

    Кроме того, при удалении узлов Cluster Autoscaler теперь даёт подам по 10 минут для корректного завершения работы (graceful termination). В случае, если под так и не остановлен за это время, узел всё равно удаляется. Раньше этот лимит составлял 1 минуту или корректного завершения не дожидались вообще.

    kubeadm и kops


    В kubeadm появилась альфа-реализация деплоя кластера (control plane) типа self-hosted (kubeadm init с флагом --feature-gates=SelfHosting=true). Сертификаты при этом могут храниться на диске (hostPath) или в секретах. А новая подкоманда kubeadm upgrade (находится в бета-статусе) позволяет автоматически выполнять обновление кластера self-hosted, созданного с помощью kubeadm.

    Другая новая возможность kubeadm в статусе альфа — выполнение подзадач вместо всего цикла kubeadm init с помощью подкоманды phase (на текущий момент доступна как kubeadm alpha phase и будет приведена в официальный вид в следующем релизе Kubernetes). Основное предназначение — возможность лучшей интеграции kubeadm с provisioning-утилитами вроде kops и GKE.

    В kops, тем временем, представлены две новые фичи в статусе альфа: поддержка bare metal-машин в качестве целевых и возможность запуска как сервера (см. Kops HTTP API Server). Наконец, поддержку GCE в kops «повысили» до статуса бета-версии.

    CLI


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

    Команды rollout и rollback в kubectl теперь поддерживают StatefulSet.

    API


    Изменения в API включают в себя APIListChunking — новый подход к выдаче ответов на запросы LIST. Теперь они разбиваются на небольшие куски и выдаются клиенту в соответствии с указанным им лимитом. В результате, сервер потребляет меньше памяти и CPU при выдаче очень больших списков, и такое поведение станет стандартным для всех инфомеров в Kubernetes 1.9.

    CustomResourceDefinition API научился валидировать объекты, основываясь на JSON-схеме (из CRD-спецификации) — альфа-реализация доступна как CustomResourceValidation в kube-apiserver.

    Сборщик мусора получил поддержку пользовательских API, добавленных через CustomResourceDefinition или агрегированные API-серверы. Поскольку обновления контроллера происходят периодически, между добавлением API и началом работы сборщика мусора для него стоит ожидать задержку около 30 секунд.

    Workload API


    Так называемый Workload API — это базовая часть Kubernetes API, относящаяся к «рабочим нагрузкам» и включающая в себя DaemonSet, Deployment, ReplicaSet, StatefulSet. На данный момент эти API перенесены в группу apps и с релизом Kubernetes 1.8 получили версию v1beta2. Стабилизация же Workload API предполагает вынесение этих API в отдельную группу и достижение максимально возможной консистентности с помощью стандартизации этих API путём удаления/добавления/переименования имеющихся полей, определения однотипных значений по умолчанию, общей валидации. Например, стратегией spec.updateStrategy по умолчанию для StatefulSet и DaemonSet стал RollingUpdate, а выборка по умолчанию spec.selector для всех Workload API (из-за несовместимости с kubectl apply и strategic merge patch) отключена и теперь требует явного определения пользователем в манифесте. Обобщающий тикет с подробностями — #353.

    Другое


    Среди прочих (и весьма многочисленных!) изменений в релизе Kubernetes 1.8 отмечу:

    • управление доступом на основе ролей (RBAC), использующее группу API rbac.authorization.k8s.io для возможности конфигурации динамических политик, переведено в стабильный статус (GA), а также получило бета-версию нового API (SelfSubjectRulesReview) для просмотра действий, которые пользователь может выполнить с пространством имён;
    • представлена альфа-версия механизма для хранения ключей шифрования ресурсов в сторонних системах (Key Management Systems, KMS), и одновременно с этим появился плагин Google Cloud KMS (#48522);
    • в PodSecurityPolicies добавлена поддержка белого списка разрешённых путей для томов хоста;
    • поддержка CRI-O (Container Runtime Interface) на базе стандарта от Open Container Initiative объявлена стабильной (прошла все тесты e2e) [CRI-O — связующее звено между kubelet и исполняемыми средами, совместимыми с OCI, такими как runc; подробнее см. в GitHub], а также проект cri-containerd достиг статуса альфа-версии;
    • поддержка Multi-cluster, ранее известная как Federation, готовится к стабильному выпуску (GA) в следующих релизах Kubernetes, а пока стали доступны альфа-реализации Federated Jobs, которые автоматически деплоятся на множество кластеров, и Federated Horizontal Pod Autoscaling (HPA), работающих аналогично обычным HPA, но, опять же, с распространением на множество кластеров;
    • команда, ответственная за масштабируемость, формально зафиксировала процесс своего тестирования, создала документацию для имеющихся пороговых значений, определила новые наборы по уровням обслуживания (Service Level Indicators и Service Level Objectives).

    P.S.


    Во время подготовки Kubernetes 1.8 проект собирался со следующими версиями Docker: 1.11.2, 1.12.6, 1.13.1, 17.03.2. Список известных проблем (known issues) для них см. здесь. В том же документе, озаглавленном как «Introduction to v1.8.0», можно найти и более полный список всех крупных изменений.

    Сами мы затянули с обновлением обслуживаемых кластеров Kubernetes с релиза 1.6 до 1.7 и провели основную миграцию только 2 недели назад (на данный момент осталось несколько инсталляций с версией 1.6). Повсеместное обновление до нового релиза — 1.8 — планируем уже в октябре.

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

    • +23
    • 7,8k
    • 7
    Флант 285,10
    Специалисты по DevOps и высоким нагрузкам в вебе
    Поделиться публикацией
    Комментарии 7
    • 0
      А вот и официальный анонс релиза k8s 1.8 в блоге проекта подоспел.
      • 0
        Продвигаются ли планы о замене Докера внутри Кубернетиса?
        • +1
          Вы о cri-o.io?
          • 0
            Да, конечно. Всё начнёт переходить на containerd достаточно скоро. containerd.io
            Я сам на данный момент занимаюсь адаптацией containerd для одной из облачных платформ как части этого проекта.
            • 0
              А к какому релизу ориентировочно это будет? Если есть планы.
              • 0
                Можно с Келси Хайтаувером поговорить, он пальцем тыкает в containerd со стороны кубернетиса. Возможно скоро, возможно уже, будет работающий прототип или бэтка.
                • +1
                  В обзоре написано, что «проект cri-containerd достиг статуса альфа-версии». Бета-версию ожидают к концу года — см. слайд №15 из доклада Liu Lantao.

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

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