Редактор｜Тина

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

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

Чжан Чжибо, ставший свидетелем успеха Kubernetes и сообщества, является одним из разработчиков, получивших выгоду: «После того, как мой первоначальный стартап Rancher был приобретен, я все еще могу найти работу в ИТ-отделе партии А в качестве пожилого ИТ-специалиста. Обе вакансии получили пользу от развития экосистемы Kubernetes. Для меня, как обычного человека, это самое большое вдохновение».

После того как Kubernetes стал открытым исходным кодом, он быстро занял решающую лидирующую позицию. Это также связано с активным предоставлением услуг хостинга Kubernetes поставщиками общедоступных облаков, что значительно снизило порог использования, а Cloud Native превратился в существующий рынок, за который конкурируют Tencent, Alibaba, Volcano Engine и другие компании. Поэтому мы также пригласили Alibaba Cloud Чжан Кая, Tencent Cloud Li Xianghui и Volcano Engine Deng Deyuan, чтобы объяснить, как Kubernetes меняет индустрию облачных вычислений в их глазах.

Заговор Google

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

В 2014 году Docker все еще была небольшой компанией со штатом всего 30 сотрудников и только что сменила название с dotcloud. Одной из главных новостей года стал выпуск Docker 1.0. С тех пор волна контейнеризации постепенно захлестнула мир.

Развитие контейнерных технологий породило большое количество контейнерных стартапов. Кажется, что у каждой крупной стартап-компании есть проект по оркестрации контейнеров. В то время рынок капитала благоприятствовал контейнерным стартапам, а масштабы и объемы финансирования продолжали расти. Некоторые крупные отечественные предприятия также имеют собственные системы оркестрации и планирования, такие как Baidu Matrix и Alibaba Sigma. Некоторые компании, такие как отечественная Meituan и зарубежная Twitter, используют Mesos.

На DockerCon в этом году, когда основатель и технический директор Docker анонсировал libswarm, он впервые представил волну существующих «конкурентов»: Shipper, Geard, Mesos, Coreos, Consul, Helios и Centurion. Причину, по которой эти проекты и стоящие за ними компании конкурируют в области оркестрации контейнеров, легко понять. То есть, хотя ценность Docker или самого контейнера велика, если вы хотите, чтобы он приносил коммерческую ценность или ценность для пользователей. облако, то оно должно находиться в Устроении, чтобы занять выгодную позицию выше.

Источник скриншота: https://www.slideshare.net/slideshow/docker-the-road-ahead/35706350

В это время Google создал самую большую и мощную компьютерную сеть в мире с миллионами серверов, разбросанных по всему миру. Идея Kubernetes исходит из системы Borg, которая управляет миллионами серверов внутри Google.

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

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

Однако когда команда Kubernetes предложила план с открытым исходным кодом, старший вице-президент Google по технической инфраструктуре задал им вопрос: «Открытый исходный код? Какие преимущества это может принести Google?» 2014. Очевидно, что это касается не только обмена технологиями, но и содержит глубокие стратегические соображения. В то время Amazon имела неоспоримое лидерство в сфере облачных вычислений. Хотя у Google была потрясающая облачная инфраструктура, у нее не было сильного коммерческого облачного бизнеса, который мог бы конкурировать с AWS. Поэтому Google нужен был способ повысить свою значимость. АВС.

Первоначально Google предложил «трехступенчатую ракету» технологий, а именно Anthos, Kubernetes и GCP. Во-первых, благодаря открытому исходному коду Kubernetes мы сначала установим фактический стандарт планирования и оркестрации в области контейнеров. После того, как все центры обработки данных будут использовать Kubernetes, Anthos будет предоставлен центрам обработки данных для управления гетерогенной инфраструктурой Azure или AWS и обеспечения ее работы. пользователей с помощью Обеспечьте бесперебойную работу в мультиоблачной среде.

Исходя из этой цели, Kubernetes предоставляет концепции и стандарты для контейнеров, микросервисов и декларативных API. Будь то поставщик облачных услуг, собственный IDC или даже мультиоблачная среда, всеми базовыми ресурсами можно управлять через стандартный API.

