Контейнеризация

Главные фичи Kubernetes на платформе MCS

• Интерфейс управления для создания кластера в несколько кликов, масштабирования и настройки.
• Автоматическое масштабирование узлов кластера в большую или меньшую сторону, то есть добавление или удаление нод (Cluster Autoscaler).
• Встроенный мониторинг на основе Prometheus Operator и Grafana. Многие наши пользователи начинают с базовых инсталляций, где запускается приложение. Когда оно выходит в продуктив, это позволяет им мониторить сервисы и сам кластер.
• Свой Terraform-провайдер для Kubernetes. Он полностью поддерживает API MCS.
• Интеграция с Docker Registry для хранения и управления образами.
• Автоматизированное развёртывание федеративных кластеров Kubernetes на базе AWS и Mail.ru Cloud Solutions (о чём мы писали тут).
• Возможность сделать Start/Stop для кластера целиком экономия для тестовых сред. Вы можете выключить кластер одним кликом в интерфейсе и платить только за диски в случае остановленных кластеров.
• Поддержка создания Node Pools, пулов виртуальных машин разных размеров: можно запускать тяжелые задачи на больших машинах, веб-приложения на маленьких. Масштабировать группы можно независимо и размещать их в разных регионах либо зонах доступности (для большей надежности и доступности).
• Persistent Volumes интегрированы с системой хранения OpenStack.
• Поддержка приватных кластеров, доступных только через VPN-соединение.
• Поддерживается Cluster Policy: Local, которая позволяет получать реальные IP пользователей внутри кластеров.
• Создание и масштабирование кластеров Kubernetes с помощью UI или API MCS, управление сущностями через Kubernetes dashboard и kubectl.
• Плавное обновление (rolling update) в один клик без простоя как для минорных, так и для мажорных версий. Обновления кластеров до 1.16.
• На момент написания статьи мы поддерживаем Kubernetes вплоть до версии 1.17.

• CI/CD aaS, интегрированный с Kubernetes и другими сервисами платформы: дополнительные сервисы, которые обеспечивают CI/CD, на базе наших собственных доработок OpenStack.
• Логирование aaS для приложений приложений, которые работают в нашем Kubernetes. Логирование будет реализовано на базе нескольких решений OpenStack.
• Service mesh: у нас появятся плагины для Kubernetes, которые в рамках реализации service mesh будут выполнять шифрование, бэкапирование и другие функции.

Сертификация дистрибутива в Cloud Native Computing Foundation

Место Kubernetes в инфраструктуре облачной платформы

Какие инструменты мы используем

1. Операционная система. Сначала мы использовали CoreOS, которая работает на хостах, сейчас у нас Fedora Atomic (1.14-1.15) и CentOS (1.16).
2. Сеть Calico. Сети Kubernetes зависят от облачной сети, которая обеспечивается SDN всего облака. В основе нашей SDN изначально был OpenStack Neutron. Но год назад мы начали разработку модуля Sprut нашего собственного SDN-решения, которое поддерживает API Neutron, но работает по другим принципам. Подход Sprut решил наши проблемы масштабируемости, возникающие из-за десятков тысяч сетевых сущностей (портов) у нас в облаке, когда при падении сетевых нод в сети такого размера начинался процесс полной синхронизации (fullsync). Сейчас Sprut мы задействуем для тех клиентов, для которых в силу особенностей нагрузки на сеть использовать его целесообразнее, чем Calico, в перспективе мы его откроем для всех.
3. Кластерный DNS на базе CoreDNS, со всеми его Service Discovery, метриками Prometheus и другими стандартными фичами.
4. Ingress Controller. Сейчас это Nginx, но мы также планируем добавить Envoy, как дополнительный Ingress Controller. Наши тесты показывают, что Envoy часто быстрее. Ingress Controller интегрирован с облачным балансировщиком нагрузки на базе OpenStack Octavia и поддерживает Proxy Protocol.
5. Мониторинг на базе Prometheus Operator. Раньше использовали просто Prometheus, но сейчас все хотят автоматизацию и сервис-мониторы, поэтому мы уже несколько месяцев предлагаем Prometheus Operator + Grafana, в рамках которой можно добавлять сервис-мониторы и выполнять мониторинг кластеров.
6. Аддоны (опциональные расширения). В один клик можно установить Docker registry, интегрированный с нашим S3-хранилищем, ingress controller, различные системы мониторинга (Heapster, Prometheus).

Multi Master и сетевая топология

Доступ к кластеру Kubernetes из публичной сети: запуск трафика и балансировка нагрузки

apiVersion: v1kind: Servicemetadata:name: nginxlabels:  k8s-app: nginx-backend annotations:  service.beta.kubernetes.io/openstack-internal-load-balancer:"true"spec: type: LoadBalancer externalTrafficPolicy: Cluster selector:  k8-app: nginx-backend ports: -port: 80  name: http  targetPort: http -port: 443  name: https  targetPort: httpn

Storage и Kubernetes

kind: PersistentVolumeClaimapiVersion: v1metadata: name: nginx-pvc-ssdspec: accessModes: -ReadWriteOnce storageClassName: dp1-ssdresources: requests:  storage: 30Gi

Автоматическое масштабирование

• Cluster Autoscaler позволяет расширять сами выделенные для кластера ресурсы. По сути он может автоматически арендовать дополнительные ресурсы или сократить их использование через Cloud Provider.
• Horizontal Pod Autoscaler позволяет расширять ресурсы подов в рамках существующих выделенных ресурсов кластера, чтобы оптимально их использовать.

Функциональности

Совместимость со стандартными инструментами Kubernetes

• Хранение и обработка serverless-функций в контейнерах: OpenFaaS, OpenWhisk, Kubeless.
• Инструменты Service Mesh: Istio, Consul, Linkerd.
• Мониторинг, аналитика, логирование: Prometheus, Fluentd, Jaeger, OpenTracing.
• CI/CD: Gitlab, CircleCI, Travis CI.
• IaC (описание приложений): Terraform, Helm.

• листинг ресурсов MCS (cluster, cluster template, node group)
• поддержку managed node groups
• поддержку действий через API: создание/удаление, горизонтальное и вертикальное масштабирование, включение/выключение кластера, обновление версии.

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

• Kubernetes использует аутентификацию по сертификатам.
• Систему безопасности кластеров можно интегрировать с LDAP/Active Directory для аутентификации пользователей. При этом ролевую модель безопасности в Kubernetes можно настроить на проверку прав доступа на основе принадлежности пользователя к группам в LDAP-каталоге.
• Для сетевой безопасности можно применять Calico Network Policy.
• В наш Kubernetes aaS интегрирован Docker Registry, защищённый SSL.
• Планируем реализовать SSO (single sign-on) в интеграции с нашим IAM (identity and access management) на уровне OpenStack.

Резервное копирование и миграция

• Мы поддерживаем интеграцию с Velero. Velero выполняет резервное копирование, которое позволяет бэкапить манифесты etcd и Persistent Volumes, вот гайд по тому, как это сделать.
• Также с помощью Velero можно мигрировать кластеры on-premises и других провайдеров на наш Kubernetes.
• Или запросите миграцию на наш Kubernetes под ключ. Поможем.

Работа с большими данными

• Автомасштабирование позволяет выдерживать большие вычислительные нагрузки.
• Можно создавать событийные (event-triggered) обработчики данных.
• Приложения на Kubernetes легко интегрировать с другими нашими PaaS для Big Data, машинного обучения, в рамках одной сети.
• Если хочется поэкспериментировать, то для ускорения обучения к очереди событий или событийному обработчику на базе Kubernetes можно напрямую подключить GPU.

Ещё о нашем Kubernetes aaS

1. Попробовать бесплатно наш Kubernetes aaS можно тут.
2. В этих двух Telegram-каналах вас ждут новости нашего Kubernetes aaS и анонсы мероприятий @Kubernetes meetup.

Чем контейнеры отличаются от виртуальных машин, почему Docker настолько популярен, что такое Kubernetes и в чём его преимущества и недостатки. В интервью АйТиБороде СТО Слёрма Марсель Ибраев и старший инженер Southbridge Николай Месропян рассказали о контейнеризации понятным языком. Мы перевели интервью в текст для тех, кому лень смотреть.
Мне не лень смотреть, мне лень читать

Разница между контейнеризацией и виртуализацией

Что такое виртуализация?

Виртуализация появилась как средство уплотнения окружений на одном и том же железе. Сначала программный продукт выполнялся на железном сервере. Потом, чтобы иметь возможность поселять в одно и то же железо больше клиентов, чтобы максимально полно утилизировать производительные мощности, придумали виртуализацию. Теперь на одном и том же железе можно держать несколько окружений. В зависимости от среды, опять же. Есть полностью проприетарные решения, такие как vmware vsphere, есть опенсорсные решения, как QEMU KVM, на основе которого Red Hat делает свой коммерческий гипервизор Red Hat Virtualization. На платформе Windows есть Hyper-V.

Благодаря виртуализации мы получаем возможность более полно утилизировать ресурсы железа. Но при этом речь идёт о полной изоляции: в виртуальной машине полностью изолированное ядро, все библиотеки, строго ограниченные ресурсы по процессору и памяти.

Ядра разделяются физически или можно виртуально разделить там одно физическое ядро на несколько при виртуализации?

Если у вас на хосте один процессор, то в виртуальной машине вы два иметь не можете. Ресурсы хоста можно делить произвольным образом между всеми виртуальными машинами. Либо статично, выделяя под конкретную виртуальную машину один, два, три процессора. Либо динамически, чтобы использовались просто свободные ресурсы в нужное время.

Что такое контейнеры и контейнеризация, и чем отличаются?

Детали зависят от операционной системы, на которой выполняется контейнер, но вообще контейнер делит с хостом ядро, пространство памяти ядра, и своё у контейнера только пользовательское окружение. Первая широко распространенная технология контейнеризации в Linux это OpenVZ, которая потом превратилась в коммерческий продукт Virtuozzo. Мы много работали и работаем с OpenVZ. У нас клиентские окружения жили в контейнерах OpenVZ, пока мы не перешли на более современные технологии.

То есть контейнер от виртуальной машины отличается только тем, что в контейнере общее адресное пространство?

Нет. Виртуальная машина изолируется полностью средствами процессора (технологии Intel, AMD, VMX).

Контейнер работает на ядре хостовой операционной системы и использует для изоляции возможности не железа, а операционной системы, так называемое пространство имён. Если мы говорим о Docker, как о наиболее распространённой сейчас технологии виртуализации, используются так называемые cgroups в ядре Linux.

Контейнер это продолжение виртуализации? То есть это технология, которая является преемником виртуализации?

Нет. Они ни в коем случае не конкурируют. Они занимают совершенно разные ниши в использовании.

Тогда почему их постоянно сравнивают? И постоянно есть вопрос, что лучше виртуализация или контейнеризация?

С моей точки зрения сравнить контейнеризацию и виртуализацию нельзя. Это сравнение теплого с мягким.

Где лучше использовать виртуализацию, а где контейнеризацию? Для как разработчика нет разницы: и то, и то используется для развертывания приложений. Два-три приложения ты фигачишь контейнером. Ты можешь виртуальных машин столько создать, и в каждой из них запустить своё приложение. В чем разница для обычных девелоперов?

Для тебя виртуальная машина это обычная изолированная операционная система, целиком: своё ядро, свой init, systemd и так далее. Чем она отличается от контейнера с точки зрения потребления ресурсов? Тем, что она полностью занимает все ресурсы, под неё выделенные. То есть, есть механизмы, когда можно динамически, то есть в зависимости от потребления процессами внутри виртуальной машины, освобождать память на хосте или занимать её. Но это всё полумеры.

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

Если мы говорим о Docker (а в рамках разговора мы не сможем обсудить все варианты контейнеризации), то он рассчитан на то, что в одном контейнере работает одно приложение.

Возвращаясь к твоему первому вопросу, разница вот в чём. Допустим, если у тебя на хосте Linux или VMware, то виртуальная машина у тебя может быть Windows. Если у тебя в контейнере Linux, то у тебя и снаружи Linux. Потому что мы в первую очередь пользуемся для изоляции не средствами железа, не средствами гипервизора, а средствами операционной системы cgroups и namespace.

Почему контейнеры разворачиваются быстрее? Потому что они маленькие, содержат в себе там одно приложение? Почему быстрее развернуть контейнер, нежели зафигачить, законфигурировать?

Виртуалка сама по себе большая, так как содержит целую операционную систему. Если нам нужно развернуть виртуальную машину, то нужно нести с собой и ядро, и всё пользовательское окружение, и какой-то запас места (потому что динамически оно с хостом шариться в общем случае не может). Я не видел линуксовую виртуальную машину весом меньше 10 Гб, и это без данных. Потом к ней еще нужно прицепить диски для данных, в зависимости от того, что будет внутри.

Если говорить о контейнерах, есть разные дистрибутивы, в том числе специально созданные для контейнеризации, тот же Alpine Linux, который в голом виде весит 20 или 50 Мб в зависимости от версии. То есть ничего не весит, собственно говоря.

Виртуалка тянет полностью всю операционку, а когда Docker создаешь, ты тянешь только какие-то небольшие пакеты?

Нет. Чтобы создать Docker-контейнер ты должен собрать образ. Ты берёшь какой-то базовый образ, тот же Alpine, CentOS или Ubuntu. В него с помощью специальных команд зашиваешь свое приложение и выгружаешь уже туда, где оно будет работать.

То есть все равно ты в контейнере используешь полноценную операционку? Вот тот же образ Alpine Linux.

Она может быть сильно порезаной по сравнению с операционной системой, которую ты засовываешь в виртуальную машину.

Но потенциально ты можешь и полноценный Linux запустить в контейнере?

Потенциально да, можешь.

Но смысла в этом, наверное, нет.

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

Один контейнер? А это не слишком жирно использовать для одного приложения, ну пусть и урезанную, но операционную систему?

Когда нужна изоляция это не слишком жирно.

Понял. Есть ли какие-то еще инструменты, которые позволяют сделать что-то похожее на контейнеризацию, но не контейнеризация?

Контейнеризация сама по себе использует механизмы изоляции, которые предоставляет ядро. Если делать что-то другое, то это тоже получится контейнеризация.

Почему Docker захватил весь рынок? Вот ты говорил, что было решение какое-то изначально в Linux?

Нет. Оно занимало и занимает совершенно другую нишу. Docker захватил весь рынок в первую очередь потому, что он первым начал использовать технологии namespace и cgroups для, так сказать, народа. Понизил порог вхождения в эти технологии до того, чтобы можно было выйти на широкий рынок, на широкого пользователя.

Docker предоставляет общий интерфейс через фактически одну команду к массе возможностей. То есть из единого командного интерфейса мы управляем всеми нюансами создания контейнеров, их запуска, монтирования томов в них, запуска процессов у них всё что угодно.

А как тут обстоит дело с дебагом твоего кода, логированием и всем остальным? Со стороны кажется, что это сложновато: нужно залезть внутрь какого-то контейнера, который представляет из себя урезанную операционку

Когда работаешь с контейнерами, в принципе не обязательно думать, что это операционка, не операционка. Там начинается другой мир. Да, к нему надо привыкнуть, но с дебагом, логированием проблем нет никаких, потому что хорошим тоном считается писать все логи в stdout/stderr контейнера, а не в файлики внутри него.

Docker-контейнер знаменит тем, что он одноразовый. Он запустился, а после того, как ты контейнер удаляешь, если ты специально никаких мер не предпринимал, чтобы сохранить в нём данные, у тебя всё удаляется. Поэтому все логи обычно пишут в stdout/stderr, средствами Docker или внешних утилит экспортируют их в ElasticSearch, ClickHouse или какие-то другие системы хранения логов и централизованно уже с ними работают. В первую очередь потому, что контейнеров много. Контейнеров в сетапах могут быть десятки, сотни, тысячи и десятки тысяч.

