Meituan прокомментировал практику управления кластером Kubernetes

задний план

Многие предприятия Meituan-Dianping, являющиеся ведущей внутренней платформой жизнеобеспечения, имеют очень важные и регулярные характеристики «пиков» и «впадин». Особенно в случае праздников или рекламных мероприятий трафик резко возрастет за короткий промежуток времени. Это предъявляет очень высокие требования к эластичности ресурсов и доступности кластерного центра, и в то же время сложность и стоимость системы в поддержке бизнес-трафика будут возрастать в геометрической прогрессии. Что нам нужно сделать, так это максимизировать пропускную способность кластера с ограниченными ресурсами, чтобы обеспечить взаимодействие с пользователем.

В этой статье будут представлены методы управления и использования кластера Meituan-Dianping Kubernetes, в том числе введение системы управления кластером и планирования Meituan-Dianping, управление и практика Kubernetes, оптимизация и преобразование Kubernetes, а также управление и оптимизация ресурсов.

Система управления и планирования кластера Meituan Dianping

Meituan Dianping уже много лет занимается управлением кластерами и оптимизацией ресурсов. В 2013 году он начал создавать метод доставки ресурсов на основе традиционной технологии виртуализации; в июле 2015 года он начал создавать полную систему управления и планирования кластера - HULK с целью продвижения контейнеризации услуг Meituan Dianping; в 2016 году он завершил контейнер на основе Docker. Собственная разработанная технология реализует способность эластичного масштабирования для повышения скорости доставки и удовлетворения потребностей в быстром расширении и сокращении, реализует эластичное расширение и сокращение, улучшает использование ресурсов, повышает эффективность бизнес-операций и обслуживания, а также разумно и эффективно снижать затраты на эксплуатацию и обслуживание ИТ предприятия; в 2018 году он начал управлять и планировать ресурсы на основе Kubernetes для дальнейшего повышения эффективности использования ресурсов.

Первоначально Meituan Dianping добилась гибкого масштабирования за счет самостоятельных исследований на основе контейнерной технологии Docker, в основном для устранения многих недостатков в механизме управления и развертывания на основе технологии виртуализации в ответ на быстрое расширение и сокращение услуг. Например, создание экземпляров ресурсов происходит медленно, работающая среда не может быть унифицирована, процесс развертывания и доставки экземпляров занимает много времени, эффективность восстановления ресурсов низкая, а эластичность низкая. После исследований и испытаний в сочетании с практическим опытом работы в отрасли мы решили разработать систему управления кластером и планирования на основе контейнерной технологии Docker, чтобы эффективно удовлетворить потребности быстрого расширения и сокращения и повысить эффективность использования ресурсов. Мы называем это "Халк" - ХАЛК, этот этап можно увидеть как ХАЛК1.0.

После этого, после непрерывных исследований и экспериментов в производственной среде, мы постепенно поняли, что просто довольствоваться эластичной масштабируемостью кластера недостаточно, а стоимость и эффективность — определенно более сложные проблемы, с которыми мы столкнемся в будущем. Мы извлекли уроки из опыта разработки, эксплуатации и обслуживания HULK 1.0 за последние 2 года, а также дополнительно оптимизировали и улучшили архитектуру и систему поддержки, а также использовали силу экологии и открытого исходного кода для расширения возможностей HULK, то есть внедрения Управление кластером с открытым исходным кодом и планирование Ожидается, что система Kubernetes еще больше повысит эффективность и стабильность управления и работы кластера, при этом снизив затраты на ресурсы. Поэтому мы перешли с платформы собственной разработки на систему Kubernetes с открытым исходным кодом и построили более интеллектуальную систему управления кластером и планирования на основе системы Kubernetes — HULK2.0.

Обзор архитектуры

На архитектурном уровне то, как HULK 2.0 может быть лучше многоуровнев и отделен от бизнеса верхнего уровня и базовой платформы Kubernetes, является приоритетом, который мы определили в начале проектирования. Мы ожидаем, что он будет удобен для использования в бизнесе и позволит максимально использовать возможности планирования Kubernetes, чтобы бизнес-уровню и пользователям не нужно было обращать внимание на детали взаимосвязей ресурсов, и что они хотят, то и получают; уровень отделен от базовой платформы Kubernetes и разделен на уровни, но остается совместимым с собственным API Kubernetes для доступа к кластеру Kubernetes. Таким образом, сложные, разнообразные и неоднородные потребности управления, с которыми сталкивается инфраструктура Meituan-Dianping, могут быть решены с помощью унифицированных, основных и стандартных отраслевых стандартов.

