Архитектура контейнерной платформы Meituan и практика контейнерных технологий

Эта статья составлена на основе выступления Оуян Цзяня, технического директора отдела инфраструктуры Meituan / Центра исследований и разработок контейнеров, на QCon 2018 (Всемирная конференция по разработке программного обеспечения).

задний план

Платформа управления контейнерным кластером Meituan называется HULK. ХАЛК в анимации Marvel станет «Халком», когда он злится.Эта функция очень похожа на «эластичное масштабирование» контейнеров, поэтому мы назвали эту платформу ХАЛКОМ. Кажется, есть некоторые компании, чьи контейнерные платформы также называются этим именем, что чисто случайно.

В 2016 году Meituan начал использовать контейнеры, в то время Meituan уже имел определенный масштаб, и до использования контейнеров существовали различные системы, в том числе CMDB, управление услугами, мониторинг и оповещение, платформа публикации и т. д. Когда мы изучаем технологию контейнеров, трудно отказаться от наших первоначальных активов. Следовательно, первым шагом контейнеризации является открытие взаимодействия между жизненным циклом контейнера и этими платформами, например, приложение/создание контейнера, удаление/выпуск, выпуск, миграция и т. д. Затем мы проверили осуществимость контейнера и подтвердили, что контейнер можно использовать в качестве рабочей среды основного онлайн-бизнеса.

В 2018 году, после двух лет работы и практических исследований, мы обновили контейнерную платформу, которая представляет собой платформу управления контейнерным кластером HULK 2.0.

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

Статус использования контейнеров Meituan выглядит следующим образом: в настоящее время существует более 3000 онлайн-сервисов и более 30 000 экземпляров контейнеров.Многие основные сервисы связи с большим параллелизмом и низкими требованиями к задержке стабильно работают на HULK. В этой статье в основном представлены некоторые из наших методов работы с контейнерными технологиями, которые относятся к оптимизации и полировке базовых систем.

Основная архитектура контейнерной платформы Meituan

Во-первых, давайте введем инфраструктуру платформы контейнеров Meituan. Я считаю, что архитектура контейнерной платформы каждой компании обычно похожа.

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

Кроме того, контейнеры обеспечивают эластичное расширение емкости, которое может динамически увеличивать и уменьшать количество узлов контейнера служб в соответствии с определенными эластичными политиками, тем самым динамически настраивая возможности обработки служб. Также есть специальный модуль — «сервисный портрет», его основная функция — лучше выполнять планирование контейнеров и оптимизировать распределение ресурсов за счет сбора и подсчета запущенных индикаторов экземпляров сервисных контейнеров. Например, вы можете определить, является ли служба интенсивной с точки зрения вычислений или операций ввода-вывода, на основе использования ЦП, памяти, операций ввода-вывода и т. д. экземпляра контейнера службы, и попытаться объединить дополнительные контейнеры при планировании. В качестве другого примера мы можем знать, что каждый экземпляр контейнера службы будет иметь около 500 процессов во время выполнения, и мы добавим разумный лимит процессов к контейнеру при создании контейнера (например, максимум 1000 процессов), чтобы предотвратить использование контейнером слишком большого количества системных ресурсов в случае возникновения проблемы. Если контейнер этой службы внезапно обращается для создания 20 000 процессов во время его работы, у нас есть основания полагать, что в бизнес-контейнере обнаружена ошибка, и контейнер ограничен предыдущими ограничениями ресурсов, и выдается сигнал тревоги для уведомления бизнес, чтобы справиться с этим вовремя.

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

Нижний уровень — это наша среда выполнения контейнера.Meituan использует основное контейнерное решение Linux + Docker, а HULK Agent — наш агент управления на сервере.

Конкретно разверните предыдущую «среду выполнения контейнера», вы можете увидеть эту архитектурную диаграмму, которая представлена в порядке снизу вверх:

Самый нижний слой представляет собой ЦП, память, диск и сеть этих основных физических ресурсов.
На один уровень выше мы используем CentOS7 в качестве основной операционной системы, а версия ядра Linux — 3.10. Основываясь на ядре по умолчанию дистрибутива CentOS, мы добавили некоторые новые функции, разработанные Meituan для контейнерных сценариев, и оптимизировали некоторые параметры ядра для предприятий, основанных на услугах с высокой степенью параллелизма и малой задержкой.
На один уровень выше мы используем Docker, который поставляется с дистрибутивом CentOS, текущая версия — 1.13, и снова были добавлены некоторые из наших собственных функций и улучшений. Агент HULK — это агент управления хостом, разработанный нами, который управляет агентом на хосте. Агент Falcon существует как в хосте, так и в контейнере, его функция состоит в том, чтобы собирать различные основные индикаторы мониторинга хоста и контейнера и сообщать об этом на фоновую платформу и платформу мониторинга.
Верхний слой – это сама емкость. Сейчас мы в основном поддерживаем контейнеры CentOS 6 и CentOS 7. В CentOS 6 есть процесс инициализации контейнера, который является процессом № 1 внутри нашего контейнера разработки, его функция заключается в инициализации контейнера и запуске бизнес-процесса. В CentOS 7 мы используем systemd, поставляемый с системой, как процесс 1 в контейнере. Наши контейнеры поддерживают множество основных языков программирования, включая Java, Python, Node.js, C/C++ и другие. Над языковым уровнем находятся различные прокси-службы, в том числе агенты управления службами, агенты журналов, агенты шифрования и т. д. В то же время наш контейнер также поддерживает некоторые бизнес-среды в Meituan, такие как установленная информация, информация о зоне ответственности и т. д., а с помощью системы управления услугами можно реализовать интеллектуальную маршрутизацию вызовов службы.

Meituan в основном использует компоненты с открытым исходным кодом серии CentOS, потому что мы считаем, что Red Hat обладает сильной технической силой с открытым исходным кодом.По сравнению с версией, непосредственно используемой сообществом с открытым исходным кодом, мы надеемся, что версия Red Hat с открытым исходным кодом может помочь решить большинство системных проблем. Мы также обнаружили, что даже при развернутых компонентах CentOS с открытым исходным кодом все еще можно столкнуться с проблемами, которые не были решены сообществом и Red Hat. В определенной степени это также свидетельствует о том, что крупные отечественные интернет-компании достигли лидирующего мирового уровня по сценариям применения технологий, масштабу и сложности, поэтому они столкнутся с этими проблемами раньше сообщества и раньше клиентов Red Hat.

Некоторые проблемы с контейнерами

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

Изоляция включает в себя два уровня: первый вопрос — сможет ли контейнер правильно понять собственную конфигурацию ресурсов; второй вопрос — будут ли контейнеры, работающие на одном сервере, влиять друг на друга. Например, количество операций ввода-вывода определенного контейнера очень велико, что увеличит задержку обслуживания других контейнеров на том же хосте.
Стабильность: это означает, что после высокого давления, крупномасштабной и длительной работы системные функции могут стать нестабильными.Например, контейнеры нельзя создавать или удалять, а проблемы с программным обеспечением могут вызывать такие проблемы, как зависание или простои.
Производительность: при сравнении технологии виртуализации и контейнерной технологии обычно считается, что эффективность выполнения контейнера будет выше, но на практике мы столкнулись с некоторыми частными случаями: один и тот же код находится на той же конфигурации контейнера, пропускная способность сервиса, Задержка ответа не такая хорошая, как у виртуальной машины.
Продвижение: После того, как мы в основном решили предыдущие проблемы, мы все еще можем столкнуться с ситуациями, когда предприятия не хотят использовать контейнеры.Одна из причин - технические факторы, такие как простота доступа к контейнерам, периферийные инструменты, экология и т. д. Стоимость с помощью контейнера. Продвижение — это не чисто технический вопрос, он тесно связан с внутренним этапом развития бизнеса компании, технической культурой, организационными установками и KPI.

Реализация контейнера

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

Кроме того, чтобы ограничить использование физических ресурсов пространством имен, необходимо наложить определенные ограничения на ЦП, память и другие ресурсы, которые может использовать процесс. Это технология Cgroup, Cgroup означает Control group. Например, контейнер 4c4g, о котором мы часто говорим, на самом деле ограничивает процессы, используемые в пространстве имен контейнера, и может использовать до 4 ядер вычислительных ресурсов и 4 ГБ памяти.

Короче говоря, ядро Linux предоставляет пространства имен для полной изоляции и Cgroups для ограничения ресурсов. namespace+Cgroup представляет собой базовую технологию контейнера (rootfs — это технология уровня файловой системы контейнера).

Решение Meituan, улучшение и оптимизация

изолировать

Я имел дело с виртуальными машинами и раньше, но пока я не использовал контейнер, я обнаружил, что информация о ЦП и памяти, отображаемая в контейнере, является информацией хоста сервера, а не информацией о конфигурации самого контейнера. До сих пор версия контейнера для сообщества остается прежней. Например, контейнер 4c4g может видеть ресурсы с 40 ЦП и 196 ГБ памяти внутри контейнера.Эти ресурсы фактически являются информацией хоста, на котором находится контейнер. Создается впечатление, что это как бы "самонадувание" контейнера, что он очень способен, но на самом деле это не так, и он принесет много проблем.

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