Как правило, они весьма короткоживущие. Если мы сетапим железные сервер или виртуалку, они могут работать годами, то контейнер живёт до обновления образа максимум. Поэтому контейнеров много, они сравнительно короткоживущие, эфемерные, непостоянные. И поэтому всё, что нужно хранить вне них, нужно хранить специальными методами.

Что насчет контейнеризации в Windows? Насколько я помню, там если не всё очень плохо, то не всё так просто, как на Linux.

Там, действительно, очень сложно. Я ни в коем случае не Windows-админ, знаком поверхностно. Но насколько я знаю, нативная контейнеризация в Windows есть. Есть средства изоляции и по ресурсам, и по пространствам имен, сетевые пространства имен, для памяти, под файлы и так далее. То есть можно Windows запустить как контейнер Windows. Это Windows Server Containerization, если я не ошибаюсь (Windows-админы, не обессудьте).

Но если мы говорим о том, чтобы запускать Docker в Windows, то здесь начинаются пляски. Docker это технология Linux, потому что использует специфические средства для изоляции, для создания контейнеров.

Когда контейнер выполняется, он не представляет собой некий образ. Когда выполняется виртуальная машина это образ, внутри которого своя файловая система, свои разделы, где всё это нарезано и всё это варится. Когда выполняется контейнер, для операционной системы это просто набор ограничений. Когда мы смотрим на процесс виртуальной машины с хоста, мы видим один процесс. В винде это Microsoft Hyper-V, в Linux это QEMU KVM, в vSphere это тоже один процесс. Когда мы смотрим с хоста на контейнер, то видим дерево процессов.

Но почему мы образы передаем друг другу? Я приложение запаковываю в Docker, и мы девелоперы передаём друг другу образы.

Образ это то, из чего контейнер запускается. А с точки зрения хоста это дерево процессов, которые ограничены через встроенные средства ограничения, то есть через namespace и cgroups. Это я к тому, что Docker по своей сути линуксовый.

А почему нельзя было сделать универсальное решение, чтобы оно и для Linux, и для винды работала? Там нет общих API или в Linux есть что-то, чего нет

Ядро-то разное.

Архитектура разная, да?

Да, API Windows и API Linux это совершенно разные вещи. По той же причине нет нативного Docker для macOS. Потому что используются средства изоляции линуксового ядра.

Я думал, что ядра macOS и Linux очень похожи.

Нет. macOS больше UNIX-like, нежели Linux. Потому что, как известно GNU is not UNIX (рекурсивный акроним). А macOS внутри более, так сказать, близка к юниксам. И там нет таких механизмов, как в Linux. Они развиваются независимо.

Docker и для Windows, и для macOS это чужеродное тело, которое запускается в линуксовой виртуалке.

Получается, чтобы запустить контейнер, нужно запустить еще и виртуалку?

Мы запускаем линуксовую виртуалку, а уже в ней мы уже запускаем эти контейнеры. Docker Desktop скрывает от пользователя все сложные процессы, но внутри все равно остаются всякие. Ну не то, чтобы это очень неэффективно. Если вам нужно разрабатывать что-то под Docker, но у вас только Windows или только macOS, то это позволяет работать, да. Но в продакшене с нагрузками так ничего толком не запустишь.

Я понял, что ты в основном с Linux работаешь, но вдруг ты слышал про WSL (Windows Subsystem for Linux)?

Разумеется, я на OpenNET читаю об этом всём и удивляюсь.

А может ли эта штука запустить контейнеры нативно? Я просто не знаю, она тоже под виртуалкой?

Насколько я понимаю, WSL это Wine наоборот. То есть трансляция вызовов API в нативные для винды. Если у нас Wine это трансляция вызовов виндового API для ядра Linux, то WSL это наоборот. И поэтому средств изоляции там ядерных линуксовых нет. Поэтому увы, увы.

Про оркестрацию

Скажем, у нас микросервисная архитектура, и не одно приложение, а много всего: 10, 20, 40, 100 микросервисов. Руками их конфигурировать совсем не прикольно. Как с этим разбираются?

Да, это вполне типовая ситуация. Сейчас особенно, потому что стильно, модно, молодежно. Постепенно приложение обрастает логикой, микросервисов становится больше и больше. И одного Docker, и даже Docker Compose уже становится мало. Ну и плюс ко всему, наверное, еще хочется какую-то отказоустойчивость, чтобы это на нескольких серверах работало. Возможно, какой-то Service Discovery и прочее.

Постепенно компания утыкается в потолок, когда им нужно свежее и очень продуктивное решение. И здесь, конечно, нужен оркестратор контейнеров. То есть такой тип программного обеспечения, который управляет всеми микросервисами, смотрит за ними, чинит, переносит с машины на машину, строит сеть и в целом является такой входной точкой во всю инфраструктуру проекта.

Марсель Ибраев, СТО Слёрм

Docker Compose не позволяет нам ничего делать? Ведь это тоже средство управления несколькими контейнерами.

Docker Compose, как минимум, не позволяет запускать проект на нескольких серверах. То есть это все равно все-таки история про одну ноду. Поэтому, да.

ОК. Что придумано? Что есть сейчас, чтобы это все делать?

Сразу нужно сказать, что инфраструктурный стандарт это всё-таки Kubernetes. Штука, которая в свое время была произведена в Google. И Google по зову сердца, по доброте своей решил поделиться с миром.

Есть ещё ряд решений, например, Docker Swarm, Mesos, OpenShift и другие, но всё-таки наиболее популярен и пользуется спросом Kubernetes. Компании, которые задумываются о том, что им нужен оркестратор, в первую очередь смотрят на Kubernetes.

Где обычно применяются оркестраторы, в частности Kubernetes?

Да, это очень важный вопрос. Дело в том, что Kubernetes все проблемы не решает. Компания работает, работает, у них всё плохо (как правило, плохо с процессами) они такие: Блин, Kubernetes классная штука. Давайте её себе поставим у нас всё сразу станет хорошо! Но становится сильно хуже.

К Kubernetes нужно подходить уже осознанно. Работу с Kubernetes стоит рассматривать, когда у вас действительно большое количество микросервисов, когда есть определённые требования к уровню доступности вашего сервиса, когда над одной частью приложения трудятся несколько команд, когда нужна инфраструктура для автоматизации деплоя и тестов. На этом этапе да, действительно стоит задуматься о Kubernetes.

Если вы небольшая компания или если у вас монолит, и вы такие: Сейчас мы его в куб засунем и все станет хорошо! Нет, не станет.

Kubernetes работает только с контейнерами Docker и с их оркестрацией?

Kubernetes работает с контейнерами, но не только с Docker. У Kubernetes есть такая штука, которая называется Container Runtime Interface. В принципе, все системы контейнеризации, которые сейчас есть и которые поддерживают Container Runtime Interface, могут работать с Kubernetes. Например, rkt.

Сейчас возникло движение энтузиастов, которые выкорчевывают Docker из Kubernetes и используют что-то другое. Потому что Docker тоже не без проблем. Главная проблема Docker это его демон, который имеет свойство зависать, особенно при большой нагрузке. Но зачем демон, если у нас уже есть Kubernetes, есть достаточно зрелая инфраструктура и нам надо просто какое-то место для запуска контейнеров.

Дополнительный демон по сути не нужен. В эту сторону движение сейчас активно идёт, но, я думаю, дойдёт не быстро. Устоявшееся мнение, что контейнеры равно Docker, будет держаться долго.

А что может быть использовано вместо Docker более оптимальным путем?

Оптимально пока сложно сказать, потому что у конкурентов Docker есть свои минусы. К примеру, containerd не имеет нормального средства управления им. К слову, с версии 1.11, кажется, под капотом Docker containerd и работает. По сути, сейчас Docker выполняет роль обёртки над containerd, а там containerd, а внутри ещё runC, если уж совсем углубляться.

Кто-то говорит про Podman: делайте просто алиас Podman Docker, и можно сразу работать. Но тоже есть свои нюансы, поэтому мы в том числе пока работаем с Docker.

Расскажи подробнее, как вообще Kubernetes работает? Что у него происходит под капотом? Для начала уточним, Kubernetes это сервис или это какое-то ПО, которое можно ставить на сервера, или это и то и то?

Ну это ПО, да. И при этом ПО, которое сейчас очень активно развивается и предоставляется облачными провайдерами как сервис. При этом ничто не мешает его поставить на железные серверы.

Всегда нужно держать в голове, что Kubernetes это в первую очередь оркестратор контейнеров. Когда вы это понимаете, то вы понимаете, для чего он нужен.

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

1. Компоненты друг друга не аффектят. Если один упал, то все остальные могут продолжить работать.
2. Эти компоненты работают по pull-модели. Нет никакого центрального компонента, командира, который всем раздаёт команды, а как сдох, так все не знают что делать. Каждый компонент выполняет свою часть работы: сделал, завершил. Если он умер, ну значит этот кусочек не выполнится.

Теперь по поводу самих компонентов. Основной компонент это API-сервер. Это просто апишка, REST API (разработчики понимают, о чём речь): управление с помощью http-запросов, версионирование кстати тоже. Очень важно, что там есть версия API, при обновлении мы можем на эти версии API завязываться и за счёт этого обновляться менее болезненно. Есть API, с которым работают все: и клиент (мы, как оператор кластера), и компоненты остальные в том числе.

API-сервер работает с хранилищем, которое представляет из себя просто etcd. Etcd это key-value хранилище, то есть ключ-значение. Вот и API-сервер это единственный компонент, который с этим хранилищем взаимодействует.

Это какая-то разработка команды kubernetes?

Нет, это отдельная штука, очень древняя.

А почему её у Redis нет, например?

У Redis есть проблемы с многопоточностью, есть проблемы с кластеризацией (хотя они ее постепенно решают). А etcd штука древняя, все детские болезни там уже вылечены, и она достаточно такая отказоустойчивая.

Кстати, это хороший показатель, что если разработчики Kubernetes уже начиная с первых версий используют etcd, то, наверное, у себя его тоже можно использовать как key-value в кластер-режиме.

API-сервер единственный, кто с etcd работает, он записывает, считывает информацию. А в etcd у нас хранится всё. Там наши настройки кластера, манифесты всё, что мы делаем.

Мы как клиент хотим что-то создать, запустить приложение, и мы эту информацию передаем в API-сервер. Мы непосредственно это не делаем, конечно, там есть такая утилита, которая называется kubectl. С её помощью мы управляем всем кластером, делаем все операции, в том числе и запускаем приложения. Передаем yaml-манифест, где у нас в декларативном формате описано, как должно выглядеть приложение в кластере. Вот мы это передаем. Оно сохраняется в etcd и следующие компоненты постоянно смотрят в API-сервер.

Если немного углубиться, там есть подписка на событие и они по сути watch'ат. То есть никакого DDoS'а самого себя там нет. Следующий компонент, который берёт эту историю в работу это kube-controller-manager. По сути, мозг кластера Kubernetes. В него вшиты множество контроллеров: node-controller, endpoint-controller. Практически у всех абстракций, которые есть в Kubernetes, есть контроллер, и он вшит в этот бинарь. Эти контроллеры занимаются просто контролем вот этой абстракции: смотрят, есть ли новые, нужно ли что-то удалить и так далее.

Давай на примере. Если продолжать говорить о приложении, то контроллер, который отвечает за какое-то конкретное приложение, точнее за его манифест, за его абстракцию он видит, что мы что-то хотим создать, запустить. И он выполняет соответствующую работу, а именно дописывает манифест в etcd, обновляет информацию. Тут, конечно, без некоторого углубления нормально не объяснишь. Но есть такая абстракция, которая называется ReplicaSet. Она позволяет запускать приложение в нескольких инстансах. Через нее мы можем увеличивать, уменьшать количество реплик. И все здорово.

Это балансировка нагрузки?

Это просто контроль за количеством инстансов одного и того же приложения.

А зачем?

Чтобы иметь возможность в случае чего скейлить свое приложение или скейлить обратно. То есть хотим в три инстанса реплики просто пишем три у нас три инстанса.

Ну это очень похоже на балансировку нагрузок.

Балансировкой уже занимается другая абстракция, которая уже трафик распределяет на вот эти три инстанса.

То есть они в принципе могут в паре работать?

Да. Они в паре и работают.

ReplicaSet не только создаёт реплики, она ещё и следит, чтобы их действительно было три. Причем не больше, не меньше.

Инстансы, которые запускает ReplicaSet, называются подами. В подах и работает наше приложение (про поды мы ещё поговорим).

И вот как раз, когда мы создаем, например, ReplicaSet, у нас есть такой ReplicaSet controller в этом контроллер-менеджере, который описание подов для ReplicaSet генерирует, и туда же, грубо говоря, в etcd через API-сервер скидывает.

Потом подключается следующий компонент. После того, как мы поняли, какое приложение нам нужно из скольких инстансов запускать, оно вот в etcd хранится этот манифест. Далее у нас идет такой компонент, который называется scheduler. Его роль достаточно проста. Он решает, на каких серверах это приложение надо запускать. Но делает это не просто так, у него есть свои алгоритмы принятия решения.

Ну в частности, он смотрит на ресурсы, то есть сколько ресурсов на ноде, если мы для этого приложения запрашиваем 1 ГБ ОЗУ, а на ноде только 512 свободны, он туда не отправляет.

Под приложением ты понимаешь Docker-контейнер с приложением?

Да, контейнер.

Контейнер с приложением каким-то.

Да.

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

Это сказывается на стабильности работы системы в целом? Правильно я понимаю, если у нас есть какой-то нестабильный сервак, который может там валиться очень часто, то у него будет меньше очков.

На стабильность он не смотрит. Он смотрит в первую очередь на ресурсы. Какой смысл отправлять приложение на запуск туда, где их недостаточно. Смотрит ещё на priority class это такая штука, с помощью которой мы можем задать приоритет.

Например, в кластере два окружения: продакшн и стейджинг. Конечно, продакшн более важен. И для них мы priority class выставляем высокий. Для стейджинга мы можем поставить поменьше. Когда происходит авария, Kubernetes понимает, что часть серверов отвалилась (за это будет отвечать Node Controller, который контролирует жизнь нод), он принимает решение, что надо те поды, которые там были, запустить в живых серверах. Scheduler будет запускать в первую очередь поды продакшена.

Интересно, что если поды продакшена не лезут, то поды стейджинга будут убиваться и на место их будут запускаться поды продакшена.

А если не хватит под продакшн места?

Если не хватит, ну сорян. Поды будут висеть в pending, то есть ждать, когда появятся ресурсы. И scheduler назначает Если на такой низкий уровень опуститься, то в манифесте пода есть специальное поле, которое называется nodeName имя ноды. И вот пока scheduler не принял решение оно пустое. Scheduler говорит, что вот этот под, вот это приложение нужно запускать там на Node 2, и он эту информацию передает, API-сервер это записывает в etcd и в это поле вносит это имя. А далее в работу вступает последний компонент всей этой схемы, который называется kubelet.

Kubelet это компонент своего рода "node agent", то есть агент, который запущен на всех серверах кластера. Он тоже постоянно в API-сервер смотрит. И он видит, что появился под, то есть приложение, у которого в поле имя сервера написано его имя, там, где он работает. Он такой: Ага! Значит его нужно у себя запустить! Он видит, что у него запущено, и что от него хотят. Он передает Docker API, из манифеста считывает, что там конкретно нужно запустить, и говорит Docker, какой контейнер нужно запустить.

Kubelet, получается, замена Docker демона?

Вот в том то и дело, что не замена, к сожалению. Поэтому вот эти альтернативы и изобретаются, поэтому туда люди идут, потому что Docker демон висит. Но по сути да, он общается с Docker демоном по API, но без него вполне можно было обойтись. Причем он не просто их запускает, он постоянно смотрит за статусом, и статус этот передаёт в API-сервер.

Хелс-чек такой?