Введение в архитектуру

Платформа управления и планирования кластеров Meituan с точки зрения «сверху вниз» ориентирована на всю компанию.Она имеет различные основные направления деятельности, унифицированную платформу OPS и платформу портала.HULK не может настраивать интерфейсы и решения для каждой платформе, поэтому необходимо объединить различные абстрактные конвергенции бизнеса и требований и, наконец, защитить детали системы HULK через HULK API, чтобы отделить HULK от бизнес-стороны верхнего уровня. HULK API — это абстракция бизнес-уровня и требований к ресурсам, и это единственный способ для внешнего мира получить доступ к HULK.

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

Как видите, API HULK и API Kubernetes делят всю нашу систему на три слоя, что позволяет каждому слою сосредоточиться на своем модуле.

Управление и практика Kubernetes

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

Кластер Kubernetes является основой всего управления ресурсами и платформой кластера HULK Требованиями являются стабильность и масштабируемость, контролируемость рисков и пропускная способность кластера.

Текущее состояние работы кластера

Масштаб кластера: более 100 000 онлайн-экземпляров, развернутых в нескольких регионах и быстро растущих.
Бизнес-мониторинг и оповещение: кластер собирает данные о запуске и состоянии приложений, а container-init автоматически интегрирует информацию о бизнес-мониторинге.
Оповещение о состоянии ресурсов: отслеживайте и собирайте важные данные, такие как узел, модуль и контейнер, с точки зрения ресурсов, и своевременно узнавайте информацию об их состоянии, например, узел недоступен, контейнер постоянно перезагружается и т. д.
Регулярная проверка и согласование: автоматически проверяйте состояние всех хостов каждый день, включая оставшийся объем диска (том данных), количество D-процессов и статус хоста, а также синхронно проверяйте данные расширения AppKey и фактический Pod и контейнерные данные, для своевременного обнаружения несоответствий.
Визуализация данных кластера: Визуализация текущего состояния кластера, включая состояние ресурсов хоста, количество сервисов, количество Pod, уровень контейнеризации, статус сервисов, данные масштабирования и т. д., а также предоставление конфигурации сервисов на основе интерфейса, автономный хост и запись операции переноса Pod. .
Планирование и прогнозирование емкости: заблаговременное определение состояния ресурсов кластера и заблаговременная подготовка ресурсов; обнаружение трафика и пиковых нагрузок на основе правил и машинного обучения для обеспечения нормальной, стабильной и эффективной работы бизнеса.

Оптимизация и трансформация Kubernetes

оптимизация производительности kube-scheduler

У нас есть кластер, использующий планировщик версии 1.6.По мере того, как масштаб кластера продолжает расти, проблемы производительности и стабильности старой версии планировщика Kubernetes (версии до 1.10) постепенно становятся заметными.Из-за низкой пропускной способности планировщик, бизнес Сбой тайм-аута расширения В кластере с масштабом почти 3000 единиц планирование Pod заняло около 5 секунд. Планировщик Kubernetes — это модель планировщика с очередями.Как только количество подов, ожидающих пика расширения, становится слишком большим, время ожидания расширения последующих подов истекает. С этой целью мы значительно оптимизировали производительность планировщика и добились очень значительного улучшения.Согласно нашей фактической проверке производственной среды, производительность улучшилась более чем на 400% по сравнению с до оптимизации.

Рабочая модель планировщика Kubernetes выглядит следующим образом:

(планировщик kubernetes, картинка из сети)

Механизм прерывания ошибки предварительного выбора

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

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

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

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

Мы предоставили эту оптимизацию сообществу Kubernetes (см.PR), добавлена опция политики alwaysCheckAllPredicates, которая была выпущена в Kubernetes 1.10 и начиналась как политика планирования по умолчанию.Конечно, вы также можете использовать исходную политику планирования, установив alwaysCheckAllPredicates=true.

В реальных тестах планировщик может повысить производительность как минимум на 40%, если используемая версия Kube-scheduler ниже 1.10, рекомендуется попробовать обновиться до новой версии.

локальный оптимум

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

