company_banner

Docker 17.06 и Kubernetes 1.7: ключевые новшества


    Прошлая неделя подарила два «вкусных» релиза из Open Source-мира контейнеров: практически одновременно обновились Docker (версия 17.06) и Kubernetes (версия 1.7). Какие возможности они принесли? В статье представлена информация из анонсов и release notes этих релизов с небольшими уточнениями по некоторым из ключевых изменений.

    Docker CE 17.06


    28 июня был анонсирован Docker CE (Community Edition) 17.06 — первый выпуск контейнерной системы, собранный с помощью проекта Moby, анонсированного в апреле. Подробнее о Moby мы уже писали.

    Сборка в несколько этапов


    Главной фичей релиза стала официальная стабилизация поддержки многоэтапных сборок (multi-stage builds), впервые представленных в Docker 17.05.0. Её суть заключается в возможности описывать в одном Dockerfile несколько этапов сборки образа для того, чтобы в конечный образ не попадали промежуточные данные, которые не требуются. Очевидный пример, который приводят в Docker: Java-разработчики обычно используют Apache Maven для компиляции своих приложений, однако Maven не нужен в конечном контейнере (образе) для запуска этих приложений. Теперь можно оформить Dockerfile таким образом, что сам Maven будет использоваться в промежуточном образе (для сборки), но не попадёт в конечный (для запуска).

    Вот вариант Dockerfile для простого приложения на Java Spring Boot:

    FROM node:latest AS storefront
    WORKDIR /usr/src/atsea/app/react-app
    COPY react-app/package.json .
    RUN npm install
    COPY . /usr/src/atsea/app
    RUN npm run build

    FROM maven:latest AS appserver
    WORKDIR /usr/src/atsea
    COPY pom.xml .
    RUN mvn -B -f pom.xml -s /usr/share/maven/ref/settings-docker.xml dependency:resolve
    COPY . .
    RUN mvn -B -s /usr/share/maven/ref/settings-docker.xml package -DskipTests

    FROM java:8-jdk-alpine
    WORKDIR /static
    COPY --from=storefront /usr/src/atsea/app/react-app/build/ .
    WORKDIR /app
    COPY --from=appserver /usr/src/atsea/target/AtSea-0.0.1-SNAPSHOT.jar .
    ENTRYPOINT ["java", "-jar", "/app/AtSea-0.0.1-SNAPSHOT.jar"]
    CMD ["--spring.profiles.active=postgres"]


    Как видно, две подготовительные стадии здесь используют Node.js и Apache Maven для сборки приложения, однако результирующий образ будем компактным, не имея в своём составе ни Node.js, ни Maven.

    Примечание: До настоящего времени у себя в компании мы для этих целей использовали фичу под названием артефакты в собственной Open Source-утилите dapp (её обзор см. здесь).

    Логи и метрики


    Метрики Docker теперь могут использоваться в плагинах. Для демонстрации приводится пример плагина, который проксирует запросы на метрику, доступную в нём:

    $ docker plugin install --grant-all-permissions cpuguy83/docker-metrics-plugin-test:latest
    $ curl http://127.0.0.1:19393/metrics
    

    Но это лишь демонстрация, а реальное предназначение этого новшества — отправлять с помощью плагинов собранные метрики в какой-либо внешний сервис или делать их доступными для сборки другим сервисом (например, Prometheus).

    Плагины теперь также могут использоваться и для логов (т.е. для реализации logging drivers), а вывод списка всех драйверов журналирования добавлен в docker info. Кроме того, реализацию docker service logs, которая (тоже с прошлого релиза, 17.05) может показывать и логи индивидуальных заданий (/task/{id}/logs в REST), перенесли из ветки Edge в Stable, поэтому теперь легко получить обобщённые логи для всего сервиса, запущенного в Swarm.

    Сеть


    Стала возможной привязка сервисов к сетям внутри узла (node-local): Host, Macvlan, IPVlan, Bridge, local-scope. Приводимый для Macvlan пример — это создание специфичных для узла сетевых конфигураций на рабочих узлах и сети на управляющем узле, которая будет их применять:

    [Wrk-node1]$ docker network create --config-only --subnet=10.1.0.0/16 local-config
    [Wrk-node2]$ docker network create --config-only --subnet=10.2.0.0/16 local-config
    [Mgr-node2]$ docker network create --scope=swarm --config-from=local-config -d macvlan
    mynet
    [Mgr-node2]$ docker service create --network=mynet my_new_service

    В рамках этого же изменения была добавлена цепочка DOCKER-USER в iptables, которая вставляется первой в FORWARD и не сбрасывается (за это дополнение — благодарность ertaquo!).

    Кроме того, во внутренние алгоритмы Service Discovery привнесены изменения, которые призваны улучшить логику её работы.

    Swarm


    Ряд новшеств получил режим Swarm, а в частности:

    • объекты конфигурации (Configuration Objects), позволяющие безопасно передавать информацию о конфигурации по аналогии с тем, как это делалось для секретов:

      $ echo "This is a config" | docker config create test_config -
      $ docker service create --name=my-srv --config=test_config …
      $ docker exec -it 37d7cfdff6d5 cat test_config
      This is a config

    • функция ротации CA-сертификатов в системе public key infrastructure (PKI), применяемой для безопасного деплоя системы оркестровки контейнеров (docker swarm ca --rotate);
    • поддержка событий (ранее были доступны вне Swarm) для получения в реальном времени данных о сервисах, узлах, сетях, секретах;
    • новый флаг --datapath-addr для docker swarm init, указывающий сетевой интерфейс для изоляции заданий управления (control traffic) от данных приложений (data traffic) — полезно в случае приложений, производящих большую нагрузку на ввод/вывод;
    • возможность указывать место хранения секрета в контейнере (вместо традиционного /var/run).

    Более подробный лог изменений в Docker 17.06 вместе с ссылками на коммиты можно найти в Docker CE release notes. А для любителей смотреть и слушать есть 8-минутное видео с рассказом и демонстрацией основных новшеств.

    Kubernetes 1.7


    29 июня был анонсирован Kubernetes 1.7, главными нововведениями которого названы улучшения в безопасности, поддержке stateful-приложений, расширяемости платформы. Что за этим стоит?

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


    • Объявлен стабильным Network Policy API, позволяющий настраивать правила, определяющие (и ограничивающие) взаимодействие между подами.
    • Node authorizer, позволяющий ограничивать API-запросы kubelet (к секретам, подам и другим объектам узла).
    • Альфа-версия шифрования секретов и других ресурсов, хранимых в etcd.
    • В kubelet TLS bootstrapping добавлена поддержка ротации сертификата клиента и сервера.
    • Логи Audit, хранимые сервером API, стали более настраиваемыми и расширяемыми с поддержкой фильтрации событий и webbooks, а также стали предоставлять больше данных для аудита системы.

    Поддержка stateful-приложений


    • Бета-версия функции автоматических обновлений StatefulSet, используемых для деплоя stateful-приложений. Стратегия обновлений определяется полем spec.updateStrategy, поддерживающим сейчас два значения: OnDelete и RollingUpdate.
    • Поддержка в StatefulSets более быстрого масштабирования и запуска приложений, не требующих строгой очередности, настраиваемой теперь через Pod Management Policy. Такие приложения теперь могут запускаться параллельно и без ожидания получения подом определённых статусов (Running, Ready).
    • Альфа-версия локального хранилища (Local Storage): в StorageClasses внутри StatefulSets теперь можно получить доступ к локальному хранилищу через стандартный интерфейс PVC/PV.
    • Умный откат (и история изменений) при обновлениях DaemonSets.
    • Новый плагин StorageOS Volume, реализующий постоянные томы хранения высокой доступности во всём кластере (из локального или подключённого к узлу хранилища).

    Расширяемость


    • Агрегация API позволяет расширять возможности Kubernetes собственными API. Прослойка агрегации работает вместе с kube-apiserver и ничего не делает, пока не зарегистрирован ни один ресурс для расширения API. Регистрация API выполняется через объект APIService, который реализуется через extension-apiserver внутри пода, работающего в кластере Kubernetes.
    • В Container Runtime Interface (CRI) добавлены новые RPC-вызовы для получения метрик контейнера. Добавлена альфа-версия интеграции с containerd, поддерживающая базовый жизненный цикл пода и управления образами.

    Другое


    • Альфа-версия поддержки внешних контроллеров Dynamic Admission, позволяющих добавлять API-серверу бизнес-логику при модификации объектов.
    • Альфа-версия Policy-based Federated Resource Placement, что позволяет определять основанные на политиках решения по федеративным ресурсам (с использованием внешнего движка политик, например, основываясь на требованиях к цене или производительности).
    • На смену Third Party Resource (TPR) пришли Custom Resource Definitions (CRD), которые предлагают «более ясный API» и решают ряд проблем, зафиксированных во время бета-тестирования TPR. Полностью TPR будут убраны в Kubernetes 1.8 (доступно руководство по миграции).
    Флант
    349,00
    Специалисты по DevOps и высоким нагрузкам в вебе
    Поддержать автора
    Поделиться публикацией

    Комментарии 12

    • НЛО прилетело и опубликовало эту надпись здесь
        +2
        Главной фичей релиза стала поддержка многоэтапных сборок (multi-stage builds)
        multi-stage build support появилась в v17.05.0-ce
          +1
          Спасибо, исправил в тексте на: «Главной фичей релиза стала официальная стабилизация поддержки многоэтапных сборок (multi-stage builds), впервые представленных в Docker 17.05.0».
            0
            Судя по ишью на гитхабе — ничего стабильного там не добавилось :)
              0
              Ну, по крайней мере, добавилась уверенность разработчиков, что всем можно это использовать ;-)
          +1
          В Docker добавили цепочку DOCKER-USER в iptables, которая вставляется первой в FORWARD и не сбрасывается.
          Т. е. теперь можно закрыть доступ к опубликованному через Docker порту для конкретного интерфейса/IP, или наоборот.
            0
            Спасибо. Читал об этом в комментариях opennet'а, но не увидел конкретной записи в release notes, поэтому написать забыл. Если правильно всё понял, было частью node-local в Swarm (#32981 в Moby) (#1675 в libnetwork).
            0
            Я вот кстати не понял, почему они в примере с multi-stage build в финальном образе используют java:8-jdk-alpine, а не java:8-jre-alpine, вроде для запуска jar достаточно обычного jre. Ведь они описывают эту фичу как возможность максимально минимизировать финальный образ.
              +3
              Вполне возможно что пример писал вообще человек без навыков java :) А golang постеснялись — итак везде он…
              0
              Любопытный вопрос: судя по доке Kubernetes, они тестируют свой продукт с Docker версии примерно 1.12, но не старше. У вас какой опыт, есть ли смысл столь «изменчивый» продукт, как Docker, с Kubernetes использовать свежую со свежей версиями? Потому что новость написана сразу об обновлениях этих двух продуктов, но есть ли положительный опыт использования свежего Docker (желательно 17.06) совместно со свежим Kubernetes (желательно 1.7)?
                0

                У текущего kubernetes'а бывают проблемы с новыми версиями докера (которые после смены версионирования). Как минимум, kubeadm при бутстрапе повисал, если на хосте, скажем 17.06, а на 1.12 и 1.13 раскатывал kubernetes без проблем.

                  0
                  По данным коллег, из живых инсталляций с Docker 17 у нас только Kubernetes 1.6.1. А с Kubernetes 1.7 нашёлся только Docker 1.12.6. Обе связки рабочие.

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

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