В том числе хелс-чек тоже делает Kubelet. И мы постоянно видим, какой статус у наших приложений в реальном времени. Вот то, что там сейчас пулинг образа идёт, что там сейчас она запускается, вот он на раннинг все хорошо, все запустилось. И вот только на этом этапе у нас физический запуск произошёл. То есть всё вот это это подготовка.

Ноды это всегда сервер или это может быть кластер серверов?

Ноды это место, где запущен Kubelet.

Это может быть виртуалка, как я понимаю?

Да, может быть виртуалка.

Ты сказал, что в результате этих действий мы получаем физически развёрнутое приложение. Kubelet посылает какие-то свои статусы, либо он просто stdout контейнера фигачит? К чему этот вопрос. Потому что, если у тебя приложение в stdout выдает логи, какой-то дебаг kubernetes как-то умеет это в одно место собирать и предоставлять в удобочитаемом виде, или это не его обязанность вообще?

В твоем вопросе, два вопроса скрыты. Статус самого контейнера (жив или не жив) берёт из Docker. Функционал приложения (работает ли оно) вот эти дебаг, логи, какие-то хелс-чеки это все тоже делает Kubelet, но для этого надо несколько строчек в манифест добавить и сказать, как именно проверять.

На данный момент поддерживается три возможности проверять приложение:

1. http-get это http-запрос в контейнер на инпоинт, и мы видим, работает оно, не работает, отвечает, не отвечает. С 200 по 399 код это ок, если 301 даже редирект это ок. Если 404 это не ок. 500 тем более.
2. exec мы внутрь контейнера делаем какой-то запрос, какую-то команду, проваливаемся. Например, select 1, проверяем, всё ли нормально с базой.
3. tcp socket Kubelet просто проверяет доступные сокеты. Если все хорошо, то все хорошо.

Есть три типа проверки контейнеров: это liveness, readiness и startup пробы.

Liveness проба это контроль за жизнью приложения. Постоянно Kubelet смотрит, ходит и смотрит. Там гибкие настройки, можно написать, как часто ходить, как проверять и так далее.

Readiness проба проверяет, а готово ли приложение принимать трафик. Потому что разные истории могут быть, это могут быть разные инпоинты у приложения. Мы проверяем, работает ли приложение, готово ли оно принимать трафик.

Startup проба это больше для легаси таких историй, которые очень долго поднимаются, молотятся в самом начале. То есть очень долго инициализируются. И startup проба проверяет, запустилось ли вообще приложение.

На каком размере архитектуры может работать Kubernetes? Может ли он контролировать сразу миллион инстансов?

Насколько я помню из документации, это 5000+, что ли, нод. На одной ноде по умолчанию можно запустить 110 подов, 110 экземпляров приложения.

Под это экземпляр одного и того же приложения? Или могут быть два разных контейнера на одном серваке и это будет два разных пода?

Под это абстракция, в которой запускается приложение. Тут важно понять, что это не какая-то физическая оболочка, не какой-то процесс ещё один, это скорее именно абстракция, с которой работает Kubernetes.

Kubernetes не умеет работать с контейнерами. Мы не можем сказать: заскейль нам вот это приложение в трёх контейнерах. Мы можем только сказать: заскейль нам в трех подах. В поде может быть как один контейнер, так и несколько. То есть мы можем туда запихнуть, например, nginx и php-fpm в связке, и они будут скейлится по два контейнера в связке.

Но тут надо понимать, что хорошая практика засовывать в контейнер неделимые части приложения. Всё-таки, если 2-3 контейнера надо засовывать, то может, стоит ещё поиграться с логикой приложения. Обычно один контейнер засовывают и там есть еще второй, который сам запускается, это pause контейнер, который держит сетевой namespace, чтобы все контейнеры в поде были в одном namespace, и чтобы всё хорошо работало.

Это первая часть беседы. Во второй будет про хранение данных в Kubernetes и про Ansible. Не пропустите!

Вопросы задавал Лекс АйТиБорода iamitbeard

В чём проблема с базами данных и как позаботиться о безопасности в Kubernetes? Как врубиться в Ansible? Ответы на эти и другие вопросы читайте в продолжении интервью Лекса АйТиБороды со старшим инженером Southbridge Николаем Месропяном и СТО Слёрма Марселем Ибраевым.

Прочесть первую часть
Посмотреть интервью целиком

На вопросы отвечает Марсель Ибраев

В чём проблема с базами данных в Kubernetes? Для меня как для разработчика проблем нет: зафигачил базу в Docker-контейнер и работаешь.

Проблемы нет для половины, наверное, комьюнити. Это вообще холиварный вопрос. В чатике kubernetes_ru (официальном чате русскоязычного сообщества Kubernetes) постоянно эти вопросы поднимаются.

А может, Docker не нужен? Зачем мне Docker для базы?

И это тоже. Были даже такие разговоры, что если база данных удовлетворяет 12 факторам, то это обычное приложение, запускайте и всё, 2020 год на дворе. Зачем вы её выносите отдельно, туда-сюда.

Но 12 факторов это не совсем про базу данных, там больше про stateless говорится. У нас все-таки stateful приложение, то есть приложение, которое должно сохранять статус и результат работы. После перезапуска оно этот результат терять не должно, в отличие от stateless.

И вот именно здесь краеугольный камень. Чтобы научить Kubernetes сохранять статус приложения (базы данных, таблички вот это всё), нужно присыпать ещё несколько абстракций сверху: PersistentVolume, PersistentVolumeClaim, StorageClass не буду сильно углубляться. То есть просто нужно иметь в виду, что повышается планка работы с Kubernetes.
Нужен человек, который умеет настраивать кластер этой базы данных. Потому что Kubernetes не важно, что запускается в поде (Pod): stateless приложение или stateful приложение он с ними работает одинаково. Он не соберёт магическим образом кластер баз данных и не будет за ним следить. Вы напишете манифест с тремя инстансами базы данных, Kubernetes его запустит, и это будет три отдельных инстанса базы данных, которые будут не в кластере.

Но с приложениями он умеет это делать?

Тоже нет. По факту это как бы отдельные инстансы, отдельные реплики приложения. Они по идее самостоятельные.

То есть на уровне записи и чтения данных всё равно нужно будет абстракцию какую-то свою клепать, Kubernetes ни при чём?

Да, и поэтому здесь нужны компетенции какого-то DBA, который на монолитах это уже 1000 раз настраивал, и скажет: Да, без проблем! Настроим!.

Следующий вопрос возникает с запуском базы данных, когда нам нужно выставить request/limit. Request/limit это инструмент, который позволяет работать с ресурсами.

Request это запрос на ресурсы. Например, мы знаем, что этому приложению минимально нужно 200 МБ ОЗУ. Если будет меньше, оно просто крашнется и не запустится. Мы выставляем request 200.

limit максимальная планка. Мы говорим, что 512 максимум, а если выше, то оно явно потекло и надо с ним что-то делать.

А вот как это сделать для базы данных хрен его поймёшь! В понедельник мы работаем на типовой нагрузке, в пятницу пришла баба Люда из бухгалтерии и запустила выгрузку из 1С миллиона строк, и нагрузка в потолок.

На моей истории было дважды, когда приложение (не база данных, для базы данных это будет суперкритично) начало утилизировать очень много ресурсов, и на сервере ресурсов не хватило всё померло. Kubernetes умный, он всё понял: взял и перетащил это приложение на другой сервер, но потреблять много ресурсов оно не перестало. Новый сервер упал, и как домино всё сложилось. Может повезти, что это всё в цикл замкнётся и будет переезжать, но ничего хорошего всё равно не будет. А с базой данных это критично, потому что вам нужно сохранять свои данные.

Есть 4 способа, как это сделать:

1. очень стабильно, но дорого,
2. не очень производительно, но дёшево,
3. более или менее по производительности, но без гарантии,
4. и дёшево, и круто.

Очень стабильно, но дорого это когда мы покупаем энтерпрайз, какую-нибудь железку с поддержкой. Там стоит такая бандура, SaaS всякие, и все работает. Здорово, но не у всех есть такие возможности.

Не очень производительно, но дёшево это использование облачных сервисов, которые предоставляют диски. Но здесь нужно понимать, что у многих есть в инструкции (в том числе и в документации баз данных) такая сноска: Ребята, если вы будете использовать какие-нибудь диски Google или Digital Ocean, например, то поставьте галочку using local SSD, чтобы использовать локальные диски, а не какие-то там через сеть, и вот тогда всё с базой данных будет OK.

Более-менее по производительности, но без гарантии (этот вариант нативно поддерживает Kubernetes) это когда мы просто берём, грубо говоря, прокидываем диск сервера в контейнер. Мапим папочку прям. У нас на сервере могут быть SSD, и мы SSD внутрь контейнера и получаем. Минус в том, что мы тем самым прибиваем базу данных к этому серверу. Спрашивается, зачем мы запускаем её в Kubernetes, если что случись, она там и сдохнет. Ну и лежала бы на своём монолитовском сервере.

И дёшево, и круто это собственная СХД, которую построил и поддерживает какой-то бородатый админ. При этом он ещё должен вывести уровень производительности этой СХД на такой уровень, чтобы она сравнялась как-то с SSD. Первое, что приходит в голову, это Ceph. Но пока мы делали курс по Ceph, пообщались с теми, кто много с этой технологией работает, они сказали: Не, чувак, там столько костылей, что это всё равно придётся закрывать мощностями оборудования. То есть такого нет.

Вот такие варианты: даже не 2 стула, а 4 выбирай, куда садиться. Если у вас возникает вопрос: Могу ли я запустить базу данных в Kubernetes?, значит, конкретно вы не можете пока.

В Kubernetes есть чарты (charts) и хельм (Helm), что это такое?

Сначала расскажу, как возникла потребность в их создании. Вот у нас есть кластер, всё хорошо, но мы его поднимали не просто так, а чтобы запустить приложение.

Приложение может состоять из множества микросервисов, которые надо как-то деплоить в кластер. Конечно, мы можем каждый раз править манифесты руками. Но одно приложение может содержать от пяти и до бесконечности манифестов.

Манифесты это yaml-файлики, которые отвечают за самые разные абстракции. В том числе сам под (Pod), хотя это будет не под, а абстракция, которая называется либо Deployment (именно в ней запускают приложение), либо StatefulSet (если это stateful-приложение), либо DaemonSet, ну неважно. К нему добавляется абстракция типа Service внутренний кубернетский балансировщик. К нему же добавится абстракция Ingress внешний балансировщик. Там же ещё могут быть PV/PVC короче, много всего.

Когда мы приложение разрабатываем, нам надо сделать какой-то релиз. Что-то поменялось в приложении, что-то поменяться могло в манифестах. Например, версия image была 2, стала 3. Нам придётся каждый раз ходить в репы и менять руками 2 на 3. Таких реп может быть сотни, и осталось только не забыть везде нужное поменять. В этот момент типичный админ задумывается об инструментах, которые позволяют менять все файлы внутри папки с одного паттерна на другой. И в принципе, это будет работать.

Только проблема в том, что это решение kubectl based, то есть всё равно весь вот этот вывод, который мы в папке перелопатили, мы через пайп отправляем в kubectl. Говорим: kubectl, вот теперь всё, что у нас есть новое в папке, отправляй в кластер. И это тоже будет работать. Но если что-то пойдёт не так (циферку не ту поставили или приложение просто не поднялось), нативного способа откатиться через kubectl нет. Там есть команда kubectl rollout undo, но она работает только с deployment, а у нас могут быть и другие абстракции, с которыми она не работает. И тут возникает вопрос, а как откатываться? Потому что шаблонизация вроде более-менее понятна, да и шаблонизаторов много всяких (и Kustomize, и json.net), но как откатываться большой вопрос.

Явный ответ на это дает Helm, потому что у него из коробки есть возможность cделать rollout, то есть откат, в случае, если какие-то есть проблемы. Работает он достаточно просто. Он все манифесты из папки, что мы нагенирировали, сохраняет в артефакт. Например, в config какой-то. Прям вот как оно есть, так и сохраняет подряд. Назвал его артефакт версия 1, сохранил в кластер. Потом мы выпустили новый релиз. Он ага, артефакт версия 2. И вот так они копятся. Потом мы выкатили новый релиз, какой-нибудь версии 9, и поняли, что это не то. Он говорит: Ок, у меня есть версия 8, достает все манифесты оттуда и фигачит в кластер.

Возвращаясь к вопросу, как вменять всё, когда этих манифестов становится за сотню и просто невозможно в голове удержать, что где поменять. Тогда на помощь приходят шаблонизаторы, темплейтирование и Helm это тоже умеет. Набор темплейтированных манифестов называется Chart.

Ты уже не раз говорил про stateful и stateless приложения. Разработчикам эти термины знакомы. И понятно, что со stateless просто: развернул и не паришься. Есть какие-то особенности разворачивания stateful приложений? И что для этого используется внутри Kubernetes? Какие-то может быть особенные штуки для хранения состояния приложения? Как оно хранится? Где оно хранится?

Сам по себе Kubernetes никакого решения не предоставляет. Нет внутренней системы хранения данных. В любом случае нужно использовать стороннее решение. Сейчас появился CSI Driver, и стало проще.

CSI Driver это ещё один интерфейс, который позволяет унифицировать подключение внешних инструментов. Как есть Container Runtime Interface, который не только Docker может подключить, но всё, что CRI поддерживает, так и CSI может подключить всё, что его поддерживает. Технология не так давно вышла в прод, развивается и допиливается, но в целом это хороший шаг. Остаётся подключить, например, Ceph как систему хранения данных и через абстракции Kubernetes запрашивать диски или файловые системы в этой СХД и подключать себе. То есть по сути приложение будет работать с этой СХД, а Kubernetes будет в роли посредника.

А до появления этого механизма в Kubernetes нельзя было разворачивать stateful приложения?

Можно было. Есть такая штука, как storage class. Это ещё одна абстракция, и там это всё настраивается. Скажем так, объём тех решений, которые можно применять в Kubernetes, будет расти. Уже есть всякие облачные хранилища, которые можно подключать, и множество всего другого.

Как построен механизм безопасности всего процесса поднятия, слежения за твоими приложениями? Общение наверняка ведётся по https, но есть ли ещё что-нибудь? Что, например, будет, если API Kubernetes завладеет злоумышленник? Как этого избежать?

Не открывать API наружу! Достаточно просто.

А как не открывать? Выстраивать приватную сеть?

Ну да, VPN, двухфакторная авторизация что-нибудь такое. API нужно закрывать очень хорошо, потому что каждый год находят уязвимости. В 2018 году, например, обнаружили критическую уязвимость с индексом 9,8, если я не путаю. Она позволяла поднять привилегии в API, и всё делай, что хочешь. Были уязвимости в 2019 году. Мне запомнилась возможность подменять файлы на хосте через контейнер.

И всё это можно сделать, если авторизоваться в API. Естественно, API не дураки писали, и там есть аутентификация, тот же самый TLS, просто так ничего не сделаешь. Но уязвимости бывают, поэтому API надо всеми возможными способами закрывать.

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

Например?

Глобально можно посмотреть в первую очередь как раз с точки зрения уязвимостей, получения прав и так далее. Решение закрытие API. Если Kubernetes развёрнут не в облаках, а на своих виртуалках, то надо регулярно обновлять свои сервера. Про iptables и SSH наружу, я думаю, говорить не надо. Это общие и достаточно банальные требования, но их надо выполнять. Kubernetes не панацея, это дополнительный слой абстракции. Сверху намазали, и за этим теперь тоже надо как-то следить.

Второй аспект безопасности это уровень привилегий пользователей. В Kubernetes это хорошо сделано. Есть так называемый Role Based Access Control или RBAC сокращенно. Мы можем разграничить пользователей по тому, какие действия им доступны: ты можешь работать только здесь, а ты только здесь. Но там есть достаточно простые хаки, которые позволяют это всё очень легко обойти.

