Краткий обзор
Сегодня даже консервативные организации начинают внедрять Kubernetes. Платформа предлагает очевидные преимущества, — удобное развертывание, высокая скорость и гибкость, прозрачное управления расходами, — но при этом приводит к ряду новых проблем. Во многом эти проблемы в разных организациях схожи, но универсального решения для них не существует. Зато можно выделить несколько общих подходов, каждый со своими преимуществами и недостатками. Выбор подхода к управлению Kubernetes зависит от размера, сложности инфраструктуры и бизнес-целей каждой организации. В этом документе мы рассмотрим причины, по которым большинство организаций переходят на Kubernetes, а также проблемы, с которыми они сталкиваются. Затем мы проанализируем пять стратегий реализации Kubernetes и приведем примеры компаний, которым подходит каждая из них.
Введение: почему организации начинают использовать контейнеры и Kubernetes
Kubernetes и контейнеры очень быстро завоевали популярность. Сами по себе контейнеры существуют в Linux уже больше 10 лет, но только в 2014 году, когда Google выпустила открытую версию Kubernetes, они стали мейнстримом. С тех пор обе технологии быстро развиваются. По мнению 451 Research, рынок контейнеров растет на 30% в год. Согласно опрос, проведенному Portworx и Aqua Security в 2019 году, 87% из более чем 500 опрошенных ИТ-специалистов использовали контейнеры, и почти все — для производственных рабочих нагрузок. С 2018 по 2019 годы число участников фонда Cloud Native Computing Foundation (CNCF) выросло на 50%.
Что такое контейнеры?
Контейнер содержит приложение или микросервис вместе с библиотеками, бинарными файлами и файлами конфигурации, которые требуются для успешного выполнения. В отличие от виртуальной машины, контейнер не имеет операционной системы и работает в общей ОС, а потому занимает мало места и может выполняться в любой среде без изменений.
Почему организации так стремятся использовать контейнеры и Kubernetes? Обычно на это много причин, и хотя тут есть свои нюансы, можно выделить несколько общих факторов.
Например:
Сокращение ИТ-расходов. Контейнеры могут работать гораздо эффективнее, чем архитектуры приложений на основе виртуальных машин или других более традиционных технологий. Их можно плотнее размещать на экземплярах, чтобы сократить объем необходимых приложению ресурсов в ЦОД или облаке. Поскольку контейнеры используют общую операционную систему, они занимают меньше места по сравнению с виртуальными машинами и требуют меньше вычислительной мощности, памяти и хранилища. Экономия затрат по всей организации может быть ощутимой.
Повышение продуктивности разработчиков. Контейнеры хорошо подходят для DevOps и, в целом, ускоряют разработку, тестирование и развертывание приложений. Они быстрее реагируют на изменения в рыночной экосистеме и поведении заказчиков. С их помощью можно проверить, как разные приложения помогают достичь бизнес-целей. С контейнерами каждый разработчик может делать больше за меньшее время.
Более быстрый вывод продукта на рынок. Приложения можно не только быстрее разрабатывать, но и быстрее выводить на рынок, чтобы опередить конкурентов.
Переносимость между средами. Контейнеры работают одинаково в любой среде. Разработчик может быть уверен, что, если приложение работало корректно на локальном компьютере, оно будет работать и в другой среде. Это одна из причин повышенной производительности и быстрого выхода на рынок. При этом контейнеры могут упростить перенос инфраструктуры организации в публичное облако, а также реализацию мультиоблачной и гибридной стратегии.
Упрощенное обслуживание. Контейнеры проще и дешевле обслуживать и масштабировать. Не только сам контейнер, но и отдельные компоненты приложения можно масштабировать независимо от других. Это упрощает модернизацию, в том числе с помощью современных методов последовательного обновления. Сбой одного контейнера редко приводит к сбою всего приложения, поскольку проблему легче изолировать. Контейнеры проще переносить, чем монолитные приложения, и они поддерживают любые среды, поэтому в производственной среде меньше вероятности наткнуться на проблемы, не проявившиеся во время разработки и тестирования.
Что такое Kubernetes?
Kubernetes — это система оркестрации контейнеров с открытым исходным кодом, которая изначально была разработана Google и представлена как opensource-проект в 2014 году. В переводе с древнегреческого Kubernetes означает «кормчий» или «рулевой». Kubernetes (сокращенно — K8s) обеспечивает декларативную конфигурацию и автоматизацию для управления оркестрацией контейнеров, а также автоматизирует развертывание, масштабирование и обслуживание контейнеров. Также Kubernetes управляет обнаружением сервисов, балансировкой нагрузки, оркестрацией хранилища, самовосстановлением и секретами. Для Kubernetes существует обширная экосистема сопутствующих инструментов. Сейчас за платформу отвечает сообщество Cloud Native Computing Foundation (CNCF). Это первый проект CNCF, официально получивший статус выпущенного (graduated). В опросе, проведенном CNCF в 2019 году, 78% респондентов заявили, что используют Kubernetes в производственной среде.
Узнайте больше о Kubernetes на странице проекта.
Контейнеры — это сложная система. Появление Kubernetes.
У контейнеров множество преимуществ, но они могут усложнять эксплуатацию, особенно в производственной среде. Иногда не самая большая команда инженеров вынуждена отвечать за миллионы контейнеров, особенно если организация использует микросервисы. Контейнеры нужно развертывать, планировать, перезапускать после сбоев, подключать к внешнему миру и т. д. Без автоматизированной оркестрации контейнеров это придется делать вручную, а значит нужно будет собрать неразумно большую команду исключительно для планирования контейнеров.
Kubernetes разработан как стандартная платформа оркестрации контейнеров, которая дает компаниям необходимые инструменты для автоматизации таких задач, как масштабирование, планирование и восстановление после сбоев.
Почему Kubernetes?
Суть Kubernetes в том, что он позволяет использовать контейнеры. Без платформы оркестрации было бы невозможно воспользоваться всеми преимуществами контейнеров, потому что минусы перевесили бы плюсы. С помощью Kubernetes организации могут автоматизировать балансировку нагрузки, самовосстановление, оркестрацию хранилища, управление конфигурацией, выпуски и откаты, включая современные стратегии, вроде канареечного развертывания.
Без этого уровня автоматизации использовать контейнеры было бы очень непрактично. Контейнерам нужна оркестрация, и почти сразу стало очевидно, что использовать Kubernetes будет лучше, чем создавать платформу оркестрации с нуля или использовать конкурирующие технологии.
Kubernetes и контейнеры, конечно, самая важная часть облачного стека, но они не решают всех задач по управлению контейнеризированными облачными приложениями в производственной среде. Первым пользователям приходилось создавать собственные решения для управления сложностями, связанными с Kubernetes, и сопутствующими задачами. С развитием экосистемы появились различные типы вспомогательных решений. Прежде чем рассмотреть эти решения, давайте поговорим о сложностях, связанных с Kubernetes, и их влиянии на разные типы организаций.
Универсального средства не существует
У инженерного и ИТ-отдела в каждой организации свои сильные и слабые стороны и приоритеты. Потенциальные проблемы с Kubernetes и оптимальные решения зависят от разных факторов:
Размер. Чем больше масштаб, тем сложнее управлять Kubernetes. Небольшие организации могу не столкнуться с проблемами, которые возникнут у компании из Fortune 500.
Технические задачи. Некоторые организации не только занимаются разработкой и поставкой приложений, но и предлагают управление инфраструктурой, чтобы получить конкурентное преимущество. Другие организации решают более простые задачи и работают только на уровне приложений.
Отрасль. Набор нормативных требований, необходимая продолжительность непрерывной работы и уровень безопасности данных зависят от отрасли.
Бюджет. У организаций бывает разный бюджет.
Имеющаяся инфраструктура. Некоторые используют Kubernetes в локальной среде, некоторые — в облаке. Кто-то использует несколько облачных провайдеров, а кто-то сочетает локальную и облачную среду. Kubernetes поддерживает все эти варианты, но у каждого типа среды свои особенности.
Основные сложности с внедрением Kubernetes в организации
Неожиданно высокие расходы
Поскольку организации нередко переходят на Kubernetes с целью сэкономить, увеличение расходов становится неприятной неожиданностью, особенно если бюджет ограничен. При правильном подходе расходы действительно можно сократить. Вот несколько ловушек, которых следует избегать при переходе на Kubernetes.
Kubernetes — это платформа с открытым исходным кодом, как и многое программное обеспечение в облачной экосистеме. Благодаря открытому исходному коду организации могут сократить операционные и капитальные затраты (OpEx и CapEx). Но есть здесь и подводные камни, например:
Зависимость от вендора. Базовая версия Kubernetes подходит не всем организациям, и многие выбирают коммерческий дистрибутив или платформу Kubernetes, привязанную к облачному провайдеру. В результате организации не могут просто уйти от вендора, например, если цены стали слишком высокими.
Расходы на миграцию. Переход на Kubernetes требует времени. Организации часто не понимают, сколько сил и денег понадобится для переноса всех систем в контейнеры.
Рекомендации по контролю расходов. По умолчанию в Kubernetes не включены ограничения на использование ресурсов, и разработчики — особенно новички в Kubernetes — не всегда знают, что нужно, например, настроить эти ограничения, чтобы сэкономить.
Недостаток навыков
Kubernetes — это относительно новая технология. Она настолько сложная, что даже довольно опытные пользователи до сих пор постигают ее. Kubernetes также использует постоянно растущую экосистему бесплатных и коммерческих инструментов, хранилищ, сетевых решений и систем мониторинга. У Kubernetes столько дистрибутивов, платформ и вендоров, что одному человеку невозможно разобраться во всем этом многообразии.
Непрерывное развитие. Kubernetes и его экосистема постоянно развиваются, причем иногда так быстро, что за ними невозможно угнаться. Во всяком случае, не получится охватить всю широту лучших практик и новых функций в Kubernetes и сопутствующих технологиях.
Узкая специализация. Команды по Kubernetes в организациях часто изучают только одну область, актуальную для бизнеса, и упускают важные моменты, новые возможности и лучшие практики, например по операциям второго дня. Иначе говоря, даже инженеры, которые регулярно используют Kubernetes, часто многого не знают, а потому их возможности в Kubernetes ограничены.
Недостаток навыков и необходимость постоянно инвестировать в обучение также увеличивает общую стоимость использования Kubernetes.
Мультиоблачная и гибридная среда
Одно из основных преимуществ использования контейнеров — их переносимость между средами. И хотя контейнеры переносить несложно, потребуется немало усилий для переноса рабочей нагрузки Kubernetes между публичными облаками или из публичного облака в частное, особенно при использовании дистрибутивов от облачного провайдера. При этом возможность работать в нескольких средах — это одно из главных преимуществ контейнеров и Kubernetes. Организациям нужна эта возможность, чтобы достигать своих бизнес-целей — контроль расходов, свободный выбор вендоров, обеспечение высокой доступности и т. д. Переносимость между средами важна для эффективного конвейера CI/CD, поскольку среды разработки, тестирования и производства часто находятся в разных облаках.
Согласованность между средами. Для эффективной реализации мультиоблачной и гибридной стратегий необходимо обеспечить максимальную согласованность между средами. Любую конфигурацию, секреты или данные, относящиеся к одной среде, нужно определить для этой среды, а не включать в образ контейнера или конфигурацию рабочей нагрузки. При таким подходе рабочие нагрузки можно будет перемещать без изменений.
Чрезмерное многообразие инструментов
У Kubernetes необъятная экосистема инструментов и платформ, которая продолжает расти. Если вашей организации нужна функция, которой нет в готовом варианте Kubernetes, скорее всего, вы найдете для нее подходящий инструмент. С другой стороны, такое изобилие приводит к двум проблемам:
Выбор инструмента. При подборе инструмента приходится искать компромисс. Насколько хорошо он будет сочетаться с другими инструментами? Что лучше — гибкий инструмент с открытым исходным кодом или ограниченный и более дорогой коммерческий инструмент? Как контролировать и стандартизировать использование инструментов в организации? Многообразие инструментов в сочетании с недостатком навыков усложняет не только выбор инструментов, но и сам переход на Kubernetes.
Управление инструментами. Организации часто используют десятки разных инструментов, поэтому персоналу требуется больше времени на обучение, а затем и на управление всей этой сложной системой.
Безопасность, сети и хранилище
Для перехода на Kubernetes организация должна изменить свой подход к управлению безопасностью, сетями и хранилищем. Эксперты в этих областях должны освоить совершенно новые принципы, а разработчики приложений, которые раньше и не думали об этих аспектах, сейчас должны изучить их и включить в рабочий процесс.
Контейнеры и Kubernetes не более уязвимы, чем монолиты, но требуют иного подхода к безопасности, который основан скорее на управлении конфигурацией, чем на защите периметра. Службы ИБ должны научиться по-новому управлять безопасностью, при этом помогая командам DevOps работать еще быстрее.
Управление stateful-приложениями в Kubernetes не только возможно, но и выполняется в производственной среде многими организациями, хотя изначально контейнеры задуманы как stateless. При этом требуются навыки управления облачным хранилищем, которое работает не так, как хранилище в традиционной среде.
Правильно настроить балансировку нагрузки тоже непросто, но это необходимо, чтобы гарантировать доступность и производительность приложения.
Операции второго дня
Очень редко организации включают операции второго дня в подтверждение концепции, но приложения в Kubernetes, как и все остальные, большую часть жизненного цикла проводят в производственной среде, где их нужно исправлять, обновлять и отслеживать. Потребуется много времени и сил, чтобы обновить кластер или установить исправление для системы безопасности вручную. К тому же существует высокий риск ошибок. Один из способов автоматизировать эти задачи — использовать операторы, которые расширяют функционал без изменения базовой конфигурации Kubernetes. Операторы — это инструменты автоматизации, которые выполняют определенные операции без вмешательства пользователя. Операторы Kubernetes помогают автоматизировать операции второго дня, но большинство из них подразумевают зависимость от вендора. Кроме того, они не всегда достаточно зрелые, чтобы использоваться в производственной среде.
Операционные сложности Kubernetes мешают организациям в полной мере использовать преимущества контейнеров и платформы. У большинства организаций очень высокие требования к безопасности и комплаенсу: если Kubernetes им не отвечает, они не будут его использовать. Другие проблемы, вроде высоких расходов или недостатка навыков, не позволяют эффективно использовать ресурсы и применять гибкие методы разработки — а это как раз те преимущества, которые организации ожидают от Kubernetes.
Есть способы решить эти операционные проблемы, а также другие сложности, о которых мы говорили выше. Мы рассмотрим пять стратегий, с которыми использовать Kubernetes будет проще и дешевле, а также преимущества и недостатки каждой из этих стратегий.
Решения
Базовый вариант Kubernetes (Vanilla Kubernetes)
Вы всегда можете использовать Kubernetes без дополнительных инструментов. Обычно с него все и начинают. Базовый Kubernetes отличается гибкостью и расширяемостью, но ему не хватает дополнительных функций для мониторинга, управления состояниями, обеспечения доступности, управления жизненным циклом и т. д.
Преимущества | Недостатки |
• Стоимость: базовый вариант Kubernetes не требует лицензии. • Гибкость: у организаций есть почти полный контроль над конфигурациями и расширениями. • Установка в любой среде: базовый вариант Kubernetes можно установить локально, в любом облаке и в любой операционной системе. | • Недостаток навыков: Kubernetes с открытым исходным кодом — это самый сложный вариант с технической точки зрения, который требует очень глубокого понимания и обширных навыков. • Стоимость: хотя оплачивать лицензию и не нужно, наем и удержание специалистов по Kubernetes может требовать значительных расходов. • Время вывода продукта на рынок: создание собственных инструментов и платформ часто задерживает развертывание первых приложений в Kubernetes. Переход на Kubernetes занимает больше времени, первую отдачу от этих инвестиций организация заметит далеко не сразу. • Поддержка: организация должна поддерживать платформу своими силами или полагаться на сообщество Kubernetes. • Безопасность: готовые конфигурации Kubernetes не защищены, поэтому придется инвестировать в безопасность. |
Тип организации: Vanilla Kubernetes с открытым исходным кодом подойдет только технически подкованным компаниям, которые считают создание собственных инструментов и платформ своим ключевым конкурентным преимуществом. Если компания планирует использовать базовую версию Kubernetes, ей нужна сильная команда экспертов, которая будет оказывать поддержку и создавать инструменты в соответствии с бизнес-требованиями.
Платформа как услуга
Некоторые вендоры предлагают Kubernetes по модели «платформа как услуга» (PaaS), куда входит сам предварительно сконфигурированный Kubernetes и сопутствующие инструменты. Решения PaaS также обычно включают безопасность, сети и хранилище. Работать с таким вариантом обычно гораздо проще, чем с базовым. Кроме того, он обеспечивает согласованность по всей организации, поскольку ограничивает доступные возможности конфигурации и выбор инструментов и сервисов. Правда, в результате решения PaaS теряют большую часть гибкости и требуют больше усилий для обновления.
Преимущества | Недостатки |
• Быстрое обучение: PaaS требует не так много навыков, поэтому внедрить Kubernetes с его помощью гораздо проще. • Время вывода продукта на рынок: более быстрое обучение позволит ускорить выпуск приложений. • Безопасность: Kubernetes PaaS позволяет улучшить состояние безопасности в организации, особенно потому, что так проще применять лучшие методы безопасности по всей организации. | • Стоимость: предложения PaaS часто предлагаются по дорогостоящим лицензиям. За поддержку и дополнительные функции придется платить отдельно. • Зависимость от вендора: организации попадают в зависимость от вендора PaaS, и в будущем им будет сложнее сменить вендора или перейти на базовый вариант Kubernetes. • Проблемы с переносимостью: решения PaaS сложнее переносить между средами, что только усиливает зависимость от вендора. |
Тип организации: Kubernetes PaaS подходит для организаций без обширных технических навыков, которые хотят как можно скорее внедрить Kubernetes, не инвестируя внутренние ресурсы в создание инструментов или обучение. Если быстрый выпуск приложений важнее, чем низкие расходы или очень гибкая инфраструктура, PaaS будет хорошим вариантом.
Дистрибутивы Kubernetes в публичном облаке
Облачные дистрибутивы Kubernetes — это простой и удобный вариант. Как и при использовании решений PaaS, инфраструктурой Kubernetes управляет облачный провайдер. Он контролирует конфигурации и интеграцию инструментов. Основное различие между облачным Kubernetes и решениями PaaS — стоимость и переносимость рабочих нагрузок. Облачный Kubernetes дешевле, чем PaaS. Зато его невозможно использовать в мультиоблачной или гибридной среде.
Преимущества | Недостатки |
• Недостаток навыков: облачный Kubernetes — один из самых простых для реализации вариантов. Поскольку платформой управляет облачный провайдер, от специалистов компании потребуется минимум навыков. • Время вывода продукта на рынок: облачный Kubernetes можно внедрить очень быстро. Для него не требуются сложные соглашения с вендорами или инвестиции в настройку инструментов. • Безопасность: облачные дистрибутивы Kubernetes включают готовые конфигурации безопасности, поэтому организации не сталкиваются с риском уязвимостей из-за неправильной настройки. Облачный провайдер сам управляет исправлениями и обновлениями. • Стоимость: облачные дистрибутивы Kubernetes обычно экономически эффективнее решений PaaS. Организациям, только начинающим работу с Kubernetes, модель оплаты по мере использования покажется особенно привлекательной. | • Зависимость от вендора: облачные дистрибутивы Kubernetes невозможно использовать в мультиоблачной и гибридной среде. Кроме того, невозможно или почти невозможно сменить облачного провайдера, чтобы воспользоваться более выгодным предложением. • Стоимость: облачный Kubernetes обычно дешевле PaaS, но дороже локального Kubernetes, особенно для долгосрочных проектов с высокими требованиями к вычислительным нагрузкам. • Отсутствие гибкости: организациям доступны только те инструменты и функции, которые поддерживаются в определенном дистрибутиве. Сложно получить что-то сверх этого. |
Тип организации: организации без обширного штата специалистов по Kubernetes, которые хотят сэкономить, но при этом реализовать Kubernetes максимально быстро. Облачный Kubernetes часто подходит небольшим компаниям, а также организациям, которым, скорее всего, не понадобятся необычные функции или дополнительные инструменты, не входящие в дистрибутив Kubernetes.
Управляемые решения Kubernetes
Поставщики управляемого Kubernetes управляют кластерами Kubernetes за организацию — в своих ЦОД, в ЦОД заказчика или в публичном облаке. Управляемые услуги Kubernetes подразумевают поддержку, гарантию бесперебойной работы и выполнение всех сопутствующих задач за заказчика.
Преимущества | Недостатки |
• Недостаток навыков: управляемый Kubernetes почти не требует обучения — разработчики могут сразу приступить к работе над приложениями в Kubernetes, не изучая тонкости администрирования кластера. • Операции второго дня: вендор сам выполняет операции второго дня, вроде обновлений и исправлений, еще больше упрощая работу инженерам в организации. • Безопасность: в управляемые услуги входит установка исправлений для системы безопасности. Поставщики управляемых услуг несут гораздо больше ответственности за безопасность, чем провайдеры облачных дистрибутивов. • Мультиоблачная или гибридная среда: управляемые услуги — это самый простой способ реализовать предварительно сконфигурированную платформу Kubernetes. Он требует минимум навыков и позволяет перемещаться между публичными и частными облаками. | • Зависимость от вендора: при использовании управляемого решения Kubernetes организации не зависят от облачного провайдера, зато зависят от поставщика управляемых услуг. • Стоимость: управляемые услуги Kubernetes гораздо дороже, чем облачные дистрибутивы, но дешевле решений PaaS. • Недостаток гибкости: организациям доступны только те инструменты и функции, которые предлагает поставщик управляемых услуг. С одной стороны, не придется тратить время и силы на выбор инструментов, но с другой — нужные функции могут быть недоступны. |
Тип организации: организации, которые планируют использовать Kubernetes в мультиоблачной или гибридной среде. Управляемые услуги Kubernetes лучше всего подходят для организаций, у которых нет собственных экспертов по Kubernetes и которые хотят сосредоточиться на поставке приложений, а не управлении инфраструктурой.
Корпоративные платформы Kubernetes
Корпоративные платформы Kubernetes полностью поддерживают комплаенс и содержат инструменты, которые помогают организациям управлять всем жизненным циклом приложений и обычно предоставляют единую централизованную платформу для управления несколькими кластерами и средами. С помощью такой платформы централизованным командам проще контролировать конфигурации и управлять ресурсами по всей организации. Корпоративные платформы Kubernetes предоставляют гораздо больше гибкости по сравнению с остальными вариантами, кроме базовой версии Kubernetes.
Корпоративные платформы Kubernetes могут быть ориентированы на разработку или на эксплуатацию. Первые упрощают жизнь разработчикам, а вторые предоставляют больше возможностей для контроля эксплуатации и соблюдения требований к надежности и доступности.
Преимущества | Недостатки |
• Инструменты: корпоративные платформы Kubernetes оснащены полным набором инструментов, поэтому делать сложный выбор не придется. В то же время возможна интеграция с дополнительными инструментами. • Операции второго дня: корпоративные платформы Kubernetes направлены на управление всем жизненным циклом приложения, и инструменты для операций второго дня часто считаются одним из главных преимуществ этого варианта. • Мультиоблачная или гибридная среда: благодаря единой централизованной панели управления кластерами организация может использовать Kubernetes в мультиоблачной или гибридной среде без лишних сложностей, при этом обеспечивая соблюдения корпоративных политик управления во всех средах. Кроме того, при использовании корпоративных платформ рабочие нагрузки можно легко перемещать между средами. • Масштаб: корпоративные платформы Kubernetes лучше всего подойдут крупным компаниям, которые управляют множеством сред и сотнями кластеров. • Переносимость рабочих нагрузок: корпоративные платформы Kubernetes обычно упрощают перенос рабочих нагрузок между средами. | • Недостаток навыков: для успешной работы, а также дополнительной гибкости и контроля требуются эксперты по Kubernetes. Без собственных специалистов не обойтись, но достаточно будет небольшой централизованной команды, досконально разбирающейся в теме. • Стоимость: в зависимости от вендора стоимость лицензий и поддержки может быть существенной, особенно для небольших компаний или проектов. • Безопасность: за безопасность на корпоративной платформе Kubernetes обычно отвечает сама организация. Эффективное применение мер безопасность во многом зависит от функций, предлагаемых вендором. |
Тип организации: крупные компании со сложными мультиоблачными развертываниями и техническими специалистами, которые смогут реализовать всю гибкость корпоративной платформы Kubernetes. Лучше всего этот вариант подходит организациям, уже имеющим опыт работы с Kubernetes.
На какие задачи направлено каждое решение? В таблице приводится краткая сводка сильных сторон каждого решения. Максимальной считается оценка 5/5.
Vanilla Kubernetes | Платформа как Услуга | Дистрибутивы Kubernetes в публичном облаке | Управляемые решения Kubernetes | Корпоративные платформы Kubernetes | |
Стоимость | * * * * * | * | * * * | * * | * * * * |
Недостаток навыков | * | * * * * | * * * * * | * * * * * | * * * |
Мультиоблачная/ гибридная среда | * * * * | * | * * | * * * * | * * * * * |
Чрезмерное многообразие инструментов | * * | * * | * * * * | * * * * | * * * * |
Безопасность, сети и хранилище | * * | * * * * | * * * * | * * * | * * * |
Операции второго дня | * * | * * * | * * * | * * * * | * * * * |
Kubernetes от Canonical
Все крупные облачные дистрибутивы Kubetnetes и локальные варианты используют операционную систему Ubuntu.
Решения Canonical по поддержке помогают организациям преодолеть проблему недостатка навыков и быстрее реализовать ценность Kubernetes. Помимо поддержки Canonical предлагает несколько вариантов решения проблем, возникающих при внедрении Kubernetes.
Canonical настраивает кластеры Kubernetes и управляет ими, пока организация не будет готова взять эти задачи на себя. Этот вариант помогает организациям быстро перейти на Kubernetes, попутно обучая собственных специалистов. Кластеры можно настроить локально или в публичном облаке. Canonical будет отвечать за обновления, мониторинг и другие операции второго дня, а затем передаст управление внутренним специалистам организации.
Charmed Kubernetes — это корпоративная платформа Kubernetes на основе базового Kubernetes. Charmed Kubernetes сочетает в себе гибкость Kubernetes с открытым исходным кодом с одной стороны и возможности персонализации, тщательный подбор инструментов и централизованный операционный контроль — с другой. Помимо преимуществ большинства корпоративных платформ Kubernetes, с Charmed Kubernetes организации получают следующие возможности:
Автоматические обновления системы безопасности, управляемые Canonical, для сокращения объема инвестиций в безопасность.
Надежная и расширяемая экосистема инструментов для управления хранилищем, сетями и CI/CD.
Автоматизация жизненного цикла с помощью операторов Kubernetes на основе модели.
Переносимость рабочих нагрузок между средами и базовыми ресурсами.
Charmed Kubernetes предлагает разработчикам «контейнеры как услугу» для быстрой работы и легкого масштабирования. В то же время операторы сохраняют централизованный контроль и следят за соблюдением операционных требований и политик безопасности.
MicroK8s — это упрощенная версия Kubernetes, которая предлагает все функции обычного Kubernetes с самыми популярными надстройками. MicroK8s лучше всего подходит в условиях ограниченных ресурсов, например для установки на рабочей станции, IoT-устройстве или границе сети. MicroK8s обеспечивает тот же уровень безопасности, переносимость рабочих нагрузок и автоматизацию жизненного цикла, что и Charmed Kubernetes, но упрощает установку и процесс конфигурирования, чтобы пользователи могли как можно быстрее приступить к работе.
Заключение
Хотя организации стараются как можно скорее реализовать Kubernetes, они не могут игнорировать реальные бизнес-требования, связанные с безопасностью, доступностью и аварийным восстановлением. Каждая организация должна найти баланс между простотой использования, временем вывода продуктов на рынок и гибкостью, а также решить, за что она готова платить — за собственных специалистов по Kubernetes или за лицензии. Если организация хочет использовать Kubernetes для производственных рабочих нагрузок, особенно критичных для бизнеса, ей не подходит базовый вариант Kubernetes с открытым исходным кодом и без дополнительных конфигураций. Оптимальный подход к платформе Kubernetes корпоративного класса зависит от приоритетов и возможностей каждой компании.
