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

Авторы: Ван Чен, Му Хуань, Си Ян и др.

Контейнеры по сути являются изоляционной технологией, которая решает нерешенные проблемы своего предшественника — виртуализации: медленный запуск работающей среды и низкое использование ресурсов, в то время как две основные концепции контейнерной технологии, Namespace и Cgroup, как нельзя лучше решают обе проблемы. Как казалось бы, изолированная технология, пространство имен заменило Hypervise и GuestOS. Исходная операционная среда для двух ОС превратилась в одну. Операционная среда легче и быстрее запускается. Cgroup используется как изолированная технология. Процесс может потреблять только часть процессора и памяти всей машины.

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

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

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

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

Где сложно использовать?

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

В интервью старший технический эксперт Alibaba Чжан Лэй проанализировал природу Kubernetes, он отметил: «Kubernetes сама по себе является распределенной системой, а не простым SDK или программной средой, которая сама по себе повысила свою сложность до распределенной системы системного уровня. Расположение проектов с открытым исходным кодом.Кроме того, Kubernetes впервые популяризировал идею декларативного API в области инфраструктуры с открытым исходным кодом и на основе этого предложил ряд парадигм использования, таких как шаблон проектирования контейнера и контроллер Модель, которая имеет определенный передовой и перспективный дизайн, также обеспечивает определенный цикл обучения, когда проект Kubernetes принимается публикой».

Мы кратко суммируем 4 основные сложности Kubernetes.

1,Когнитивная сложность: В отличие от исходной внутренней системы исследований и разработок, она расширяет новый набор теорий и предоставляет ряд новых технических концепций, таких как Pod, sidecar, Service, управление ресурсами, алгоритм планирования и CRD и т. д., в основном предназначенные для платформы Команды НИОКР, а не разработчики приложений, предоставляя множество мощных и гибких возможностей. Однако это не только усложняет процесс обучения, но и влияет на опыт разработчиков приложений: во многих случаях неправильное понимание может привести к некорректным операциям и даже сбоям в работе.

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

3.Миграция — это сложно: Миграция существующих приложений на K8s более сложна, особенно для немикросервисных архитектур.Во многих случаях требуется рефакторинг отдельных компонентов или всей архитектуры, а также рефакторинг приложений с использованием облачных принципов, таких как зависимости от состояния, такие как запись Локальный каталог, порядок, сетевая зависимость, например, мертвый IP-адрес, количественная зависимость, например фиксированная копия и т. д.

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

Есть ли другое решение?

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

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

Инструменты с открытым исходным кодом для экосистемы Kubernetes

OAM/KubeVela — это проект с открытым исходным кодом, размещенный в CNCF и направленный на упрощение разработки, эксплуатации и обслуживания приложений K8s.Первоначально он был совместно инициирован Alibaba Cloud и Microsoft Cloud.

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

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

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

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

Доставка — еще одна проблема в экосистеме контейнеров. Она сталкивается с проблемой зависимости от сложности и согласованности, особенно для проектов доставки Kubernetes промышленного уровня. Цикл доставки становится длиннее, а качество доставки — высоким. Sealer очень подходит для разработчиков программного обеспечения, Независимые поставщики программного обеспечения и другие свойства Предприятия могут сократить время развертывания до часового уровня.

Открытый стандартизированный сервис Kubernetes корпоративного уровня

Большинство поставщиков облачных услуг предоставляют возможности контейнерной платформы Kubernetes как услуги, такие как AWS EKS и ACK Alibaba Cloud, которые могут значительно упростить развертывание, эксплуатацию и обслуживание, сетевое хранилище, управление безопасностью и другие возможности кластеров K8s. требования рабочей нагрузки практически для всех сценариев и предоставляют широкие возможности расширения и настройки. Кроме того, большинство поставщиков облачных услуг предоставят различные уровни инкапсуляции на верхнем уровне на основе платформы Kubernetes с открытым исходным кодом, чтобы адаптироваться к потребностям различных предприятий и различных сценариев для предоставления выпусков и версий Pro, таких как ACK Pro от Alibaba Cloud. возможность размещать основные и полностью управляемые пулы узлов, полностью интегрировать возможности IaaS, более эффективные, безопасные и интеллектуальные, а также предоставлять предприятиям передовой опыт и полную оптимизацию различных подсценариев контейнерных кластеров в качестве встроенных сервисов.

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

Для получения дополнительной информации перейдите по ссылке: «Несколько выпусков Alibaba Cloud Container Service: эффективная, интеллектуальная, безопасная и неограниченная платформа следующего поколения».

Сервисы Kubernetes превращаются в бессерверные

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

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

Многие поставщики облачных услуг также дополнительно интегрировали контейнеры и бессерверные решения: например, бессерверный контейнерный сервис ASK от Alibaba Cloud и AutoPilot от Google GKE, чтобы избежать эксплуатации и обслуживания, снизить сложность операций клиентов на узлах и кластерах K8s и не нужно покупать Приложения-контейнеры можно развертывать напрямую, в то же время приложения-контейнеры по-прежнему можно развертывать с помощью командной строки и API K8s, полностью используя возможности оркестровки K8s и оплачивая по требованию в зависимости от количества ЦП и ресурсы памяти, настроенные приложением.

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

Дополнительную информацию можно переместить по адресу: «Бессерверный Kubernetes: идеал, реальность и будущее».