Например, в Kubernetes есть namespace пространство имен. Условно, у нас есть Kubernetes, есть два namespace: стейджинг и продакшн. В стейджинг мы пускаем разработчиков, они там работают, но мы им не даем что-то править на проде. В прод ходит только CI/CD. Но просто имея возможность запускать свои приложения хоть где и ничего больше, я могу за 2 минуты стать админом кластера. Я запущу под (Pod), которого отправлю на запуск на master, где у нас находятся все доступы и креды, и подмонтирую их себе в контейнер. Потом я посмотрю токены, скопирую себе на компьютер и стану админом.

Это такая штука, о которой не все задумываются. Но эту штуку тоже уже прикрыли. Есть инструмент Pod security policy, который позволяет чётко сказать, какие поды и где и как могут запускаться, какие порты могут использовать.

Ещё один аспект безопасности касается работы нескольких команд в Kubernetes. Особенно, если есть на аутсорсе команды, которые пишут свою часть приложения. По умолчанию, любой человек с доступом в namespace может постучаться во все эндпоинты (endpoints), которые есть. Прикрыть это позволяет Network policies. Это своего рода firewall внутри кластера. Когда мы внешнюю команду к себе зовём, мы спрашиваем, к каким эндпоинтам она должна иметь доступ, чтобы взаимодействовать с приложением, и только эту часть открываем. В основной кластер они зайти не могут.

Если говорить про безопасность, то в Kubernetes есть ещё одна интересная штука защита от человеческого фактора. Известно много громких факапов, произошедших по вине человека (история с GitLab, когда они положили пол своего продакшена, с Yandex.Cloud и другими компаниями). Прод базу данных снёс и оказалось, что в шести местах бэкапов нет или они неконсистентные, и случайным образом где-то там дампик лежал несколько часовой давности и типа: Ух! (перекрестился) Слава Богу! Восстановили!

Чтобы этого избежать, в Kubernetes тоже есть инструменты. Например, limit ranges, resource quotas. Они позволяют держать в узде тех, кто работает с Kubernetes. Например, не дают заскейлить свое приложение в какое-то очень большое количество. А такое один раз было. Коллега рассказывал: админ хотел поставить единицу. Клавиша залипла, интернет лагнул, вместо одного раза он нажал несколько и всё. Правда, это было не на Kubernetes, а на Nomad. Но факт такой, что он: Вам надо 111 млн приложений? Хорошо. Сейчас будет! И всё начало лагать, естественно. Чтобы этого избежать, мы можем сказать: Здесь максимум 10 реплик, и всё.

Ты упомянул Nomad. Какие ещё есть аналоги Kubernetes?

Самый яркий аналог, про который все говорят, это Docker Swarm. Docker Swarm это разработка от Docker, их нативное решение. Не требует никакой дополнительной установки: переходим в swarm-режим, и у нас появляется возможность Docker Swarm.

Docker Swarm это тоже оркестратор, поэтому многие сравнивают его с Kubernetes. Но если говорить глобально, то Kubernetes это более мощный комбайн, в нём больше возможностей. В Docker Swarm их чуть поменьше, но я бы сказал так: если у вас супертребований нет, то можно пользоваться и Docker Swarm. Но в отличие от него, Kubernetes, например, хорошо умеет автоскейлить. Причем, как ноды автоскейлить, заказывать, так и поды, то есть реплики приложений. В облаках это работает вообще шикарно. Пришла нагрузка с рекламной кампании мы не сидим, не заказываем руками, а он сам сходил и заказал. Когда нагрузка ушла, он обратно их схлопнул до нужного количества.

На каких операционных системах обычно запускается Kubernetes?

Ну обычно на Linux: CentOS, Debian.

А на винде умеет?

Они делают сейчас движение в сторону Windows. В принципе, стало лучше, но я бы сказал, что не надо пока этого делать.

Какими навыками нужно обладать, чтобы успешно работать с Kubernetes? Программирование, может, какое-то нужно? YAML, понятно.

Знание YAML, некоторое понимание, как работает контейнеризация Я не знаком лично, но слышал о таких людях, которые не имеют базового бэкграунда, но с Kubernetes работать умеют. Они могут налажать с сетью, например, но при этом с Kubernetes работают.

Я бы добавил, что нужны базовые знания по сетям, по Linux (если Kubernetes будет запускаться на Linux-машинах, их надо будет тюнить) и умение читать документацию.

В каких случаях Kubernetes вообще не стоит использовать?

Не стоит использовать, если рассчитываете, что поставите его, и все вопросы решатся. К внедрению надо подходить системно, и ставить Kubernetes только тогда, когда есть реальная необходимость.

Есть ещё ситуация Kubernetes ради зарплаты. Это когда технический специалист зашёл на Хедхантер, посмотрел на зарплаты, и пошёл пропихивать это решение в компании, чтобы потом попросить повышение: Я же теперь специалист по Kubernetes, платите мне больше. Это вряд ли к чему-то хорошему приведёт.

С технической точки зрения Kubernetes не нужно применять для приложений, которые не удовлетворяют 12 факторам. Для приложений, которые неправильно работают на уровне микросервисов, которые не допилены до конца. В одном из проектов мы пилили и переносили, пилили и переносили, и это было сложно, потому что часть проекта работала в Kubernetes, а часть продолжала работать на монолите и надо было выстраивать взаимосвязь.

В идеальном мире, конечно, Kubernetes ставится сразу же Сначала приложение готовится, потом уже туда. Но чаще всего нет.

Переходя к следующему блоку, спрошу: в чём различие Kubernetes и Ansible?

Ansible это, в первую очередь, система управления конфигурацией. Kubernetes это оркестратор контейнеров.
Знание Ansible не будет лишним, когда вы начнёте работать с Kubernetes, и наоборот. Потому что Kubernetes нужно как-то управлять, и Ansible для этого хорошо подходит.
Если мы говорим, что Kubernetes это Infrastructure as code (IaC), то вот этим IaC нужно как-то управлять. Руками туда лезть? В идеальном мире не лезут, всё прогоняют через пайплайны: надо что-то сделать в Kubernetes запускаешь плейбук он пошёл сам сделал. Поэтому знание Ansible и Kubernetes, наверное, важны в равной степени.

Далее отвечает Николай Месропян

Что такое Ansible и для чего он нужен?

Это средство управления конфигурациями. Для чего нужно? Когда у вас один сервер, им можно управлять руками: просто ходить на него, набирать команды или тыкать мышкой, что-то руками править, настраивать. Если их 2, 10 это ещё реально. Но в конце концов серверов может стать и 20, и 100, и 1000. Вот тогда возникает необходимость управлять ими более автоматизированно и централизованно.

Мы говорим про управление конфигурациями операционной системы или вообще любыми? Я задеплоил 25 приложений разных на хост, и я хочу

Обычно я начинаю рассказ про Ansible и свой курс с концепции, которая называются питомцы и стадо Pets vs Cattle. Pets это питомцы. Ты за ними ухаживаешь, лечишь, даёшь им уникальные имена. Cattle это стадо. Если кто-то заболевает, ты его забиваешь и создаешь вместо него новый сервер. У тебя их очень много, и ты их в лицо не знаешь, а знаешь только по номерам. Питомцы превращаются в стадо, когда их становится много.

Но когда они заболевать начинают!

Когда они заболевают, это жесть, я согласен. И чтобы с этим стадом управляться, создана система управления конфигурациями. Да, разумеется, она используется и для деплоев приложений, но начинаем мы обычно с системы управления конфигурациями, операционной системой на наливке каких-то приложений, конфигурирования их в том или ином порядке оркестрацией как бы.

Jenkins вроде как тоже кроме того, что поддерживает пайплайны, умеет конфигурировать приложения. Это в чём-то похоже на Ansible?

Нет, это совершенно разные вещи. Ansible похож на Chef, Puppet, SaltStack. Jenkins больше похож на GitLab CI и TeamCity. Это совершенно разные классы программного обеспечения для разных целей, но они могут работать вместе.

Я встречался с решениями, когда через пайплайн на GitLab CI производился деплой приложений посредством приложения, использующего внутри себя Chef.
Сам я писал пайплайны для GitLab CI на Ansible. То есть они вместе работать могут. Иногда и просто должны.

Из чего состоит Ansible, и как он вообще работает? Это какое-то приложение над приложениями или отдельный сервер, что это вообще?

Cначала расскажу про ПО для управления конфигурациями. Расскажу, чем они друг от друга отличаются, и потом перейдём конкретно к Ansible.

ПО для управления конфигурациями можно разделить на два основных класса: pull и push.
Когда работает система принципа pull, на клиентских хостах, то есть на управляемых хостах, выполняется некий daemon (сервис), который подтягивает конфигурацию с центрального репозитория и на месте уже её раскатывает.

push это когда управляющий процесс выполняется на одном центральном сервере, а на конечные ноды доезжают только конечные изменения (по сети). То есть конфигурирование производится не на месте, а по сети.

По сети SSH, FTP?

Как правило, SSH. Вот Ansible относится именно к push. На центральном сервере выполняется процесс, который использует конфигурацию, чаще всего хранящуюся в репозитории.

Зачем вообще нужен pull, если push выглядит достаточно красиво и ненапряжно?

Push медленный.

В случае с pull процесс работает на клиентской ноде, стягивает конфигурацию в виде файликов, а потом уже на месте, через местные вызовы API очень быстро создаёт или поддерживает нужную конфигурацию.

При модели push центральный процесс каждый раз идёт к ноде по SSH, что-то там делает, возвращает результат, здесь он оценивается, и всё это повторяется.

Тогда чем push лучше pull?

На конечных нодах не хранится никакой конфигурации, что называется нулевой footprint (след).

Бывает важно, чтобы на клиентских машинах никто не мог понять, как и что конфигурируется. Расскажу про нашу компанию, Southbridge. У нас аутсорсинг, множество клиентов, и информация под клиентов хранится в репозитории. Потому что мы не хотим, чтобы клиент мог своими руками что-то подкрутить и сломать. Он может сделать это без злого умысла, просто: Программист сказал, что можно сделать так, давай-ка сделаем! А потом раз продакшн снесся, и он приходит к нам: У вас все плохо работает!

В действительности таких случаев у нас не было, когда мы использовали pull-системы. Но тем не менее. К тому же лучше подстраховаться, чтобы конфигурация одних клиентов не попала каким-то другим. Именно поэтому мы используем push.

Плюс нам понравилась сама парадигма, что всё лежит в одном месте. Сами клиентские процессы иногда написаны на тяжёлых языках (Ruby, например) и тоже подъедают системные ресурсы: и память, и процессор. Поэтому это в каких-то случаях может быть нежелательным.

А клиентские ПО, клиентские ресурсы, которые в push работают, они пишутся руками или есть готовые какие-то решения?

Вот теперь я могу рассказать, из чего Ansible состоит (без слайдов и доски сложно, но попробую объяснить на пальцах).

Для Ansible мы пишем конфигурацию, состоящую из сущности под названием плейбуки (playbook), ролей и инвентаря. Плейбуки и роли это определение конфигурации. Инвентарь это параметризация.

Плейбук это файл, состоящий из набора так называемых плеев (play).
Сразу скажу, что вся конфигурация пишется на YAML. Ansible написан на Python, поэтому для него родной язык разметки YAML.

Ansible, если что, лучше всего ставить в virtualenv, чтобы быть независимым от мейнтейнера
А, да, начнём с того, где Ansible работает: управляющие хосты поддерживаются только Linux.

А если это виртуалка?

Всё равно. Всё-таки используются системные вызовы, и чтобы не адаптироваться, в качестве управляющего хоста поддерживается только Linux. Управлять можем Linux-системами, Windows-системами и Mac OS. Но для Mac, насколько я знаю, оно пока в зачаточном состоянии.

Android, мобильные платформы?

Наверняка что-то есть, но пока оно большого распространения не получило.

У нас выполняется центральный процесс, который этот плейбук читает.

Плейбук это набор плеев. Каждый плей состоит из двух элементов: описание хостов, на которых выполняется данный участок кода, и tasks задачи, то есть именно что делать.

Если совсем примитивно, с помощью Ansible можно сделать на хостах всё то же, что мы делаем руками, только автоматизировано, массово, детерминировано и т. д. Поэтому элементарный task или элементарная задача это выполнение какой-нибудь команды, например. Но чаще всего используются специализированные модули: для шаблонизации файлов, для запуска сервисо

А команды это просто команды консоли или?

Да, есть такой модуль command, который просто выполняет консольную команду.

Он на клиенте?

На клиенте, да.

А почему нельзя просто через SSH напрямую в терминал фигачить?

Модуль command это последний шанс, если у тебя нет специализированного модуля для выполнения определённой задачи.

Чтобы запустить сервис, мы не делаем command systemctl start engine, мы используем модуль service или модуль systemd, который приводит систему, в данном случае сервис, в заданное состояние. То есть он запущен и включён либо остановлен и выключен.

Вообще, управление конфигурациями задумывалось как декларативное. То есть мы описываем желаемое состояние системы, потом эта самая управлялка приводит систему в заданное состояние. Если система уже находится в нужном состоянии, то не производится никаких действий. Это свойство называется идемпотентность.

Понятно, в не зависимости от того, сколько раз ты запускаешь

Результат всегда один и тот же.

Это прям как в REST API, разработчикам должно быть понятно.

Да!

Поэтому мы описываем в задачах желаемую конфигурацию и Ansible приводит (если это грамотно написано) систему в заданное состояние. Если система уже в заданном состоянии, то действие не производится. Потом мы в выводе команды всё это видим.

Что такое роли? Роли можно уподобить подключаемым библиотекам. То есть мы пишем роль, которая, допустим, настраивает веб-сервер nginx, и потом из разных плейбуков для разных хостов с разными параметрами мы эту роль подключаем.

Роли могут храниться как на диске вместе с плейбуками конфигурации, так и во внешних репозиториях. Есть такая штука, называется Ansible Galaxy это что-то вроде центрального хранилища ролей. Туда можно свою роль подать на рассмотрение. Это не то чтобы пакетный менеджер, а как GitHub, допустим. Только специализированный, исключительно для Ansible.

То есть роли это готовые куски конфигураций, которые ты можешь у себя встраивать и переиспользовать?

Это описание конфигурации, которому ты можешь сам задавать разные параметры из инвентаря.

Отлично. И тут включается механизм параметризации?

Да. При запуске команды ansible-playbook, которая и делает нужные изменения на хостах, мы задаём ей параметром так называемый инвентарь откуда брать параметры. В инвентаре у нас чаще всего список хостов, объединенных в группы (чтобы Ansible знал, на каких хостах выполнять те или иные задачи), и набор переменных для них, которые подставляются в роль и меняют поведение в нужную сторону.

Jinja2 это из этой темы?

Jinja2 это весьма мощный язык шаблонизации. Jinja2 используется в ролях.

Это параметризация, как я понимаю, нет?

Это шаблон. А параметры это то, что ты уже в этот шаблон вставляешь. Вообще, это очень мощная вещь, с помощью этого языка шаблонов можно описывать конфиги практически любой сложности и при выполнении уже непосредственно роли из своего инвентаря подставляются нужные переменные и тебе формируется нужный конфиг.

Как гарантировать, что твой конфиг работоспособный, что он не устарел, не сломался вдруг на сервере что-то поменялось, и у тебя команда ansible-play не сработала. Это как-то тестируется?

Да, разумеется, это тестируется.

В правильно построенной инфраструктуре мимо Ansible и вообще любого средства управления конфигурациями ничего меняться не должно. То есть никто не должен ходить руками и там что-то делать и настраивать. Если он это делает, то за это нужно по рукам бить. Потому что правильный подход это вносить нужные изменения в инвентарь. Если в используемых ролях нет нужных действий, ты дописываешь.

Это подход инфраструктура как код (Infrastructure-as-Code, IaC). Код в каком смысле? Код должен проходить ревью, то есть твои коллеги должны видеть, что ты написал и подтвердить, что это вменяемо.

Речь про конфигурации?