Работа по изоляции, которую мы выполняем, заключается в получении информации о памяти в контейнере, а ядро возвращает информацию о памяти контейнера в соответствии с информацией Cgroup контейнера (аналогично работе LXCFS).

Реализация изоляции информации о ЦП аналогична реализации памяти, поэтому я не буду здесь вдаваться в подробности, вот пример того, как количество ЦП влияет на производительность приложения.

Все мы знаем, что JVM GC (сборка объектов мусора) оказывает определенное влияние на производительность выполнения Java-программ. JVM по умолчанию использует формулу «ParallelGCThreads = (ncpus

Явная передача параметра запуска JVM "-XX:ParallelGCThreads" сообщает JVM, что следует запустить несколько параллельных потоков GC. Его недостаток в том, что требуется бизнес-осведомленность, а для разных настроенных контейнеров передаются разные параметры JVM.
Используйте взломанный glibc в контейнере, чтобы JVM (через системный вызов sysconf) могла правильно получить количество ресурсов ЦП контейнера. Это то, что мы использовали некоторое время. Преимущество в том, что бизнесу не нужно быть в курсе, и он может автоматически адаптироваться к контейнерам с разными конфигурациями. Недостатком является то, что необходимо использовать модифицированный glibc, а также существуют определенные затраты на обновление и обслуживание.Если используемый образ является родным glibc, проблема все еще существует.
За счет усовершенствования ядра на новой платформе мы можем получить правильное количество ресурсов ЦП в контейнере и сделать его прозрачным для бизнеса, образа и языка программирования (аналогичные проблемы могут также повлиять на производительность OpenMP, Node.js и другие приложения).

На некоторое время наши контейнеры были запущены с корневыми привилегиями, и способ сделать это, это было добавить параметр «PRIVILEGED = TRUE» в Docker Run. Это обширное использование позволяет контейнерам видеть диски всех контейнеров на сервере, где они расположены, ведущие к вопросам безопасности и производительности. Проблемы безопасности хорошо поняты, но почему это приводит к вопросам производительности? Вы можете представить сценарий, где каждый контейнер выполняет сканирование состояния диска. Конечно, проблема чрезмерных разрешений также отражена в том, что операция монтажа может быть выполнена по желанию, время NTP может быть изменена по желанию, и так далее.

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

В Linux есть два типа ввода-вывода: прямой ввод-вывод и буферизованный ввод-вывод. Прямой ввод-вывод записывает непосредственно на диск, а буферизованный ввод-вывод сначала записывает в кэш, а затем на диск.В большинстве случаев это буферизованный ввод-вывод.

Используемое нами ядро Linux 3. X. В версии сообщества все контейнеры Buffer IO совместно используют кеш ядра, и кеш не изолирован, и нет ограничения скорости, что приводит к тому, что контейнеры с большим количеством операций ввода-вывода легко влияют на другие контейнеры на тот же хозяин. Изоляция кеша буфера ввода-вывода и ограничение скорости реализованы Cgroup V2 в Linux 4.X.Есть очевидные улучшения.Мы также опираемся на идею Cgroup V2 для достижения той же функции в нашем ядре Linux 3.10: каждый контейнер основан на своя собственная. Существует соответствующая доля кэша ввода-вывода в конфигурации памяти кэша, а скорость, с которой данные кэша записываются на диск, ограничена конфигурацией ввода-вывода Cgroup контейнера.

Сам Docker поддерживает больше ограничений ресурсов Cgroup для контейнеров, но меньше параметров, которые можно передать, когда K8s вызывает Docker.Чтобы уменьшить взаимное влияние между контейнерами, мы устанавливаем разные ресурсы для контейнеров разных сервисов на основе распределения ресурсов сервисных портретов. Ограничения, помимо общего ЦП, памяти, есть ограничения ввода-вывода, ограничения ulimit, ограничения PID и так далее. Поэтому мы расширили возможности K8 для выполнения этих задач.

В компаниях часто создаются файлы дампа ядра при использовании контейнеров.Например, когда доступ к памяти программы C/C++ выходит за пределы или когда система находится в состоянии OOM, система решает завершить процесс, занимающий много памяти, и файл дампа ядра создается по умолчанию.

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

С этой целью мы изменили процесс дампа ядра, чтобы записать файл дампа в собственную файловую систему контейнера и использовать собственный предел пропускной способности Cgroup IO контейнера.

стабильность

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

На стороне ядра Meituan обнаружил проблему с реализацией лимита ввода-вывода буфера ядра 4.x, которая была подтверждена и исправлена сообществом. Мы также разработали серию исправлений CentOS Ext4, которые решили проблему частых зависаний процессов в течение определенного периода времени.

Мы столкнулись с двумя критическими проблемами стабильности Red Hat Docker:

После перезапуска службы Docker выполнение Docker не может войти в контейнер, что более сложно. Мы использовали nsenter для замены Docker exec и дали положительный отзыв RedHat, прежде чем решить эту проблему. Позже это было исправлено в обновлении от Red Hat ранее в этом году.access.RedHat.com/errata/RH БА...
При определенных условиях Docker Daemon будет паниковать, из-за чего контейнер не может быть удален. С помощью нашей собственной отладки и сравнения последнего кода мы обнаружили, что проблема была решена в восходящем потоке Docker, а также была быстро решена обратная связь с Red Hat.GitHub.com/проект атом…

Сталкиваясь с системным ПО сообщества open source, таким как ядро системы, Docker и K8s, существует точка зрения: нам не нужно самостоятельно анализировать проблему, нам достаточно получать последние обновления от сообщества. Однако мы не согласны, мы считаем, что способности самой технической команды очень важны, в основном по следующим причинам:

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

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

представление

Производительность контейнерной платформы в основном включает два аспекта:

Производительность бизнес-служб, работающих в контейнерах.
Выполнение операций с контейнером (создание, удаление и т.д.).

На приведенном выше рисунке показан пример нашего распределения ЦП.Основной сервер, который мы используем, представляет собой двусторонний 24-ядерный сервер, включающий два узла, каждый из которых имеет 12 ядер, и в общей сложности 48 логических ЦП, включая гиперпоточность. Он относится к типичной архитектуре NUMA (неоднородный доступ к памяти): каждый узел в системе имеет свою собственную память, и скорость процессора в узле, обращающемся к собственной памяти, намного выше (примерно в два раза хуже), чем при доступе к памяти. память другого узла.

В прошлом мы сталкивались с проблемой, связанной с тем, что сетевые прерывания концентрируются на CPU0, что может привести к увеличению задержки в сети или даже к потере пакетов при интенсивном трафике. Чтобы обеспечить пропускную способность сети, мы выделили 8 логических ЦП из узла 0 для обработки сетевых прерываний и задач в хост-системе, таких как распаковка изображений и другие задачи с высокой загрузкой ЦП.Эти 8 логических ЦП не запускают никаких контейнеров. Нагрузка.

Что касается планирования контейнеров, мы стараемся максимально не распределять ЦП между узлами.Практика показала, что доступ к памяти между узлами оказывает большее влияние на производительность приложения. В некоторых сценариях с интенсивными вычислениями размещение контейнеров в узле увеличит пропускную способность более чем на 30 %. Схема распределения на основе Node также имеет определенные недостатки: она приведет к увеличению фрагментации ЦП, чтобы более эффективно использовать ресурсы ЦП. В реальной системе мы выделим некоторые контейнеры служб, нечувствительные к ЦП, для использования ресурсов ЦП между узлами в соответствии с информацией профиля службы.

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

Оптимизация производительности: файловая система

Для оптимизации производительности файловой системы первым шагом является выбор модели.По статистике характеристик чтения и записи приложения мы выбираем файловую систему Ext4 (более 85% операций чтения и записи файлов приходится на файлы размером менее 1М).

Файловая система EXT4 имеет три режима журналов:

Журнал: подождите, пока метаданные и журналы данных будут помещены на диск, прежде чем записывать данные.
Упорядочено: записывает только журнал метаданных.Убедитесь, что данные были помещены на диск перед записью журнала метаданных.
Обратная запись: записывает только журнал метаданных и не гарантирует, что данные будут помещены на диск перед метаданными.

Мы выбрали режим обратной записи (по умолчанию ordered), который является самым быстрым из нескольких режимов монтирования, недостатком которого является то, что данные не так просто восстановить в случае сбоя. Большинство наших контейнеров не имеют состояния, и мы можем просто загрузить еще один на другой машине, когда он выйдет из строя. Поэтому в производительности и стабильности мы выбрали производительность. Контейнер предоставляет дополнительную файловую систему tmpfs на основе памяти для приложений, которая может повысить производительность служб с большим количеством временных файлов для чтения и записи.

Как показано на рисунке выше, создание виртуальной машины в Meituan занимает как минимум три шага со средним временем более 300 секунд. Среднее время создания контейнера с изображением — 23 секунды. Гибкость и скорость контейнера были значительно отражены.

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

На приведенном выше рисунке показана общая архитектура управления образами контейнеров Meituan, и ее функции заключаются в следующем:

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

Распределение изображения является важной связью, которая влияет на длительность расширения контейнера.

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

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

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

Для одноуровневой декомпрессии мы используем алгоритм параллельной декомпрессии, чтобы заменить алгоритм последовательной декомпрессии Docker по умолчанию, и pgzip, чтобы заменить gzip в реализации.

Образ Docker имеет многоуровневую структуру, а объединение слоев изображения представляет собой последовательную операцию «распаковки одного слоя и слияния одного слоя, затем распаковки одного слоя, а затем слияния одного слоя». На самом деле только слияние должно быть последовательным, распаковка может выполняться параллельно. Мы изменили многоуровневую декомпрессию на параллельную, распакованные данные сначала помещаются во временное хранилище и, наконец, последовательно объединяются в соответствии с зависимостями между слоями. Предыдущие изменения (параллельная распаковка всех слоев во временное пространство) почти удвоили количество дисковых операций ввода-вывода, а также сделали процесс распаковки недостаточно быстрым. Поэтому мы используем Ramdisk на основе памяти для хранения распакованных временных файлов, уменьшая накладные расходы, вызванные дополнительной записью файлов. Проделав вышеописанную работу, мы обнаружили, что многослойность контейнера также повлияет на время загрузки и распаковки. Приведенное выше изображение является результатом нашего простого теста: независимо от того, насколько многослойные изображения распаковываются параллельно, время распаковки может быть значительно улучшено, и улучшение более очевидно для изображений с большим количеством слоев.

продвигать

Первым шагом в продвижении контейнеров является умение назвать преимущества контейнеров.Мы считаем, что контейнеры имеют следующие преимущества:

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

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

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

Преимущества продукта: В определенной степени продвижение контейнерной платформы — это бизнес ToB.В первую очередь должен быть хороший продукт.По сравнению с предыдущим решением (виртуальная машина) у него много преимуществ.
Подключиться к существующей системе: этот продукт должен иметь возможность хорошо интегрироваться с существующей системой клиента, вместо того, чтобы позволить клиенту отменить все системы и начать все сначала.
Собственная платформа и инструменты для разработки приложений: этот продукт должен быть простым в использовании и иметь набор инструментов для работы.
Плавная миграция виртуальных машин в контейнеры: Лучше всего предоставить решение по миграции с исходного решения на новый продукт, и его легко реализовать.
Тесно работает с приложением RD: Для обеспечения хорошей поддержки клиентов (даже если некоторые проблемы не вызваны этим продуктом, активно помогайте решать).
Наклон ресурсов: поддержка прорывных новых технологий на стратегическом уровне: ресурсы перераспределяются в сторону контейнерных платформ, и нет достаточных причин не выделять ресурсы виртуальных машин в максимально возможной степени.

Суммировать

Контейнер Docker плюс оркестровка Kubernetes — одна из основных практик текущего облака контейнеров.Платформа управления контейнерным кластером Meituan HULK также использует такое решение. В этой статье в основном рассказывается о некоторых исследованиях и практиках, которые Meituan провела в области контейнерных технологий. Контент в основном охватывает некоторую работу по оптимизации, выполненную Meituan Container Cloud на уровне ядра Linux, Docker и Kubernetes, а также некоторые мысли о продвижении процесса контейнеризации в Meituan.Приглашаем к общению и обсуждению с нами.

об авторе

Оуян Цзянь окончил факультет компьютерных наук Университета Цинхуа в 2006 г. и имеет 12-летний опыт разработки и управления центрами обработки данных. Раньше он был штатным инженером VMware China, техническим директором Wushuang Technology и главным архитектором Zhongke Ruiguang. В настоящее время он является техническим директором отдела инфраструктуры Meituan / Центра исследований и разработок контейнеров, отвечая за контейнеризацию Meituan.

Предложения о работе

Команда инфраструктуры Meituan-Dianping ищет старших и старших технических экспертов по Java для работы в Пекине и Шанхае. Мы являемся основной командой, занимающейся исследованиями и разработками компонентов инфраструктуры на уровне компании и ведущих в отрасли, охватывающих такие технические области, как распределенный мониторинг, управление услугами, высокопроизводительная связь, промежуточное программное обеспечение сообщений, базовое хранилище, контейнеризация и планирование кластеров. Заинтересованные студенты могут отправить свои резюме наliuxing14@meituan.com.