Новое поколение сервисов PaaS на базе контейнеров и бессерверных технологий

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

Хотя K8s обеспечивает полное управление жизненным циклом контейнерных приложений, он слишком богат, слишком сложен и слишком гибок, что является одновременно и преимуществом, и иногда недостатком. Особенно для сотрудников отдела исследований и разработок, эксплуатации и технического обслуживания, которые привыкли управлять приложениями с точки зрения приложений в эпоху виртуальных машин, даже если AWS EKS, Alibaba Cloud ASK и т. д. в определенной степени снизили операционную сложность K8, Надеюсь, каким-то образом порог использования контейнерной технологии можно еще снизить.

Контейнеры и K8 не обязательно объединять.В некоторых новых службах PaaS, таких как Serverless Application Engine (SAE) Alibaba Cloud, нижний уровень преобразует технологию виртуализации в технологию контейнеров, полностью используя технологию изоляции контейнеров для сокращения времени запуска и ресурсов. использование, в то время как на уровне управления приложениями сохраняется исходная парадигма управления приложениями микросервиса, и пользователям не нужно изучать огромные и сложные K8 для управления приложениями. Этот новый тип услуги PaaS обычно также имеет полный набор встроенных возможностей управления микросервисами.Пользователям не нужно рассматривать выбор платформы, а также изоляцию данных, распределенные транзакции, конструкцию прерывателя цепи, ограничение тока и переход на более раннюю версию, и т. д., а также им не нужно беспокоиться об ограниченном обслуживании сообщества.

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

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

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

Для получения дополнительной информации перейдите по ссылке: «Преодолевая границы бессерверной реализации, Alibaba Cloud SAE выпускает 5 новых функций».

Более экстремальные бессерверные услуги — FaaS

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

Это делает FaaS (Function Computing) альтернативой контейнерам и K8 для общей вычислительной мощности.

Подобно Google Cloud Run, App Runner и другим бессерверным сервисам, форма продукта FaaS становится все более и более открытой, со все меньшим количеством ограничений на работу.Помимо того, что он подходит для моделей вычислений, управляемых событиями, он также подходит для веб-сайтов. монолитные приложения, рабочие места и т. д. Сценарии могут помочь пользователям добиться максимальной гибкости и еще больше улучшить использование вычислительных ресурсов.

Например, Лилит из игровой индустрии применяет функциональные вычисления для проверки боя, чтобы проверить, есть ли читерство в битве, загруженной клиентом игрока. Верификацию боя, как правило, нужно рассчитывать покадрово, и нагрузка на ЦП будет очень высока, обычно битва 1 команды против 1 команды занимает n миллисекунд, а битва 5 команд против 5 команд требует соответствующих 5n миллисекунд, что требует высокой гибкости. Кроме того, SLB, установленный под архитектурой контейнера, не сможет воспринимать фактическую нагрузку Pod из-за механизма опроса, что приводит к неравномерной нагрузке, что приводит к бесконечному циклу и риску стабильности.

Система планирования Function Compute помогает Lilith разумно организовывать каждый запрос.Для проблемы с бесконечным циклом она также предоставляет механизм для остановки процесса по тайм-ауту и ​​снижает сложность системы планирования до уровня инфраструктуры. Кроме того, после глубокой оптимизации функциональных вычислений задержка холодного запуска значительно сокращается: от планирования до получения вычислительных ресурсов и запуска службы она составляет примерно 1 секунду+.

Кроме того, появление FaaS также значительно освободило инженеров стартапов, работающих с полным стеком, тратить средства на DevOps для переноса веб-приложений, таких как небольшие программы и веб-сайты.Например, функциональные вычисления сокращают количество серверов на языках интерфейса. такие как Node.js Порог обслуживания, пока вы можете писать код JS, вы можете поддерживать службы Node.

Для получения дополнительной информации перейдите по ссылке: «Преодолевая отраслевой камень преткновения, Alibaba Cloud Function Computing выпускает 7 крупных технологических прорывов».

Право самое лучшее

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

Если мы хотим в полной мере использовать все возможности K8S, а у команд есть определенные технические резервы, то Kubevela идеально подходит для выбора open source, Sealer также может помочь нам снизить сложность доставки; если вы хотите дать облака с разных уровней пакеты на верхнем уровне производителей для удовлетворения потребностей более эффективной адаптации различных бизнес-сценариев, то услуга коммерческого контейнера, предоставляемая производителями облачных вычислений, является хорошим выбором; если контейнер и K8s не могут соответствовать резиденции эластичного бизнес-класса, FAAS можно выбрать.

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

Справочная статья:

1. «Прошлое и настоящее облачных вычислений» Лю Чао
2. «Гибкое и эффективное управление облачными кластерами: управление K8s с помощью K8s», Huaiyou, Linshi
3. «Является ли сложность «ахиллесовой пятой» Kubernetes? ", Чжао Юин
4. «Упрощение Kubernetes для
   Разработчики», Rishidot Research
5. «KubeVela официально с открытым исходным кодом: масштабируемая облачная платформа приложений и основной механизм», специалист по сопровождению проекта OAM.
6. «KubeVela 1.0: открывая будущее программируемых платформ приложений», специалист по сопровождению проекта OAM.

Оригинальная ссылка

Эта статья является оригинальным контентом Alibaba Cloud и не может быть воспроизведена без разрешения.