Да. То есть точно также весь инфраструктурный код хранится в репозитории GitLab, GitHub чем вы там пользуетесь.

Рядом с продуктовым кодом? Или это отдельная репа?

Разумеется, отдельная. Это много реп чаще всего. И потом перед тем как что-то изменить, ты делаешь merge request с изменениями (в зависимости от того, какая схема у вас в компании принята). В простейшем случае пишешь в телегу коллеге: Вот, я написал, посмотри и кидаешь ссылку. Он говорит: Всё нормально, идём на тестирование.

Раз инфраструктура как код, у нас код проходит пайплайн. Всегда самый первый или второй job это lint. Команда ansible-lint просматривает код на синтаксические ошибки и дает дельные советы. Если ты ставишь пакет, вызывая его как command "yum" или "apt-get" install, то тебе линтер напишет: Используй специализированный модуль yum или apt. То есть тут не только синтаксические ошибки, но и семантика.

Разумеется, кроме проверки синтаксиса, есть инструмент полного тестирования. Потому что синтаксический анализатор не знает общего замысла твоего плейбука и не может знать, что будет в конце, идемпотентна данная конфигурация или нет. Есть такой инструмент, называется Molecule. Она запускает виртуальную машину...

Главный вопрос: не на проде же ты это будешь делать?

Да, разумеется, запускается виртуалка, в ней согласно описанной для Molecule конфигурации запускается Ansible плейбук.

А где гарантия, что виртуалка похожа на прод?

Надо самому следить.

Продакшн у нас же изначально чистый, как я понимаю?

Продакшн у нас изначально чистый. То есть с момента рождения он у нас сделан с помощью Ansible. Поэтому тестовая виртуалка обязана быть похожа на прод. Если нужно, туда можно и приложения вкатить отдельным jobом.

А по ресурсам она тоже должна быть такая же, как прод, или необязательно?

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

Тебе как человеку, который работает с Ansible, нужно программирование? Ты говорил, язык разметки YAML, написан на Python, нужно ли дописывать какие-то модули, ещё что-то. Просто, чтобы понимали девелоперы: нужно ли владеть языком при работе с Ansible?

Можно не владеть. Но лучше владеть.

Каким и для чего?

Python. Потому что, если под конкретную задачу нет нужного модуля, конечно, можно написать это всё в виде скрипта и дёргать его из task, но это плохой тон, это называется bashsible в комьюнити, связанных с Ansible. И это прям фу-фу.

Чаще советуют написать специализированный модуль под свою задачу. Его можно написать на Shell, да и вообще на любом языке, потому что там просто система вызовов, но лучше всего писать на нативном для этого дела.

Нативном для Ansible, да?

Да.

Потому что можно на C попробовать это сделать.

Ну, если затраченные усилия будут оправданы, почему бы и нет.

Какие есть более или менее популярные аналоги Ansible? Или это монополист на рынке?

Нет, это, конечно, не монополист. Значительно более старые решения (в смысле прошедшие более длинный путь развития) это Chef и CFEngine. Последний сейчас уже мало используется.

Они все работают примерно одинаково?

Они работают в основном как pull: на настраиваемой ноде выполняется сервис, который тянет конфигурацию.

Ansible единственный, кто делает push из крупных?

Ansible умеет pull, но это не основной его режим работы. SaltStack тоже умеет push, но это не его основной режим работы. Ansible, можно сказать, в этом плане единственный. Ну и видимо, народу нравится, потому что я смотрю время от времени Google Trends по запросам, относящимся к Chef, к Ansible, и вижу, что Ansible набирает всё большую популярность. Более старых решения на пятилетнем промежутке её чуть-чуть теряют. Хотя есть энтузиасты, которые за них топят и их поддерживают.

Может, есть какие-то книги, что можно почитать, чтобы базово познакомиться с Ansible?

Знакомство с Ansible лучше всего начать с документации. На docs.ansible.com расписаны и самые основы, и примеры простых плейбуков, и вообще всё что нужно.
Я еще скажу про книгу Ansible: Up and Running. Книга неплохая, но Ansible достаточно быстро развивается и поэтому многие вещи в ней уже устарели. Поэтому лучше всего начинать именно с документации на сайте, она там всегда актуальна.

Вопросы задавал Лекс АйТиБорода iamitbeard

Kubernetes сейчас называют стандартом для оркестрации контейнеров. Он лежит в основе многих облачных платформ контейнеризации: например, мы давно развиваем наш Kubernetes aaS на платформе Mail.ru Cloud Solutions.

Однако Kubernetes далеко не первый подобный инструмент на рынке: некоторые из систем-предшественников продолжают активно использовать и вроде бы даже успешно.

Почему так происходит, несмотря на то, что Kubernetes, можно сказать, одержал победу в своем классе и мы видим много примеров, когда он приходит на смену другим решениям? Например, не так давно разработчики Mesosphere DC/OS, в основе которой лежал Apache Mesos, прекратили ее развитие и сфокусировались на другой своей платформе D2iQ Kubernetes (DKP). Думаю, что стоит разобраться, всегда ли хорош Kubernetes, когда оправдано использовать другие оркестраторы и о каких подводных камнях стоит знать.

Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). В этой статье расскажу об устройстве ряда оркестраторов-предшественников, сравню их с Kubernetes, посмотрю на его преимущества и недостатки по сравнению с ними.

• Критерии для сравнения
• I. Docker Swarm vs Kubernetes
• II. Nomad vs Kubernetes
• III. Apache Mesos (+ Maraphon, Aurora) vs Kubernetes
• IV. Fleet vs Kubernetes
• V. Преимущества и недостатки систем оркестрации
• Как перейти на Kubernetes с других оркестраторов
• Чек-лист: на что обратить внимание при выборе провайдера Kubernetes
• Выводы: сравнительный анализ систем оркестрации

Критерии для сравнения

В статье я сравню Kubernetes с наиболее известными и часто используемыми системами оркестрации: Docker Swarm, Nomad, Apache Mesos и Fleet.

Для сравнения использую следующие критерии:

1. Типы рабочих нагрузок: предназначен ли оркестратор для управления Docker-контейнерами, иными контейнерами и неконтейнерными приложениями.
2. Легкость управления: насколько оркестратор прост в установке и настройке.
3. Требования к платформе для развертывания: является ли решение платформонезависимым или есть определенные требования к ОС и иные ограничения.
4. Производительность: среднее время обработки API-вызовов, запуска контейнеров и других важных операций.
5. Ограничения на количество узлов и контейнеров в кластере: какие существуют ограничения на число управляемых компонентов.
6. Конфигурация как код: есть ли возможность загрузки схем приложений из YAML- или JSON-файлов.
7. Шаблоны: доступна ли настройка пользовательских шаблонов.
8. Сети: как строится сеть, есть ли собственное сетевое решение или необходимо использовать сторонние сетевые плагины.
9. Возможность обнаружения сервисов: поддерживается ли динамическое обнаружение сервисов путем использования DNS, Proxy и так далее.
10. Автомасштабирование: есть ли возможность автомасштабирования в зависимости от изменений нагрузки.
11. Выполнение обновлений и отката: какие стратегии обновлений поддерживаются. Существует ли возможность последовательных обновлений (Rolling Update), когда старые инстансы приложения постепенно заменяются на новые. Насколько просто проводится откат.
12. Отказоустойчивость: как выполняется обработка сбоев, что происходит при выходе из строя одного из узлов.
13. Мониторинг: есть ли встроенные механизмы или необходимо использовать внешние инструменты и какие.
14. Безопасность: есть ли встроенное решение для управления конфиденциальной информацией (логины и пароли).

Выполнив сравнение по этим критериям, разберемся, для решения каких задач могут подойти другие оркестраторы, в чем они уступают Kubernetes и как при желании построить переход от них к Kubernetes с наименьшими усилиями.

I. Docker Swarm vs Kubernetes

Docker Swarm встроенное в сам Docker решение для управления контейнерами на физических или виртуальных машинах. Когда несколько хостов Docker используют режим Swarm, некоторые из них могут быть настроены как управляющие ноды, или менеджеры (Manager), а остальные как рабочие ноды (Worker). Задача менеджеров управлять кластером и делегировать задачи рабочим узлам.

1. Типы рабочих нагрузок

Если Docker Swarm предназначен для работы исключительно с Docker-контейнерами, то Kubernetes поддерживает несколько типов контейнеров: Docker, containerd, CRI-O и любое решение, придерживающееся стандарта CRI (Container Runtime Interface).

2. Легкость управления

По сравнению с Kubernetes Docker Swarm намного проще в установке вручную. Swarm работает поверх Docker, использует интерфейс его командной строки и легко интегрируется с Docker Compose. Kubernetes также может работать поверх Docker, но взаимодействовать с инфраструктурой в этом случае нужно будет при помощи двух разных утилит: Docker CLI и kubectl CLI.

Устройство Kubernetes на порядок сложнее. Он включает в себя множество компонентов: kube-api-server, kube-scheduler, kube-controller-manager, kube-proxy, kubelet и поддерживает несколько типов установщиков для разных типов инфраструктур и задач: Kubeadm, Kops, Kubespray и так далее. Все это требует дополнительного обучения.

То есть порог вхождения в Kubernetes выше по сравнению с Docker Swarm. Но все, что связано непосредственно с администрированием контейнеров: deployments, доведение кластера до нужного состояния, добавление новых нод, в K8s можно выполнить проще и быстрее. Также многие, поработав с обоими оркестраторами, отмечают, что Kubernetes более стабилен.

3. Требования к платформе для развертывания

Docker Swarm, как и Kubernetes, может использоваться в различных ОС: Windows, macOS, Linux. Однако Kubernetes использует различные настройки для каждой ОС. Если требуемые вам конфигурации выходят за рамки стандартной реализации, самостоятельная настройка Kubernetes может превратиться в гигантскую задачу. В этом плане Docker Swarm выигрывает.

4. Производительность

По сравнению с Kubernetes Docker Swarm быстрее. Kubernetes сложнее из-за большего числа дополнительных уровней в архитектуре (планировщик и так далее), что замедляет выполнение операций, но обеспечивает стабильность кластера в целом.

5. Ограничения на количество узлов и контейнеров в кластере

Kubernetes v1.20 поддерживает конфигурации, отвечающие следующим критериям:

• не более 110 подов на узел, при этом параметр можно настраивать,
• не более 5 000 узлов,
• всего не более 150 000 подов,
• всего не более 300 000 контейнеров.

В документации Docker Swarm даны рекомендации только по числу узлов-менеджеров 7 штук. Максимальное число контейнеров будет определяться, скорее, ограничениями ОС, но пользователи Swarm советуют придерживаться похожих рекомендаций: 100 контейнеров на ноду.

6. Конфигурация как код

В обоих оркестраторах можно использовать YAML-файлы для определения конфигураций. В Kubernetes также доступен JSON-формат, но YAML предпочтителен.

7. Шаблоны

В Docker Swarm нет шаблонизатора, аналогичного Helm в Kubernetes. Некий шаблонизатор приложений анонсировался в Docker Desktop Enterprise 3.0, но в настоящее время это решение не поддерживается.

8. Сети

С точки зрения сетевой модели Kubernetes смотрится предпочтительнее. Он работает с виртуальными сетями и поддерживает намного большее количество разных сетевых решений по сравнению со Swarm. Каждый под получает свой IP-адрес, что означает отсутствие необходимости сопоставления портов контейнера портам хоста. Kubernetes может работать с любым CNI-совместимым сетевым решением.

В Docker Swarm вы можете указать оверлейную сеть для своих служб. Менеджер будет автоматически назначать адреса контейнерам в оверлейной сети при инициализации или обновлении приложения. Однако некоторые пользователи жаловались на производительность нативной сети, советуя применять сетевые плагины вроде Calico.

9. Возможность обнаружения сервисов

Реализована в обоих оркестраторах с использованием встроенного DNS-сервера.

10. Автомасштабирование

В Docker Swarm автомасштабирование недоступно. Для каждой службы вы можете вручную указать количество задач, которые хотите запустить. Когда это число увеличивается или уменьшается, управляющий узел (Manager) автоматически адаптируется, добавляя или удаляя задачи для поддержания желаемого состояния.

В Kubernetes поддерживается автомасштабирование на основе наблюдаемого использования ЦП, памяти и ряда других пользовательских метрик. При этом масштабирование доступно на нескольких уровнях:

1. Автомасштабирование кластера с использованием Cluster Autoscaler, отвечающее за изменение числа узлов в кластере.
2. Горизонтальное автомасштабирование подов (Horizontal Pod Autoscaler, HPA), которое автоматически изменяет количество подов в зависимости от значений выбранных показателей.
3. Вертикальное автомасштабирование подов (Vertical Pod Autoscaler, VPA), которое автоматически изменяет объем ресурсов, выделяемых существующим подам.

11. Выполнение обновлений и отката

И Kubernetes, и Docker Swarm поддерживают последовательные обновления (Rolling Update): во время развертывания вы можете постепенно применять обновления служб к узлам. В случае сбоя можно вернуться к предыдущей версии сервиса. Однако Kubernetes предоставляет возможность более гибкой настройки.

Swarm Manager позволяет контролировать время задержки между развертыванием сервиса на разных наборах узлов, возможность одновременного обновления нескольких задач и действия в случае сбоя обновления.

В Kubernetes гораздо больше настраиваемых опций: максимальное количество недоступных подов, допустимое увеличение числа подов, минимальное время, в течение которого под должен стать доступным, максимальный срок выполнения задач.

12. Отказоустойчивость

В обоих оркестраторах поддерживается высокая доступность приложений.

В Docker Swarm управляющий узел (Manager) постоянно отслеживает состояние кластера и согласовывает любые различия между фактическим состоянием и настроенным вами желаемым состоянием.

В Kubernetes службы балансировки нагрузки обнаруживают поды со сбоями и удаляют их. Используются проверки работоспособности (Health Check).

13. Мониторинг

Использование в Docker Swarm решений для логирования и мониторинга (ELK, Prometheus) возможно, как и в Kubernetes, но требует больше кастомных настроек или использования дополнительных наборов инструментов, таких как Swarmprom.

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

С точки зрения безопасности в Swarm еще недавно не было практически ничего. Для хранения секретов приходилось использовать Vault. Сейчас каждый узел в Swarm применяет взаимную аутентификацию и шифрование TLS для защиты коммуникаций внутри себя и с другими узлами. Также есть возможность использовать самоподписанные корневые сертификаты или сертификаты от настраиваемого корневого Центра сертификации. Есть и встроенное решение для управления секретами.

Однако Kubernetes все равно находится на шаг впереди, предлагая гибкую настройку сетевых политик (Network Policies), использование пространств имен (Namespaces) и прочие преимущества.

II. Nomad vs Kubernetes

Nomad это оркестратор от компании HashiCorp для управления контейнерами и неконтейнерными приложениями. Основу его архитектуры составляют клиенты (Client), на которых можно запускать задачи, и серверы (Server), управляющие клиентами и задачами. Серверы выбирают лидера для обеспечения высокой доступности.

Рабочую нагрузку в Nomad определяет работа (Job), описывающая желаемое состояние кластера и состоящая из одной или нескольких групп задач. Задача (Task) самая маленькая единица работы, которая выполняется драйверами (Docker, QEMU, Java и так далее). Обязанность Nomad поддерживать соответствие между желаемым состоянием, описанным в Job, и фактическим состоянием кластера.

За консультацию по работе Nomad отдельное спасибо manefesto.

1. Типы рабочих нагрузок

В то время как Kubernetes ориентирован на использование контейнеров, Nomad работает с различными видами рабочих нагрузок. Он поддерживает виртуализированные, контейнерные и автономные, микросервисные и пакетные приложения, включая Docker, Java, Qemu и другие, полный список можно посмотреть здесь. Это позволяет оркестрировать не только контейнерами / виртуальными машинами, но и запускать приложения на нодах. Например, можно запустить на нодах тяжелые Java-приложения.