Всего за три года в отрасли завершился спор в области планирования и оркестрации под руководством Google. Kubernetes Быстро становится самым популярным в отраслиизконтейнерплатформа оркестровки,Али、Тенсент、Такие компании, как ByteDance, также перешли на проживание. Kubernetes начальство. 2017 год В конце года даже Amazon выпустил один Kubernetes продукт. Каждый производитель инвестирует в Kubernetes еще больше утвердил свой необратимый статус.

Поставщики облачных технологий и контейнеров будут обслуживать большое количество клиентов и будут более чувствительны к технологической ориентации и выбору пользователей.

«Rancher всегда была поставщиком контейнерных продуктов корпоративного уровня, но вначале она не использовала Kubernetes в качестве основного механизма оркестрации. В 2017 году наш бизнес столкнулся с большими трудностями. Все больше и больше клиентов ожидали, что будут использовать Kubernetes вместо Kubernetes. Мы разработали собственный движок оркестрации, поэтому в 2018 году мы решительно отказались от предыдущего накопления технологий и полностью трансформировали продукт в платформу управления Kubernetes», — об этом также упомянул Чжан Чжибо.

Хотя Kubernetes в то время еще не достиг возможностей корпоративного уровня, и большинство пользователей вряд ли стали бы переносить свой основной бизнес на Kubernetes, базовый размер пользователей открытого исходного кода действительно был очень большим, и он развивался чрезвычайно быстро. Технология Kubernetes также постоянно развивается при продвижении сообщества открытого исходного кода. В этом процессе необходимо упомянуть два узла. Один из них — запуск механизма Custome Resource Definition (CRD) в версии 1.7. Благодаря механизму CRD Kubernetes оставляет различия в разных сценариях на усмотрение пользователей и сообществ для расширения реализации, которая в основном может охватывать разные режимы и различные архитектуры корпоративных приложений.

Во-вторых, после версии 1.19 планировщик Kubernetes полностью перешел на архитектуру платформы Scheduler, которая раскрывает каждый этап Pod на протяжении всего цикла планирования с помощью механизма перехвата, позволяя плагинам пользователя рекомбинировать и организовывать упаковку различных Pod и узлов. . Стратегия. С тех пор планирование Kubernetes больше не ограничивается распределением ресурсов одного модуля. Сообщество быстро расширилось до пакетного планирования задач, гетерогенного планирования ресурсов, автономного гибридного развертывания, уточненного планирования, ориентированного на SLO, и эластичного планирования для облачных ресурсов. и т. д. и т. д., эти широкие возможности планирования обеспечивают базовую гарантию поддержки Kubernetes большего количества типов рабочих нагрузок. Большое количество задач обучения и вывода в области искусственного интеллекта и машинного обучения, пакеты Spark и потоки Flink в области больших данных, Ray в области общей структуры распределенных вычислений и даже задания Slurm в области высокопроизводительных вычислений — все это можно запланировать в кластерах Kubernetes. .

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

Наиболее практическими преимуществами внедрения Kubernetes должны стать экономия ресурсов и повышение эластичности приложений.

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

Еще одним преимуществом Kubernetes является улучшение использования ресурсов, которое сначала увеличилось с 5% в эпоху ВМ до 20%, а затем до текущего уровня около 65% (который также считается безопасным уровнем). Контейнеры используют более детальную концепцию разделения, чем виртуальные машины, что позволяет более эффективно использовать ресурсы.

Источник скриншота: выступление Дэвида Арончика, старшего менеджера по продуктам Google Kubernetes, 2017 г.

Интегрированная база данных кластера Kubernetes、AI、большие данные、существовать Интернет-бизнес и другие виды бизнеса,В сочетании с гибридным отделом для расширения возможностей управления и контроля одной машины Планирования.,Весь кластер служит стандартной службой поддержки вычислительной мощности.,В конечном итоге улучшение общего использования ресурсов。в соответствии с Тенсентизобщедоступные данные,После объединения пула ресурсов,Общий коэффициент использования ресурсов колеблется от 12% повышен до 45% , использование в автономном режиме достигает 65%,3 Совокупная годовая экономия 30 100 миллионов.