(картинка взята из интернета)

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

Предполагая, что в кластере всего 1000 узлов и процесс планирования PodA, 700 из них могут пройти предикаты (этап предварительного выбора), затем мы пройдем все узлы и найдем эти 700 узлов, а затем узнаем через счет сортировка Оптимальный узел узла NodeX. Однако используется локальный оптимальный алгоритм, то есть мы считаем, что пока мы можем найти N узлов и выбрать узел с наибольшим количеством очков среди этих N узлов, мы можем выполнить требования.Например, по умолчанию мы находим 100 Узлов, которые могут пройти Предикаты (этап предварительного отбора), то есть из этих 100 Узлов выбирается оптимальное решение. Конечно, глобального оптимального решения NodeX может и не быть в этих 100 Узлах, но мы также можем выполнить требования, выбрав среди этих 100 Узлов оптимальный NodeY. В лучшем случае нужно пройти 100 Узлов, чтобы найти эти 100 Узлов, или же он может пройти 200 или 300 Узлов и т. д., чтобы мы могли значительно сократить время расчета, и в то же время он не будет производить слишком много для нашего результаты планирования.

Локальная оптимальная стратегия разработана нами в сотрудничестве с сообществом, что также включает в себя детали того, как добиться справедливого планирования и оптимизации вычислительных задач (подробности см. В деталях).PR1,PR2), эта оптимизация была выпущена в Kubernetes версии 1.12 и используется в качестве текущей стратегии планирования по умолчанию, что может значительно улучшить производительность планирования, особенно в крупномасштабных кластерах, эффект очень очевиден.

кубелет макияж

Управляемость риска

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

Стратегия перезапуска контейнера

Обновление ядра — это ежедневная операция и операция обслуживания.При обновлении версии ядра путем перезапуска хоста мы обнаружили, что после перезапуска хоста указанный выше контейнер не может исцелить себя или версия после самовосстановления была неправильной, что может вызвать неудовлетворенность бизнеса. и причиной Это оказало большое давление на нашу работу и техническое обслуживание. Позже мы добавили в Kubelet стратегию перезапуска (Reuse), сохранив при этом нативную стратегию перезапуска (Rebuild), чтобы обеспечить сохранение информации о системном диске контейнера и диске данных, а также возможность самовосстановления контейнера после перезапуска хоста. .

Состояние IP поддерживается

В соответствии с сетевой средой Meituan Dianping мы разработали подключаемый модуль CNI, а также применили и повторно использовали IP-адрес на основе уникального идентификатора Pod. IP-адрес приложения можно повторно использовать после миграции пода и перезапуска контейнера, что дает много преимуществ для бизнеса в Интернете, эксплуатации и обслуживании.

Политика ограниченного выселения

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

Масштабируемость

Распределение ресурсов

Что касается масштабируемости Kubelet, мы улучшили работоспособность ресурсов, например, привязали Numa к контейнеру для повышения стабильности приложения, задали CPUShare для контейнера в соответствии с уровнем приложения, чтобы скорректировать вес планирования, привязали CPUSet к контейнеру. и так далее.

Улучшенный контейнер

Мы открыли и расширили возможности бизнеса по настройке контейнеров и поддержали бизнес в расширении таких параметров, как ulimit, io limit, pid limit и swap для своих собственных контейнеров, а также расширили возможности изоляции между контейнерами.

Обновление приложения на месте

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

зеркальное распределение

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

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

Управление ресурсами и оптимизация

Оптимизация ключевых технологий