2. Легкость управления

Установка Nomad значительно проще, чем Kubernetes. Nomad доступен в виде предварительно скомпилированного двоичного файла (единого как для клиентов, так и для серверов) и в виде пакетов для различных операционных систем. Вы также можете собрать Nomad из исходников.

Минимальный тестовый стенд можно поднять на хосте без использования сторонних утилит типа Minikube. Достаточно запустить Nomad в dev-режим, и он будет выполнять роль сервера/агента, чего вполне достаточно для локального тестирования.

Однако если Kubernetes стремится предоставить все функции, необходимые для запуска контейнерных приложений (включая управление кластером, автообнаружение служб, обеспечение безопасности и многое другое), то Nomad сосредоточен только на управлении кластером и планировании.

K8s считается фреймворком для построения кластера, в то время как подход HashiCorp больше близок к UNIX-way. Настроить кластер Nomad под нужные требования можно с помощью внешних инструментов: Consul для обнаружения сервисов, Vault для управления конфиденциальной информацией и других. До определенного момента в Nomad не было возможности использовать внешние хранилища, сети, отличные от хостовых и Bridge, но сейчас есть поддержка плагинов CSI, CNI, появилась возможность использовать сети, хранилища так же, как это делает K8s.

В любом случае использовать Nomad несложно: по факту достаточно скопировать бинарный файл и создать Systemd-сервис, который работает в связке с Consul как Service Discovery.

3. Требования к платформе для развертывания

И Kubernetes, и Nomad могут быть развернуты в различных ОС: Linux, macOS, Windows. Однако Kubernetes требует различных настроек в зависимости от ОС поэтому его установка, проводимая вручную, сложнее.

4. Производительность

По производительности оба решения примерно на одинаковом уровне, но Nomad все же впереди за счет архитектурной простоты.

5. Ограничения на количество узлов и контейнеров в кластере

Kubernetes поддерживает кластеры до 5 000 узлов и 300 000 контейнеров. В документации Nomad указано, что он масштабируется до размеров кластера, превышающих 10 000 узлов в реальных производственных средах. Также Nomad успешно участвовал в ряде напряженных тестов на масштабируемость: 1 миллион контейнеров в 2016 году и 2 миллиона контейнеров в 2020 году. Однако на практике вероятность применения настолько масштабных кластеров невелика.

6. Конфигурация как код

Kubernetes поддерживает декларативные развертывания на основе YAML-файлов. Nomad использует собственный язык описания конфигураций HashiCorp HCL. То есть при использовании Nomad вам потребуется дополнительное обучение HCL. Но стоит отметить, что в Nomad присутствуют стандартные средства и команды для преобразования описаний из YAML и JSON в HCL (и обратно): yamlencode/yamldecode, jsonencode/jsondecode. Правда, работают они с определенными ограничениями, а некоторые в тестовом режиме.

7. Шаблоны

В Nomad нет инструмента для шаблонизации, аналогичного Helm для Kubernetes.

8. Сети

В плане организации сетей Kubernetes выглядит лаконичнее и стабильнее. В нем изначально была введена абстракция Pod, позволяющая запускать несколько контейнеров в одном сетевом пространстве, и использовался CNI (Container Networking Interface). Nomad же развивался от меньшего к большему и долгое время использовал исключительно хостовые сети без дополнительных слоев абстракции. Вместо Pod в нем использовались Job без возможности объединения контейнеров внутри них в единое сетевое пространство. Мультиинтерфейсные сети и возможность подключения CNI стали развиваться в Nomad относительно недавно. Можно подключить CNI-плагин для использования Calico, Cilium, Weave.

9. Возможность обнаружения сервисов

В отличие от Kubernetes, в Nomad нет Autodiscovery на основе DNS. Для обнаружения сервисов необходимо использовать дополнительный инструмент Consul. В этом Nomad сильно уступает Kubernetes. И многие считают это одной из основных причин, почему Nomad оказался менее востребован в свое время.

10. Автомасштабирование

Общая черта двух оркестраторов поддержка следующих типов автомасштабирования:

• горизонтальное автомасштабирование приложений в Nomad и подов в Kubernetes,
• автомасштабирование кластера.

Дополнительно в Kubernetes реализовано вертикальное автомасштабирование подов, которое автоматически изменяет объем ресурсов, выделяемых существующим подам. Похожее решение в Nomad, состоящее в построении рекомендаций по ЦП и памяти на основе анализа исторических данных, доступно исключительно в Enterprise-версии.

11. Выполнение обновлений и отката

Оба оркестратора предоставляют возможность гибкого управления обновлениями, включая стратегии последовательного (Rolling update), сине-зеленого (Blue and Green) и канареечного (Canary) обновлений. Для настройки доступен целый ряд показателей, влияющих на ход обновлений, включая временные интервалы для проверки работоспособности и прочее.

И K8s, и Nomad поддерживают автоматический возврат к последней стабильной версии в случае сбоя развертывания. История развертывания ведется в обоих случаях.

12. Отказоустойчивость

По умолчанию поведение у обеих систем схожее. В Kubernetes дается минута на определение узла со сбоем и до пяти минут на вытеснение подов на другую ноду. В Nomad примерно такие же дефолтные показатели. Но в Kubernetes с использованием опций kubelet и Control Manager реально добиться того, чтобы уже в течение 10 секунд поды были вытеснены на другую работоспособную ноду.

13. Мониторинг

Оба оркестратора совместимы с популярными инструментами логирования и мониторинга: ELK, Prometheus/Grafana и прочими. Ведется сбор метрик, которые можно получить впоследствии через API либо настроив автоматическую пересылку стороннему провайдеру.

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

Основное, в чем проигрывает Nomad в плане безопасности, это необходимость использования сторонней системы Vault для управления конфиденциальной информацией (логинами и паролями). Хотя безопаснее Vault на современном рынке Open Source-решений, пожалуй, нет его настройка и использование совместно с Nomad является довольно сложной задачей. Коробочный Kubernetes в этом отношении проще, так как может предложить встроенное решение.

Кроме этого, если в Kubernetes по умолчанию поддерживаются пространства имен (Namespaces), которые можно эффективно использовать для разделения сред разработки, то в Nomad данная функциональность доступна только в Enterprise-версии.

III. Apache Mesos (+ Maraphon, Aurora) vs Kubernetes

Apache Mesos это менеджер кластера, поддерживающий различные рабочие нагрузки. Основу архитектуры Mesos составляют мастер (Mesos Master), агенты (Mesos Agent), работающие на каждом узле кластера и управляемые мастером, и фреймворки (Mesos Frameworks), которые запускают задачи на агентах. Обычно разворачивается несколько резервных мастеров, готовых взять на себя управление в случае сбоя, а за выбор лидера среди них отвечает ZooKeeper.

Фреймворк состоит из двух компонентов: планировщика (Scheduler), он регистрируется на главном сервере, которому будут предлагаться ресурсы, и исполнителя (Executor), который запускается на узлах агентов для выполнения задач фреймворка. Мастер предлагает ресурсы агентов фреймворкам, а планировщики выбирают, какие из предложенных ресурсов использовать для запуска своих задач на агентах. В кластере Mesos может работать несколько фреймворков для разных типов задач.

То есть сам по себе Apache Mesos является лишь неким диспетчером, а конечная функциональность будет определяться используемым фреймворком. Поэтому при описании показателей будем иногда ссылаться на два конкретных фреймворка: Maraphon для управления контейнерными приложениями и Apache Aurora для планирования Cron-заданий и долго работающих служб. Aurora больше не поддерживается, но в свое время была довольно распространена и в том числе могла использоваться для контейнерных приложений. Также иногда будем упоминать Mesosphere DC/OS операционную систему, основанную на Apache Mesos, Maraphon и предлагающую ряд дополнительных возможностей (правда, часть из них доступна в платной версии).

1. Типы рабочих нагрузок

Apache Mesos предназначен для обработки различных типов рабочих нагрузок, которые могут быть как контейнерными, так и неконтейнерными. В качестве планировщика заданий (Scheduler) могут быть использованы, например, Hadoop (Big Data), MPI (обмен сообщениями), Jenkins (система непрерывной интеграции). Используя Apache Mesos, можно разработать даже собственный планировщик.

Kubernetes ориентирован исключительно на контейнерные приложения.

2. Легкость управления

Apache Mesos проще развернуть, чем Kubernetes, если мы говорим о ручной установке. Однако дальнейшее администрирование Apache Mesos сложнее по сравнению с K8s, так как необходимо работать с ZooKeeper, уметь администрировать Java и быть готовым к связанным с этим трудностям: утечкам памяти, Xmx, лимитам и так далее. Kubernetes с Golang в этом плане проще.

3. Требования к платформе для развертывания

Mesos работает на Linux и macOS. Агенты могут быть установлены и на Windows.
Kubernetes также поддерживает все ОС.

4. Производительность

Mesos изначально был ориентирован на работу с Big Data поэтому по производительности он опережает Kubernetes.

5. Ограничения на количество узлов и контейнеров в кластере

По масштабируемости Apache Mesos выигрывает у Kubernetes, так как способен поддерживать десятки тысяч узлов (K8s рассчитан на 5 000 максимум). Когда Mesos сочетается с Mesosphere DC/OS, получается платформа, предлагающая практически неограниченную масштабируемость, которая идеально подходит для больших систем. Разработчики заявили, что прекратили ее развитие, но существующих клиентов продолжают поддерживать. Еще в 2015 году Mesos с успехом выдержал тест на масштабирование до 50 000 узлов.

6. Конфигурация как код

В Apache Mesos в сочетании с Maraphon можно использовать определения JSON (для указания репозиториев, ресурсов, числа экземпляров и команд для выполнения). В Kubernetes для этой цели поддерживаются декларативные развертывания и в YAML, и в JSON (первый предпочтительнее).

7. Шаблоны

Если вы работаете в Mesosphere DC/OS, то можете использовать шаблоны конфигураций (с использованием Maraphon-LB). В Apache Aurora при настройке услуг в DSL также были доступны шаблоны во избежание дублирования конфигураций. Но Helm, используемый в K8s, будет более мощным и удобным инструментом.

8. Сети

Долгое время Apache Mesos отставал от Kubernetes в плане сетевой реализации, так как по умолчанию в нем не назначались IP-адреса контейнерам, требовалось проведение сопоставления портов контейнера с портами хоста, которые являются ограниченным ресурсом. Впоследствии была добавлена поддержка CNI (Container Networking Interface) и появилась возможность использования виртуальных сетей вида Calico, Cilium, Weave. Но в Kubernetes сейчас поддерживается большее число сетевых решений.

9. Возможность обнаружения сервисов

Присутствует в обеих системах.

Mesos-DNS обеспечивает обнаружение служб и базовую балансировку нагрузки для приложений. При использовании совместно с Marathon дополнительно доступен Marathon-LB для обнаружения на основе портов с помощью HAProxy. В Aurora была также представлена экспериментальная поддержка Mesos DiscoveryInfo для создания настраиваемой системы обнаружения без использования ZooKeeper.

В Kubernetes доступен встроенный DNS-сервер.

10. Автомасштабирование

Реализация автомасштабирования лучше в Kubernetes. Как уже отмечалось выше, доступны три стратегии: масштабирование кластера, горизонтальное масштабирование подов и вертикальное масштабирование подов. В качестве триггеров можно настраивать показатели ЦП, памяти и пользовательские показатели.

В Apache Mesos автомасштабирование доступно в комбинации с Maraphon (в Mesosphere DC/OS) на основе значений ЦП, памяти и числа запросов в секунду.

11. Выполнение обновлений и отката

Поддерживается в обеих системах. Сине-зеленое (Blue and Green) развертывание доступно в Apache Mesos, также его можно реализовать в Kubernetes, используя встроенные механизмы.

12. Отказоустойчивость

Обе системы отказоустойчивы.

В Apache Mesos экземпляры приложений распределяются по агентам, обеспечивая высокую доступность. Кроме того, ZooKeeper поддерживает доступность кластера через кворум и выборы лидера.

Аналогично поды в Kubernetes реплицируются на несколько узлов. Обычно кластер Kubernetes состоит из нескольких рабочих узлов. В нем также может быть несколько мастеров.

Кроме этого, оба оркестратора предоставляют проверки работоспособности (Health Check). Для Mesos они доступны в случае использования Mesosphere DC/OS.

13. Мониторинг

И в Mesos, и в Kubernetes доступно получение метрик, относящихся к работоспособности и другим показателям. Данные можно запрашивать и агрегировать с помощью внешних инструментов. Типичной практикой является развертывание ELK и Prometheus + Grafana.
Но подключение мониторинга в Kubernetes происходит проще, так как многое строится на готовых решениях благодаря поддержке многочисленного сообщества и богатому инструментарию. В Mesos многое приходится делать самостоятельно, вследствие чего неизбежно увеличивается Time to Market.

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

Сложно отдать кому-то предпочтение. Если говорить об Apache Mesos в связке с Maraphon или Aurora вне Mesosphere DC/OS, то Kubernetes выглядит лучше. Долгое время Mesos не мог предложить в плане безопасности практически ничего. Так, встроенное решение по работе с секретами не имело в нем надлежащей реализации, и пользователи предпочитали использовать сторонние инструменты, например Vault.

Но если обратиться к ОС DC/OS Enterprise сегодня она предлагает богатый функционал в плане корпоративной безопасности, возможно, даже лучший, чем в Kubernetes. Однако эта версия системы является платной, кроме того, ее развитие свернуто разработчиками в пользу новой платформы на основе как раз Kubernetes.

IV. Fleet vs Kubernetes

Fleet это низкоуровневый кластерный движок от CoreOS, похожий на распределенную систему инициализации. В настоящее время он не поддерживается, так как компания стала активно продвигать Kubernetes.

Fleet был основан на systemd. В то время как systemd обеспечивал инициализацию системы и служб на уровне одной машины, Fleet расширил этот процесс до кластера. В архитектуре Fleet на каждой машине запускался fleetd-демон, обеспечивающий две роли: движок (Engine) и агент (Agent). Движок принимал решения по планированию, а агент обрабатывал Systemd Unit-файлы (Unit). Эта обработка чаще всего сводилась к запуску контейнера.

В любой момент времени в кластере был активен только один движок, но все агенты работали. Новые файлы назначались агентам с наименьшей нагрузкой. В качестве хранилища данных в кластере и средства связи между движком и агентами выступал etcd. В нем хранились Unit-файлы, данные об их состоянии, состоянии кластера и так далее.

1. Типы рабочих нагрузок

Если Kubernetes поддерживает работу с контейнерными приложениями, то Fleet использовал модули systemd для запуска контейнеров или любых других процессов на узлах кластера.

2. Легкость управления

Установка Fleet проводилась значительно проще и быстрее по сравнению с Kubernetes. Чтобы запустить свои службы в кластере, необходимо было отправить обычные модули systemd в сочетании с несколькими свойствами, специфичными для Fleet. То есть для управления кластером было достаточно знаний по работе с systemd.

3. Требования к платформе для развертывания

Fleet изначально разрабатывался на базе CoreOS. Kubernetes в настоящее время поддерживает практически все виды ОС.

4. Производительность

Сложно оценить, так как продукт более не поддерживается. Вероятно, Fleet был быстрее, учитывая его архитектурную простоту и ограниченную функциональность.

5. Ограничения на количество узлов и контейнеров в кластере

Fleet уступал по масштабируемости. В последней версии продукта не рекомендовалось запускать кластеры более 100 узлов или с более чем 1000 служб. Kubernetes сейчас поддерживает до 5 000 узлов и 300 000 контейнеров в кластере.

6. Конфигурация как код

В документации Fleet отсутствуют данные о возможности загрузки определений приложений из YAML или JSON, доступной в Kubernetes. Но формировавшиеся представления сохранялись в etcd в формате JSON. Также Fleet предоставлял API для управления состоянием кластера с использованием JSON: создание и удаление модулей, изменение желаемого состояния, вывод списка модулей.