Действительно ли концепция «мультиоблачных» технологий успешна?

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

Еще одним ключевым узлом является выпуск Kubernetes v1.0, который, по нашему мнению, означает, что Kubernetes действительно доступен от тестирования до производства, и многие пользователи постепенно приняли Kubernetes.

Еще один узел был с 2015 по 2016 год. В области оркестрации контейнеров Kubernetes добился выгодной позиции в конкуренции со Swarm и Mesos.

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

Различные поставщики облачных технологий теперь предоставляют свои собственные продукты контейнерных платформ на базе Kubernetes, такие как Amazon EKS, Google GKE, Alibaba ACK, Tencent TKE, Volcano Engine VKE и т. д. Стоит отметить, что EKS от AWS должен стать наиболее используемым дистрибутивом Kubernetes в мире.

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

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

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

Таким образом, это кажется противоречием, поскольку ценностное предложение пользователей мультиоблачных систем отличается от ценностных предложений поставщиков облачных услуг. Ценностное предложение каждого поставщика облачных услуг состоит в том, чтобы надеяться, что пользователи будут «больше использовать свои собственные и меньше чужих» и стремиться увеличить свои основные доходы и прибыль. Вот почему мы видим, что AWS, Azure и Google в зарубежных странах, Alibaba Cloud, Tencent Cloud и Huawei Cloud в Китае и т. д. на самом деле не очень заинтересованы в инвестициях в мультиоблачное гибридное облако. Поэтому, даже если мультиоблако будет реализовано, оно будет использовать себя в качестве «основного облака» для реализации мультиоблачного управления, контроля и миграции и в то же время предоставлять некоторые нестандартные возможности для удовлетворения потребностей пользователей.

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

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

Поэтому, как сказал Чжан Чжибо: «Для совместимости и переносимости, пока пользователи гарантируют, что разные облака используют одинаковые версии Kubernetes и относительно ограничены в дополнительных функциях, миграция и трансплантация между несколькими облаками не представляют сложности. Этот вопрос связан с облаком. Вендоры тут ни при чем, в основном это зависит от самих пользователей».

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

Kubernetes стал менее популярным, но это означает не его упадок, а его зрелые и надежные возможности в качестве инфраструктуры уровня предприятия.

Примерно в 2018-2019 годах в сообществе упор делался на одно слово: «boring», что означает «скучно». Это означает, что Kubernetes действительно стал проектом, по умолчанию признанным всеми предприятиями. Вместо того, чтобы своевременно обращать внимание на каждую новую функцию в сообществе, все более охотно изучают, какую ценность может принести им Kubernetes и для чего его можно использовать. Различные предприятия также начали всесторонне использовать Kubernetes в своих средах, включая миграцию встроенной облачной безопасности, облачных баз данных и т. д. в Kubernetes.

С точки зрения отраслевого цикла компании, связанные с Kubernetes, неизбежно пройдут этап консолидации. За это время произошла серия приобретений: VMware приобрела Heptio, основанную двумя соучредителями Kubernetes, а SUSE приобрела популярную Rancher. Компания Weaveworks, когда-то известная как «светоч инноваций в области управления облачными контейнерами», объявила о своем банкротстве... Большинство проектов по оркестрации контейнеров постепенно исчезли, и даже Mesos, один из крупнейших конкурентов Kubernetes, также закрылся. в последние два года переехал на Чердак, официально объявив об «выходе на пенсию».

Источник скриншота: Приобретения в Kubernetes Space.

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

Проникновение и охват Kubernetes в настоящее время достигли относительно стабильного состояния. Однако глубина применения Kubernetes в вертикальном направлении продолжает углубляться.