Профиль службы: профилируйте производительность ЦП, памяти, сети, диска и сетевого ввода-вывода и нагрузку приложения, анализируйте характеристики приложения, спецификации ресурсов и типы приложений, а также реальное использование ресурсов в разное время, а затем выполнение услуги с точки зрения обслуживания и времени Корреляционный анализ для общего планирования и оптимизации развертывания.
Аффинити и взаимная эксклюзивность: какие приложения объединены таким образом, что общая вычислительная мощность относительно невелика, а пропускная способность относительно высока, они имеют определенное сходство; и наоборот, если между приложениями существует конкуренция за ресурсы или взаимное влияние, они будут быть взаимоисключающими.
Приоритет сценария: большинство предприятий Meituan-Dianping в основном представляют собой стабильные сценарии, поэтому необходимо разделение сценариев. Например, тип бизнеса очень чувствителен к задержкам, и ему не разрешается иметь слишком большую конкуренцию за ресурсы даже в часы пик.В этом сценарии следует избегать задержек, вызванных конкуренцией за ресурсы, и сокращать их, чтобы обеспечить достаточное количество ресурсов; тип бизнеса требует некоторых периодов времени.Ресурсы ЦП могут превышать верхний предел конфигурации.Мы разделяем эту часть ресурсов для таких служб через набор ЦП, чтобы преодолеть ограничения машинных ресурсов спецификаций приложения, не только служба может получить более высокую производительность, но и время простоя.ресурсы были использованы, и коэффициент использования ресурсов был дополнительно улучшен.
Эластичное масштабирование: развертывание приложений обеспечивает прогнозирование трафика, автоматическое масштабирование, масштабирование пиковых и минимальных пиков на основе правил, а также механизмы масштабирования на основе машинного обучения.
Уточненное распределение ресурсов: на основе технологии совместного использования и изоляции ресурсов улучшено планирование и распределение ресурсов, например привязка Numa, приоритет задач, набор ЦП и т. д.

Оптимизация стратегии

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

Сходство: существует определенное сходство между приложениями, которые имеют взаимосвязи вызовов и зависимости, или приложения, которые вместе взятые могут снизить общую вычислительную мощность и повысить пропускную способность. Наш набор ЦП состоит в том, чтобы использовать ограничения сходства предпочтений ЦП для создания приложений, чтобы приложения с разными предпочтениями ЦП могли дополнять друг друга.
Взаимная исключительность: в отличие от сходства, это в основном развертывание приложений, которые имеют конкуренцию или бизнес-вмешательство, как можно более раздельно во время планирования.
Приоритет приложений. Разделение приоритетов приложений является необходимым условием для решения проблемы конкуренции за ресурсы. В настоящее время, когда между контейнерами существует конкуренция за ресурсы, мы не можем решить, кто должен получить ресурсы.Благодаря концепции приоритета приложений мы можем ограничить количество важных приложений на одном хосте на уровне планирования и уменьшить количество важных приложений. на одном хосте.Конкуренция за ресурсы одной машины также позволяет нижнему уровню одной машины решать конкуренцию за ресурсы; на уровне хост-машины ресурсы распределяются в соответствии с приоритетами приложений, чтобы обеспечить достаточное количество ресурсов для важных приложений, и низкоприоритетные приложения также могут быть запущены.
Разборка: Разборка приложения в основном предназначена для аварийного восстановления, и здесь она разделена на разные уровни разборки. Мы предоставляем различные уровни детализации фрагментации, включая хост, Tor, компьютерный зал, зону и многое другое.
Изоляция и эксклюзивность. Это особый тип приложения, которое необходимо развертывать независимо, используя хост или виртуальную машину в изолированной среде, например, в рабочей среде поисковой группы.
Специальные ресурсы. Специальные ресурсы предназначены для удовлетворения особых требований к оборудованию определенных предприятий, таких как графические процессоры, твердотельные накопители и специальные сетевые карты.

Онлайн-оптимизация кластера

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

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

заключительные замечания

В настоящее время мы активно изучаем следующие аспекты:

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

об авторе

Гуолян, старший инженер центра кластерного планирования базовой платформы исследований и разработок Meituan-Dianping.

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

Базовый центр планирования кластеров платформы исследований и разработок Meituan Dianping стремится создать эффективную ведущую в отрасли платформу управления и планирования кластеров, создавать лучшие в отрасли облачные решения с помощью платформы управления кластерами корпоративного уровня, улучшать возможности и стабильность управления кластерами, а также снижать затраты на ИТ. стоимость и ускорить инновации и развитие компании. В то же время, поскольку Kubernetes стал стандартом де-факто в отрасли, Meituan Dianping постепенно охватывает сообщество, участвует в проектах с открытым исходным кодом и добилась больших успехов в области планирования кластеров. промышленности для совместного улучшения управления кластерами и возможностей планирования и снижения затрат на ИТ всей отрасли, совместных инноваций и разработок. Базовая платформа исследований и разработок Meituan Dianping уже давно набирает таланты в области управления кластерами и планирования, гибкого планирования, Kubernetes и ядра Linux.Заинтересованные студенты могут отправлять свои резюме по адресу tech@meituan.com.