7. Шаблоны

Fleet поддерживал несколько простых шаблонов развертывания на основе настраиваемых параметров модуля systemd. В них, например, можно было использовать определения места запуска контейнеров (Affinity и Anti-Affinity), похожие на селекторы Kubernetes. Однако используемый в Kubernetes шаблонизатор Helm более мощный инструмент.

8. Сети

Fleet это низкоуровневое решение, и его нельзя сравнивать с K8s в плане организации сетей.

9. Возможность обнаружения сервисов

Присутствует в обоих. Но, в отличие от Kubernetes, Fleet не поддерживал интеграцию с DNS. Взамен этого он предлагал модель Sidekick, в которой отдельный агент обнаружения запускался рядом с основным контейнером.

10. Автомасштабирование

В документации Fleet не описана возможность автомасштабирования.

11. Выполнение обновлений и отката

Fleet не поддерживал последовательные обновления, в отличие от K8s: новые модули (Units) планировались, а старые уничтожались вручную.

12. Отказоустойчивость

Обеспечивается в обоих оркестраторах. Архитектура Fleet разработана так, чтобы быть отказоустойчивой: если машина выходила из строя, любые запланированные на ней задания (Unit) перезапускались на новых хостах.

13. Мониторинг

Fleet уступал Kubernetes по возможностям мониторинга. Он поддерживал в экспериментальном режиме получение незначительного количества метрик в формате Prometheus. О возможности использования других инструментов логирования и мониторинга (ELK и прочее) в документации не сказано.

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

Fleet как низкоуровневое решение предлагал меньше возможностей в плане безопасности по сравнению с K8s. Например, он не поддерживал контроль доступа (Access Control List, ACL): все, кто имели доступ к etcd, могли управлять Fleet. Также в нем не было инструментов для управления конфиденциальной информацией (логины и пароли).

V. Преимущества и недостатки систем оркестрации

1. Docker Swarm

Преимущества:

1. Ниже порог входа: быстро устанавливается, легок в изучении, интегрирован с Docker Compose и Docker CLI.
2. Позволяет быстрее разворачивать контейнеры.

Недостатки:

1. Уступает Kubernetes в плане администрирования, особенно в Production-среде.
2. Отсутствует автомасштабирование.
3. Проигрывает в плане поддержки сообществом: инструментарий намного меньше, чем у Kubernetes, что приводит к отсутствию готовых решений и необходимости многое настраивать самостоятельно.

Для каких задач подходит: в небольших проектах, где предпочтение отдается простоте и быстрой разработке.

2. Nomad

Преимущества:

1. Прост в установке и эксплуатации, так как сосредоточен только на управлении кластером.
2. Поддерживает различные виды рабочих нагрузок.

Недостатки:

1. Ограниченная функциональность. Требуется установка сторонних инструментов для решения задач, которые K8s реализует по умолчанию: Autodiscovery, управление секретами.
2. Проигрывает Kubernetes в плане поддержки сообществом.

Для каких задач подходит:

1. Для небольших/средних команд с ограниченными возможностями поддержки оркестратора.
2. При сочетании контейнерных и неконтейнерных нагрузок.
3. При построении сетей L2 с малым количеством контейнеров.

3. Apache Mesos (+ Maraphon, Aurora)

Преимущества:

1. Высокая масштабируемость.
2. Поддержка контейнерных и неконтейнерных приложений, возможность совмещения нескольких фреймворков (включая Kubernetes).

Недостатки:

1. Сложность администрирования.
2. Проигрывает в плане поддержки сообществом.

Для каких задач подходит:

1. Масштабные проекты с участием нескольких центров обработки данных и/или десятков тысяч узлов.
2. При сочетании контейнерных и неконтейнерных нагрузок. В частности, при работе с приложениями по обработке данных: Hadoop, Kafka, Spark.
3. Комбинация Apache Mesos и Aurora отлично подходила для оркестрации задач, не связанных с контейнерами, но требующих аналогичной обработки, например перезапуска в случае сбоя.

4. Fleet

Преимущества:

1. Простота

Недостатки:

1. Ограниченная функциональность
2. Продукт более не поддерживается

Для каких задач подходил: можно было использовать в качестве основы для запуска инструментов оркестровки более высокого уровня например, для распространения агентов Kubernetes и двоичных файлов на машины в кластере.

5. Kubernetes

Преимущества:

1. Самодостаточный инструмент оркестровки, в который встроено множество сервисов. Kubernetes предоставляет все функции, необходимые для запуска приложений на основе контейнеров, включая: управление кластером, планирование, обнаружение служб, мониторинг, управление безопасностью и многое другое.
2. Поддерживается фондом CNCF (Cloud Native Computing Foundation). У Kubernetes самое впечатляющее по числу участников сообщество среди всех оркестраторов, что обеспечивает богатый инструментарий и большое число готовых решений.
3. Это бесплатный инструмент с открытым исходным кодом, который работает в любой ОС.

Недостатки:

1. Сложнее настроить вручную, хотя это можно решить с помощью использования Kubernetes aaS.
2. Предназначен только для контейнерных приложений.
3. Меньшее количество поддерживаемых узлов по сравнению с Nomad и Mesos.

Для каких задач подходит: идеален в качестве платформы корпоративного уровня, способной запускать тысячи контейнеров в облаке и управлять ими.

Как перейти на Kubernetes с других оркестраторов

Предположим, вы использовали одно из рассмотренных решений и задумались о переходе на Kubernetes.

Что теперь предпринять?

Продумайте окружение. Kubernetes интегрирован со множеством инструментов мониторинга, логирования, построения CI/CD и так далее. Возможно, вы не захотите ограничиться лишь сменой оркестратора и построите более обширную инфраструктуру по сравнению с текущей, максимально задействовав возможности экосистемы K8s.

Перепишите манифесты на YAML Kubernetes. Сложность операции будет определяться их количеством и особенностями прежнего оркестратора:

1. Переход с Docker Swarm наиболее прост. Можно либо самостоятельно переписать все манифесты, либо использовать доступные инструменты преобразования из файлов Docker Compose в YAML Kubernetes, например Kompose. Первый способ представляется более правильным, так как позволит учесть все преимущества Kubernetes, связанные с deployments, labels, tolerations и так далее. Второй способ позволит избежать переписывания, но менее нативен.
2. Переход с Nomad и Apache Mesos наиболее сложен, так как их манифесты не совместимы с Kubernetes. Скорее всего, переход с Apache Mesos/Maraphon будет проще, так как в нем использовались JSON-определения в отличие от Apache Mesos/Aurora с собственным синтаксисом (похожим на Python) и Nomad с его HCL.
3. Если вы использовали Fleet, то, вероятно, как основу для более высокоуровневого оркестратора. То есть для перехода на Kubernetes необходимо переписать манифесты, созданные для того оркестратора, что вы применяли. Либо ничего не переписывать, если у вас уже был Kubernetes поверх Fleet.

Разверните Kubernetes, вспомогательную инфраструктуру и настройте свой кластер. Если у вас нет команды, способной справиться с непростой задачей ручной установки, то можно использовать одно из готовых (Managed) решений. Их провайдеры не только предлагают услуги по развертыванию кластеров Kubernetes, но и оказывают дальнейшую техническую поддержку, а также могут помочь с миграцией (например, с Docker Swarm). В результате вы получите готовый кластер за считаные минуты и все преимущества Cloud Native-приложений.

При этом, если вы хотите по максимуму отказаться от администрирования кластера, с выбором провайдера тоже нужно не ошибиться: не все Managed-решения находятся в зрелом состоянии и позволяют снять с IT-отдела компании многие сложности работы с Kubernetes. Кроме того, не стоит забывать, что Managed-решения не серебряная пуля и кое-какой поддержкой кластера заниматься все равно придется.

Чек-лист: на что обратить внимание при выборе провайдера Kubernetes

Функциональность сервиса. Советуем выяснить, какие возможности провайдер предлагает из коробки. В первую очередь это способ хранения данных, масштабирование, балансировка нагрузки, безопасность, организация сетей. Все, что отсутствует в коробочном решении, вам, вероятно, придется настраивать самостоятельно.

Так, KaaS от Mail.ru Cloud Solutions из коробки включает:

• автоматическое масштабирование кластера до сотен узлов с использованием Kubernetes Cluster Autoscaler;
• наличие выделенных балансировщиков нагрузки для распределения трафика;
• интегрированные Persistent Volumes на базе надежного блочного хранилища CEPH, виртуального файлового хранилища или SSD/NVME-дисков, подключенных по iSCSI к каждому вычислительному серверу;
• собственный Terraform-провайдер для работы с инфраструктурой как кодом.

Совместимость со стандартными инструментами Kubernetes. Нужно проверить, поддерживает ли провайдер интеграцию с другими приложениями экосистемы K8s, например:

• Serverless: OpenFaaS, Kubeless;
• Service Mesh: Istio, Consul, Linkerd;
• мониторинг: Prometheus, Fluentd, Jaeger, OpenTracing;
• CI/CD: Gitlab, CircleCI, Travis CI;
• IaC (описание приложений): Terraform, Helm.

Возможность подключения других сервисов провайдера. Обратите внимание на дополнительные решения провайдера и возможность их использования в своих кластерах. KaaS от MCS позволяет подключить объектное хранилище (Cloud Storage) и DBaaS для хранения данных Stateful-приложений, а также его легко совместно использовать с другими PaaS, например Cloud Big Data. Например, централизованно разворачивать нужные сервисы и управлять ими на одной платформе.

Сертификация CNCF. Подтверждает то, что сервис отвечает всем функциональным требованиям сообщества Cloud Native Computing Foundation (CNCF) и совместим со стандартным Kubernetes API. MCS пока единственный в России облачный провайдер, получивший такую сертификацию.

Техническая поддержка. Как организована поддержка, бесплатная ли она, оказывает ли провайдер помощь в миграции данных и так далее.

Выводы: сравнительный анализ систем оркестрации

Результаты сравнения Kubernetes и других известных оркестраторов наглядно демонстрирует таблица ниже:

• самая удачная и удобная в использовании реализация;
• удовлетворительная реализация, уступающая другим по ряду параметров;
• реализация, уступающая другим по большинству параметров и/или требующая значительно больше времени и ресурсов для ее использования.

Как мы увидели, Kubernetes лидирует по многим показателям. Но есть и недостатки, и самый весомый из них высокий порог входа для новых пользователей при выборе ручной установки. Однако современный рынок предлагает множество Managed-решений, способных преодолеть эту сложность. Главное грамотно подойти к выбору между ними, взвесив все за и против.

Что еще почитать по теме:

1. Зачем крупным компаниям микросервисы, контейнеры и Kubernetes: как эти три технологии выводят IT на новый уровень.
2. 10 антипаттернов деплоя в Kubernetes: распространенные практики, для которых есть другие решения.
3. Наш Телеграм-канал Вокруг Kubernetes в Mail.ru Group.

Идея самостоятельно развернуть кластер Kubernetes на собственных серверах или в облаке выглядит привлекательной: кажется, что это дешевле, чем платить за Managed-решение от провайдера. На самом деле все не так однозначно: на практике можно обнаружить скрытые расходы и подводные камни.

При этом для крупных компаний Self-Hosted может быть вариантом, так как у них есть условно бесплатные ресурсы и штат специалистов для поддержки технологии, а иногда еще горячее желание построить и развивать свою платформу во что бы то ни стало. А вот с малым и средним бизнесом ситуация немного другая, решение нужно взвесить со всех сторон.

Я Дмитрий Лазаренко, директор по продукту облачной платформы Mail.ru Cloud Solutions (MCS). В статье расскажу, в чем особенности развертывания Self-Hosted-кластера Kubernetes и о чем нужно знать перед запуском.

Для старта понадобятся время, деньги и администраторы, разбирающиеся в Kubernetes

Первая статья расходов на специалистов, которые умеют работать с этой системой и смогут обслуживать кластер. Это дорогие ребята, на рынке их немного, и нанять трудно.

Почему Kubernetes сильно увеличивает расходы на специалистов? Вроде бы развернуть кластер несложно, для этого есть официальная документация и инсталляторы, например Kubespray или Kubeadm. Однако если в компании есть инженер, который может прочитать строчку документации и разобраться, как поставить Kubernetes на серверы с помощью одной команды, это еще не все, этим его работа не ограничится.

В реальности развернуть кластер только половина дела. В таком виде он будет работать до первой проблемы, которая неизбежно возникнет через неделю или месяц. Например, перестанут создаваться поды из-за неверной конфигурации ресурсов на controller-manager. Или кластер начнет работать нестабильно из-за проблем с дисками у etcd. Или запущенные СronJob из-за ошибок controller-manager начнут бесконечно плодить новые поды. Или в кластере будут возникать сетевые ошибки из-за неправильного выбора конфигурации DNS.

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

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

Скорее всего, понадобится человек на фултайм, который будет заниматься только Kubernetes, поддержкой и развитием кластера. В большой компании может родиться отдел для поддержки инфраструктуры.

Конечно, если запускать Kubernetes только ради деплоя контейнеров, то можно не разбираться и не развивать кластер. Но тогда возникает вопрос: зачем вам Kubernetes? Можно взять более простой в настройке и поддержке инструмент, тот же Docker Swarm. Если вы хотите от Kubernetes что-то простое, просто его не используйте. Нет смысла тратить время на развертывание кластера лишь ради запуска простого кода. Эта технология предназначена для проектов, где постоянно идет разработка, часто запускаются новые релизы и нужно выдерживать требования HighLoad.

По этой причине Self-Hosted Kubernetes в большинстве случаев могут успешно запустить только крупные компании, где есть возможность выделить сотрудников для обслуживания кластера и нет потребности экономить ресурсы.

Кроме того, самостоятельное развертывание кластера дело небыстрое. Если понадобится запустить кластер в короткие сроки для проекта или тестовых сред, то на Self-Hosted это не выйдет: развертывание займет несколько часов, а то и недель. К этому стоит быть готовыми. Для сравнения: в облаке вы запустите кластер KaaS за 10 минут и сможете сразу его использовать, но это получается потому, что над инфраструктурной частью уже заранее поработали специалисты провайдера.

Kubernetes требует прокачки: он не работает сам по себе

Как я уже говорил выше, Kubernetes отдельная экосистема, которой нужно заниматься и подключать к ней дополнительные инструменты. Если брать Self-Hosted, то все это придется делать самостоятельно.

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

Например, понадобится мониторить и сам кластер, и приложения в нем. Причем стандартного мониторинга через Zabbix вам не хватит, потребуется специфический Prometheus или Telegraph.

С логами аналогичная ситуация: из коробки вы получите только историю логов для уже запущенных приложений, при передеплое она исчезнет. Вручную собирать логи с Kubernetes не получится, нужно подключать сборщики логов вроде Fluentd и систему хранения, например Elasticsearch или Loki. Отдельно придется заниматься балансировкой нагрузки: понадобится отказоустойчивый балансер вроде MetalLB.

Системы хранения для Self-Hosted Kubernetes еще одна головная боль

Kubernetes изначально разработан для Stateless-приложений они ничего не хранят внутри контейнеров. При работе со Stateful-приложениями, хранящими данные, встает вопрос подключения внешних хранилищ.

Самый простой вариант, к которому часто прибегают, поднять один NFS-сервер, но это решение для бедных: оно не обеспечит высокую доступность и сохранность данных. Если в медленный и ненадежный NFS будут ходить продакшен-сервисы с важными данными, могут возникнуть большие проблемы.

Для нормальной работы приложения без изменения его логики понадобятся Persistent Volumes хранилища, связанные с подами. Они подключаются внутрь контейнеров как локальные директории, позволяя приложению хранить данные под собой. Среди рабочих вариантов CephFS, Glusterfs, FC (Fiber Channel), полный список СХД можно посмотреть в официальной документации.