По мере насыщения всего рынка, особенно среди поставщиков облачных услуг, таких как Alibaba, Tencent и Huoshan Engine, конкуренция постепенно смещается на фондовый рынок. В условиях конкуренции на фондовом рынке основная проблема заключается в том, что совместимость в мультиоблачных средах еще не решена. Сюда входит развертывание Kubernetes, различие между различными версиями Kubernetes и способы миграции между мультиоблачными средами. Ключевым моментом является снижение затрат пользователей на миграцию и затраты на использование, а также оптимизация затрат при обеспечении стабильности использования.

В ноябре прошлого года в Didi произошло широкомасштабное и продолжительное отключение электроэнергии. В официальных новостях говорилось, что это «сбой в базовом системном программном обеспечении», но в отрасли в целом считали, что это крупномасштабный сбой в производственной среде, вызванный уязвимостью Kubernetes. Такого рода случаи, связанные с хрупкостью Kubernetes, ни в коем случае не единственные. Как бороться с хрупкостью Kubernetes для повышения стабильности всей облачной среды — это тоже направление для углубленной разработки. В настоящее время Tencent, Didi, Meituan и Alibaba занимаются такого рода более глубоким и масштабным применением и практикой.

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

В сценарии ИИ по-прежнему важен Kubernetes?

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

В 2021 году инженеры OpenAI обнародовали свои планы по масштабированию Kubernetes до 7500 узлов. Этот кластер не только утроился в размере за 3 года, но и используется для крупных моделей, таких как GPT-3, CLIP и DALL·E, а также для быстрых мелкомасштабных итеративных исследований. Более того, OpenAI использует «десятки тысяч» графических процессоров NVIDIA. Такое масштабирование сопряжено с другими инженерными проблемами, включая вспомогательный мониторинг, индивидуальное планирование и многое другое.

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

«В рамках ByteDance мы используем Kubernetes с 2016 года, поэтому у нас нет другого выбора. Будь то онлайн-сервисы или офлайн-задачи, главное, чтобы это был технологический проект, лишь бы он требовал использования ресурсов, независимо от того, формы мы будем использовать Kubernetes. Поэтому мы не делаем различий между генеративным искусственным интеллектом и другими типами приложений. В ByteDance все управление ресурсами осуществляется через Kubernetes».

У Kubernetes также есть недостатки. Основными сценариями, для которых он изначально был разработан, были рабочие нагрузки без сохранения состояния (например, веб-приложения и микросервисы). Позже, с повышением стабильности системы и возможностями управления томами хранилища, в Kubernetes также запускались многие рабочие нагрузки с сохранением состояния, такие как базы данных, распределенное промежуточное программное обеспечение. , и т. д. До этого момента основная архитектура Kubernetes не сталкивалась с какими-либо серьезными проблемами. В эпоху ИИ произошли очевидные изменения, особенно задачи ИИ, представленные глубоким обучением, и задачи обработки больших данных, представленные пакетными потоками Spark и потоками Flink, которые все пытаются запускать в кластерах Kubernetes. С точки зрения управления графическим процессором и вывода, первая и самая большая проблема, с которой приходится сталкиваться каждому, — это планирование и управление ресурсами.

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

Что касается планирования на уровне задач, Kubernetes должен иметь возможность перейти от планирования для одного пода к планированию для группы подов, удовлетворять различные зависимости, ассоциации и ограничения между подами и повышать общую эффективность задач. Архитектура Scheduler-framework — одно из ключевых улучшений в планировании и управлении задачами ИИ в Kubernetes. По сути, Kubernetes должен иметь возможность эффективно поддерживать крупномасштабную систему задач. В архитектуре помимо планировщика (пакетного планировщика) и контроллера жизненного цикла (контроллера заданий) объекта задачи еще отсутствует важный компонент — очередь задач (очередь заданий). Сообщество Kubernetes также знает об этом, и такие инкубационные проекты, как Kueue и Kube-queue, пытаются решить эту ключевую загадку.

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

В процессе обучения строительство вспомогательных систем контроля и эксплуатации и обслуживания не было особенно завершено. Особенно при крупномасштабном обучении по-прежнему остается проблемой то, как контролировать мощность графического процессора и точно определять, остановлена ​​ли задача пользователя или все еще тренируется. Например, если пользователь обучает модель и обнаруживает, что среда обучения модели внезапно останавливается во время работы, однако эту ситуацию невозможно эффективно обнаружить с помощью традиционных решений для мониторинга ЦП или ГП. Здесь может быть ключевой показатель — мощность графического процессора. Когда мощность графического процессора падает, это означает, что задача остановилась. В этом случае, когда задача остановлена, как быстро запустить новую задачу, чтобы ускорить процесс обучения, крупные поставщики облачных услуг не решили эту проблему должным образом. Это показывает, что еще есть много возможностей для совершенствования систем мониторинга, эксплуатации и обслуживания во время крупномасштабного обучения.

Кроме того, что касается виртуализации графических процессоров, в настоящее время существует несколько зрелых решений, таких как QGPU, VGPU, mGPU и cGPU. Однако в сценариях применения графических процессоров имеется мало данных об использовании графических процессоров. Что касается использования ЦП, в отрасли обычно упоминается загрузка 60% или 80%, но почти нет соответствующего обсуждения и объяснения использования графического процессора и того, когда считается, что оно полностью снижает производительность графического процессора. Это показывает, что проблемы в этой области до сих пор не решены полностью и отсутствуют комплексные отраслевые решения. Например, хотя мы видим, что такие компании, как Google, заявляют о создании обучающих кластеров графических процессоров на 6000 узлов, информации об этом очень мало. Обмен информацией или углубленное размышление о крупномасштабном кластере обучения графических процессоров.

Поэтому у крупных производителей, будь то GPT или другие крупные языковые модели различных компаний, все планируют вычислительные мощности GPU на базе Kubernetes. Но на данном этапе, поскольку пока нет приложений уровня феномена, лишь немногие приложения ИИ имеют очень высокие показатели удержания, а многие — однозначные. Поэтому всех больше волнует, как быстрее запустить приложение, как быстрее выпустить модели. и даже Вы можете потратить сотни миллионов, чтобы получить несколько дней стартового времени. Поэтому крупные производители сейчас в основном сосредотачиваются на поддержке собственных приложений искусственного интеллекта для решения некоторых проблем прикладного уровня, таких как медленная скорость загрузки модели, выбор подходящей карты графического процессора и модели в оттенках серого. Для планирования и управления ресурсами на уровне Wanka запустите его «эксклюзивным» способом: создайте для себя отдельный кластер Kubernetes. Можно сказать, что для них не так важно, GPU это или Kubernetes.

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

В конце написано: Почему Kubernetes успешен?

Что касается экосистемы Kubernetes, следует упомянуть еще один сектор — CNCF.

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

Чтобы решить эту проблему, Google передал проект Kubernetes независимой организации CNCF и сделал его первым проектом CNCF. Это одна из ключевых инициатив по поддержанию работоспособности Kubernetes. CNCF уже насчитывает 741 члена, 190 проектов, а ее экологическая территория также расширяется с каждым днем.

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

Если есть еще один, то это должен быть «Red Hat»: «Ни один проект с открытым исходным кодом без участия Red Hat не является действительно проектом с открытым исходным кодом».

Когда Kubernetes планировал сделать открытым исходным кодом, Red Hat обратилась в Google. В декабре 2014 года, вскоре после того, как Google официально выпустил проект Kubernetes, Red Hat официально объявила о стратегическом сотрудничестве с Google для полного инвестирования в Kubernetes. Хотя это связано с тем, что Red Hat хочет заняться облачными вычислениями и ей необходимо предоставить OpenShift структуру управления контейнерами, эта компания, существующая с 1993 года, имеет очень хорошее влияние в сообществе открытого исходного кода. Существует поговорка: если проект с открытым исходным кодом недостаточно чист или поставщик открытого исходного кода имеет слишком сильное доминирование над проектом, Red Hat обычно не будет в нем участвовать.

Таким образом, Kubernetes извлекает выгоду из технического влияния Google, с одной стороны, и влияния Red Hat с открытым исходным кодом, с другой.

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