Интеграция Kubernetes c Persistent Volumes нетривиальная задача. Чтобы развернуть тот же Ceph, недостаточно взять мануал с Хабра и выполнить ряд команд. Плюс в дальнейшем СХД должен кто-то заниматься опять нужен отдельный инженер, а то и несколько.

Если же Self-Hosted-кластер развернут не на железе, а на виртуальных машинах в облаке, то все немного проще собственный кластер Ceph поднимать не нужно. Можно взять кластер хранилища у провайдера и научить его работать с кластером K8s, если провайдер готов предоставить вам API к своей системе хранения данных, что есть не везде. Писать интеграцию при этом придется самостоятельно.

Правда, у провайдеров, предоставляющих IaaS, можно арендовать объектное хранилище или облачную СУБД, но только если логика приложения позволяет их использовать. А в Managed-решениях Kubernetes уже из коробки есть интегрированные Persistent Volumes.

Отказоустойчивость кластера отдельная проблема

С Kubernetes проще обеспечить отказоустойчивость приложений, однако потребуется еще и реализовать отказоустойчивость кластера.

В Kubernetes есть мастер-нода, непосредственно управляющая кластером и содержащая его конфигурацию, метаданные и статусы объектов Kubernetes. Отказоустойчивый кластер включает три мастер-ноды, отдельные от самого кластера и дублирующие друг друга. Каждая нода отдельный сервер или виртуальная машина, их не могут использовать бизнес-приложения. То есть их нужно отдельно подключать и обслуживать либо оплачивать аренду в облаке.

Это создает сложности для малого бизнеса: раньше для всех приложений требовалось всего два сервера, а с Kubernetes только ради отказоустойчивости нужно три дополнительных сервера.

Также в кластере Kubernetes есть прекрасная фича встроенный механизм самовосстановления. Если одна из нод выходит из строя, то все процессы, ранее работающие на этой ноде, автоматически перезапускаются на других нодах кластера. Вот только чтобы это произошло, на остальных нодах нужен резерв по ресурсам. И его нельзя ничем занимать, иначе приложения не смогут переехать в случае проблем.

Резерв зависит от того, какое количество вышедших из строя нод вероятно в вашем случае:

• Если у вас одна стойка с серверами в одном дата-центре, то одномоментно, скорее всего, выйдет из строя максимум одна нода на одном сервере, например из-за ошибок ОС. Значит, нужен резерв на одну ноду. Конечно, может сломаться стойка, но тут уже нужно резервирование не средствами Kubernetes.
• Если у вас несколько стоек с серверами, то есть вероятность потери одной стойки, например из-за проблем со свичем, когда все серверы в ней станут недоступны. Значит, нужен резерв в размере количества серверов в одной стойке.
• Если у вас несколько дата-центров, то в каждом нужно держать резерв по размеру другого дата-центра, чтобы приложения работали в случае его выхода из строя.

Если проще, то это выглядит так: когда в кластере 10 нод и вы хотите без проблем пережить потерю одной ноды, то вам потребуется 10-процентный запас ресурсов. Если же приложения должны работать даже при потере 50% кластера, значит, на всех нодах нужен запас в 50%.

При этом лучше, если ноды в кластере небольшие по объему, но их много. Допустим, у вас есть пул ресурсов 100 ГБ оперативной памяти и 100 ядер CPU. Такой объем позволяет запустить 10 виртуалок и 10 нод кластера Kubernetes. И в случае выхода из строя одной ноды вы теряете только 10% кластера.

На железных серверах такую конфигурацию не создашь. Например, используя 300 ГБ оперативной памяти и 50 ядер CPU, вы развернете всего 23 ноды кластера. И в случае выхода из строя одной ноды рискуете сразу потерять 3050% кластера.

Получается, что риск того, что кластер ляжет вследствие сбоя или непредсказуемой нагрузки, на традиционной инфраструктуре выше. Кроме того, может быть так: специалисты без достаточного опыта не всегда могут заранее предусмотреть проблемы, понять, в чем их причина, и быстро устранить.

Автомасштабирование кластера нетривиальная задача

Чтобы кластер всегда был готов к любой нагрузке и новые ноды подключались и отключались по необходимости, нужно реализовать автомасштабирование. То есть сделать так, чтобы ваши приложения автоматически получали нужные ресурсы в необходимом объеме.

Автоскейлинг приложений в кластере возможен на любой инфраструктуре это делается средствами Kubernetes. А вот автоскейлинг кластера, который позволяет автоматически подключать и отключать ноды при изменении нагрузки, на Bare Metal реализуется только покупкой дополнительных серверов. Значит, заказываем их и ждем сразу масштабироваться не выйдет.

Плюс если мы говорим о Self-Hosted на Bare Metal, то все серверы, необходимые для работы приложений на случай нагрузки, придется держать в рабочем состоянии и постоянно за них платить.

Если Self-Hosted-кластер развернут на IaaS, то схема похожая: инженер добавляет новую виртуальную машину и вносит ее в кластер. Другой вариант взять API провайдера, если он его предоставляет, подключить через него кластер Kubernetes, научить его запускать для себя новые серверы и так реализовать автомасштабирование. Но потребуется разрабатывать отдельное решение это сложная задача, предполагающая высокий уровень экспертности в Kubernetes и облаках.

Кроме того, для быстрого масштабирования Self-Hosted-кластера на IaaS придется резервировать нужное количество ресурсов провайдера и создавать из них новые виртуальные машины по мере надобности. И за эти зарезервированные ресурсы придется платить: практика брать плату за выключенные ресурсы бывает у реселлеров VMware. На нашей платформе в случае отключенных ВМ вы не платите за ресурсы, только за диски. В некоторых Managed-решениях автоскейлинг включается по кнопке, уточните эту возможность у вашего провайдера.

Подводные камни Self-Hosted Kubernetes

1. Для самостоятельной эксплуатации кластера нужен специалист на фултайм, который хорошо знает технологию и понимает, как все работает внутри Kubernetes.
2. В кластере потребуется настроить мониторинг, сбор логов, балансировку нагрузки и многое другое.
3. Отдельная проблема развернуть и интегрировать с кластером систему хранения данных.
4. Чтобы обеспечить отказоустойчивость кластера, потребуются дополнительные серверы или виртуалки это дополнительные затраты.
5. Для масштабирования кластера под нагрузкой нужен запас серверов или виртуалок это еще одна статья дополнительных расходов.

Рассчитывайте ваши возможности при старте проекта. То, какие ресурсы есть у вашей компании, ваш бэкграунд, навыки и другие детали сильно влияют на выбор решения, насколько вам будет выгодно разворачивать Kubernetes самостоятельно или лучше это сделать в облаке с помощью готового сервиса. И не забываем главный вопрос всего Kubernetes: нужна ли вообще эта технология на вашем проекте, как и для чего вы собираетесь ее использовать?

Тут можно почитать, как устроен наш Kubernetes aaS на платформе Mail.ru Cloud Solutions: что у него под капотом и что в него еще входит, кроме собственно Kubernetes.

Важная характеристика Docker-контейнеров эфемерность. В любой момент контейнер может рестартовать: завершиться и вновь запуститься из образа. При этом все накопленные в нём данные будут потеряны. Но как в таком случае запускать в Docker приложения, которые должны сохранять информацию о своём состоянии? Для этого есть несколько инструментов.

В этой статье рассмотрим docker volumes, bind mount и tmpfs, дадим советы по их использованию, проведём небольшую практику.

Особенности работы контейнеров

Прежде чем перейти к способам хранения данных, вспомним устройство контейнеров. Это поможет лучше понять основную тему.

Контейнер создаётся из образа, в котором есть всё для начала его работы. Но там не хранится и тем более не изменяется ничего важного. В любой момент приложение в контейнере может быть завершено, а контейнер уничтожен, и это нормально. Контейнер отработал выкидываем его и собираем новый. Если пользователь загрузил в приложение картинку, то при замене контейнера она удалится.

На схеме показано устройство контейнера, запущенного из образа Ubuntu 15.04. Контейнер состоит из пяти слоёв: четыре из них принадлежат образу, и лишь один самому контейнеру. Слои образа доступны только для чтения, слой контейнера для чтения и для записи. Если при работе приложения какие-то данные будут изменяться, они попадут в слой контейнера. Но при уничтожении контейнера слой будет безвозвратно потерян, и все данные вместе с ним.

В идеальном мире Docker используют только для запуска stateless-приложений, которые не читают и не сохраняют данные о своём состоянии и готовы в любой момент завершиться. Однако в реальности большинство программ относятся к категории stateful, то есть требуют сохранения данных между перезапусками.

Поэтому нужны способы сделать так, чтобы важные изменяемые данные не зависели от эфемерности контейнеров и, как бонус, были доступными сразу из нескольких мест.

В Docker есть несколько способов хранения данных. Наиболее распространенные:

• тома хранения данных (docker volumes),
• монтирование каталогов с хоста (bind mount).

Особые типы хранения:

• именованные каналы (named pipes, только в Windows),
• монтирование tmpfs (только в Linux).

На схеме показаны самые популярные типы хранения данных для Linux: в памяти (tmpfs), в файловой системе хоста (bind mount), в томе Docker (docker volumes). Разберём каждый вариант.

Тома (docker volumes)

Тома рекомендуемый разработчиками Docker способ хранения данных. В Linux тома находятся по умолчанию в /var/lib/docker/volumes/. Другие программы не должны получать к ним доступ напрямую, только через контейнер.

Тома создаются и управляются средствами Docker: командой docker volume create, через указание тома при создании контейнера в Dockerfile или docker-compose.yml.

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

Один том может быть примонтирован одновременно в несколько контейнеров. Когда никто не использует том, он не удаляется, а продолжает существовать. Команда для удаления томов: docker volume prune.

Можно выбрать специальный драйвер для тома и хранить данные не на хосте, а на удалённом сервере или в облаке.

Для чего стоит использовать тома в Docker:

• шаринг данных между несколькими запущенными контейнерами,
• решение проблемы привязки к ОС хоста,
• удалённое хранение данных,
• бэкап или миграция данных на другой хост с Docker (для этого надо остановить все контейнеры и скопировать содержимое из каталога тома в нужное место).

Монтирование каталога с хоста (bind mount)

Это более простая концепция: файл или каталог с хоста просто монтируется в контейнер.

Используется, когда нужно пробросить в контейнер конфигурационные файлы с хоста. Например, именно так в контейнерах реализуется DNS: с хоста монтируется файл /etc/resolv.conf.

Другое очевидное применение в разработке. Код находится на хосте (вашем ноутбуке), но исполняется в контейнере. Вы меняете код и сразу видите результат. Это возможно, так как процессы хоста и контейнера одновременно имеют доступ к одним и тем же данным.

Особенности bind mount:

1. Запись в примонтированный каталог могут вести программы как в контейнере, так и на хосте. Это значит, есть риск случайно затереть данные, не понимая, что с ними работает контейнер.
2. Лучше не использовать в продакшене. Для продакшена убедитесь, что код копируется в контейнер, а не монтируется с хоста.
3. Для успешного монтирования указывайте полный путь к файлу или каталогу на хосте.
4. Если приложение в контейнере запущено от root, а совместно используется каталог с ограниченными правами, то в какой-то момент может возникнуть проблема с правами на файлы и невозможность что-то удалить без использования sudo.

Когда использовать тома, а когда монтирование с хоста

Монтирование tmpfs

Tmpfs временное файловое хранилище. Это некая специально отведённая область в оперативной памяти компьютера. Из определения выходит, что tmpfs не лучшее хранилище для важных данных. Так оно и есть: при остановке или перезапуске контейнера сохранённые в tmpfs данные будут навсегда потеряны.

На самом деле tmpfs нужно не для сохранения данных, а для безопасности, полученные в ходе работы приложения чувствительныеданные безвозвратно исчезнут после завершения работы контейнера. Бонусом использования будет высокая скорость доступа к информации.

Например, приложение в контейнере тормозит из-за того, что в ходе работы активно идут операции чтения-записи, а диски на хосте не очень быстрые. Если вы не уверены, в какой каталог идёт эта нагрузка, можно применить к запущенному контейнеру команду docker diff. И вот этот каталог смонтировать как tmpfs, таким образом перенеся ввод-вывод с диска в оперативную память.

Такое хранилище может одновременно работать только с одним контейнером и доступно только в Linux.

Общие советы по использованию томов

Монтирование в непустые директории

Если вы монтируете пустой том в каталог контейнера, где уже есть файлы, то эти файлы не удалятся, а будут скопированы в том. Этим можно пользоваться, когда нужно скопировать данные из одного контейнера в другой.

Если вы монтируете непустой том или каталог с хоста в контейнер, где уже есть файлы, то эти файлы тоже не удалятся, а просто будут скрыты. Видно будет только то, что есть в томе или каталоге на хосте. Похоже на простое монтирование в Linux.

Монтирование служебных файлов

С хоста можно монтировать любые файлы, в том числе служебные. Например, сокет docker. В результате получится docker-in-docker: один контейнер запустится внутри другого. Выглядит как бред, но в некоторых случаях бывает оправдано. Например, при настройке CI/CD.

Монтирование /var/lib/docker

Разработчики Docker говорят, что не стоит монтировать с хоста каталог /var/lib/docker, так как могут возникнуть проблемы. Однако есть некоторые программы, для запуска которых это необходимо.

--volume | -v

--tmpfs

$ docker volumeCommands:  create   Create a volume (Создать том)  inspect  Display detailed information on one or more        volumes (Отобразить детальную информацию)  ls    List volumes (Вывести список томов)  prune Remove all unused volumes (Удалить все неиспользуемые тома)  rm    Remove one or more volumes (Удалить один или несколько томов)

$ docker volume create slurm-storageslurm-storage

$ docker volume lsDRIVER  VOLUME NAMElocal   slurm-storage

$ docker inspect slurm-storage[    {        "CreatedAt": "2020-12-14T15:00:37Z",        "Driver": "local",        "Labels": {},        "Mountpoint": "/var/lib/docker/volumes/slurm-storage/_data",        "Name": "slurm-storage",        "Options": {},        "Scope": "local"    }]

$ docker run --rm -v slurm-storage:/data -it ubuntu:20.10 /bin/bash# echo $RANDOM > /data/file# cat /data/file13279# exit

$ docker run --rm -v slurm-storage:/data -it centos:8 /bin/bash -c "cat /data/file"13279

$ docker run -v /srv:/host/srv --name slurm --rm -it ubuntu:20.10 /bin/bash

$ docker run -v /srv:/host/srv -v slurm-storage:/data --name slurm --rm -it ubuntu:20.10 /bin/bash

$ docker run --volumes-from slurm --name backup --rm -it centos:8 /bin/bash

$ docker run -v newslurm:/newdata -v /srv:/host/srv -v slurm-storage:/data --name slurm --rm -it ubuntu:20.10 /bin/bash

$ docker volume lsDRIVER  VOLUME NAMElocal   slurm-storagelocal   newslurm

$ docker run -v /anonymous -v newslurm:/newdata -v /srv:/host/srv -v slurm-storage:/data --name slurm --rm -it ubuntu:20.10 /bin/bash

$ docker run -v /anonymous -v newslurm:/newdata -v /srv:/host/srv -v slurm-storage:/data --name slurm -it ubuntu:20.10 /bin/bash$ docker volume lsDRIVER  VOLUME NAMElocal     04c490b16184bf71015f7714b423a517ce9599e9360af07421ceb54ab96bd333local   newslurmlocal   slurm-storage

$ sudo dockerd --storage-opt dm.basesize=40G

$ sudo service docker stop$ sudo rm -rf /var/lib/docker

Если вам интересно узнать подробнее о работе с данными в Docker и других возможностях технологии, приглашаем на двухдневный онлайн-интенсив в феврале. Будет много практики.

Автор статьи: Александр Швалов, практикующий инженер Southbridge, Certified Kubernetes Administrator, автор и разработчик курсов Слёрм.