Если мы продолжим исследовать другие факторы, способствующие успеху Kubernetes, мы также получим следующие ответы:

«100% открытый исходный код и мощные функции корпоративного уровня. Даже если вы не можете позволить себе продукты корпоративного уровня, вы можете создать кластер Kubernetes с богатыми возможностями. Никто не сможет устоять перед таким недорогим продуктом, соответствующим требованиям. Тенденция развития. Это естественный выбор рынка».

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

«Открытый исходный код работает хорошо. Он полагается на силу всего сообщества в постепенном улучшении своих возможностей».

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

«Баланс между коммерциализацией и открытым исходным кодом. Масштабное применение облачных поставщиков способствовало процессу коммерциализации контейнерных технологий. Коммерциализация успешно поддержала сообщество открытого исходного кода и обеспечила финансовую и ресурсную поддержку для устойчивого развития сообщества».

Профиль гостя:

Чжан Жибо,вперед SUSE Rancher Директор по исследованиям и разработкам в Большом Китае, принимал активное участие в исследованиях и разработках и имеет опыт OpenStack приезжать Kubernetes технологические изменения в базовой операционной системе Линукс, виртуализация KVM и Docker контейнер имеет богатый опыт исследований и разработок и практический опыт в технической области. В настоящее время существует ведущая автомобильная компания IT Должности отдела.

Чжан Кай,Алибаба Облако Старший технический эксперт, Алибаба Облакоконтейнер Руководитель направления интеллектуальных вычислений. Он имеет обширный опыт исследований и разработок в области облачных вычислений и активно участвует в облачных технологиях, корпоративных приложениях, микросервисах, искусственном интеллекте, больших данных, высокопроизводительных вычислениях и многих других сценариях. Возглавить команду по разработке облачных решений AI поле, творение Fluid、Kube-Queue、GPUShare、Arena и многие другие связанные проекты с открытым исходным кодом.

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

Дэн Дэюань,Директор платформы облачных приложений Volcano Engine,Существует богатый опыт работы с продуктами и архитектурой корпоративных облачных приложений. Прежде чем присоединиться к ByteDance,Был соучредителем Hangzhou Caiyun Technology.。один раз в США Google Основной член команды управления кластером, в основном занимающийся разработкой системы управления кластером.

Дальнейшее чтение:

Интерпретация главы о контейнерах 2015 года: Расширение и эволюция: https://www.infoq.cn/news/2015-review-container-chapter-expansion-and-evolution

Интерпретация 2016 - контейнер: «Мертвые» и «Вечная жизнь»: https://www.infoq.cn/article/interpretation-of-2016-container

Интерпретация 2017 Контейнеры: Позже Kubernetes Время: https://www.infoq.cn/news/2017-container-Kubernetes.

Почему 2019 год называют эрой контейнерных технологий? https://www.infoq.cn/article/R1p3H3_29f4TYImExsyw

Почему 2019 год является ключевым моментом в эпоху облачных технологий? https://www.infoq.cn/article/y6BB98AcyFWXoNxiZ7fz

Документальный фильм о Kubernetes (часть 1): https://www.youtube.com/watch?v=BE77h7dmoQU

Документальный фильм о Kubernetes (часть 2): https://www.youtube.com/watch?v=318elIq37PE

Kubernetes Устарело dockershim：https://mp.weixin.qq.com/s/kIB4_qDvIIlsbs-jD47yBA

Mesos Проект переехал в Attic ：https://mp.weixin.qq.com/s/bQjuZLSqempKg9i4qkD3Gw

Alibaba Cloud реконструирует всю базовую систему планирования спустя 13 лет: https://www.infoq.cn/article/otoewtvxnyws8ab6ydzb

В нем участвуют десятки тысяч человек и продлится три года.,Самый крупный в странеиз Как создаются облачные практикииз？https://mp.weixin.qq.com/s/6WA9BWdDPWsBWjdVm7oDeA

Путь ByteDance к использованию мультиоблачных технологий: https://mp.weixin.qq.com/s/3nlilkW7hh1A0h4yEJFAag