Последние сообщения

А не подскажите тогда, какие основные сложности с внедрением Kubernetes в организации?

Ясно, можете простыми словами объяснить почему организации так стремятся использовать контейнеры и Kubernetes? 

Виталий Стрекалов

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

Например:

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

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

— Более быстрый вывод продукта на рынок. Приложения можно не только быстрее разрабатывать, но и быстрее выводить на рынок, чтобы опередить конкурентов.

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

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

Почему Kubernetes?

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

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

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

Ясно, можете простыми словами объяснить почему организации так стремятся использовать контейнеры и Kubernetes? 

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

Ответ зависит от ряда факторов. Главный из них, предпочтительный для вас принцип управления рабочими нагрузками: с помощью Kubernetes или посредством стандартных инструментов публичного облака. На платформах Anthos и Tanzu, например, оркестратор с открытым кодом используется для координации всех процессов, тогда как в решениях вроде Outposts и Azure Stack для развертывания приложений и управления ими используются собственные облачные инструменты оператора (CloudWatch, CloudTrail, CloudFormation и т.д.). Если вы предпочитаете средства развертывания приложений и управления ими, которые предлагает сам оркестратор Kubernetes, возможно, стоит сделать выбор в пользу платформы, где есть эта возможность.

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

Неплохо также учесть долгосрочные перспективы самого Kubernetes. Сегодня он пользуется бешеной популярностью, в связи с чем платформу, собственно, и взяли на вооружение Google, VMware и другие компании, однако она появилась всего семь лет тому назад. Вполне возможно, что со временем Kubernetes уйдет в прошлое, как временное увлечение, а не станет одним из столпов мира ИТ.

Можно напомнить, что еще пять-шесть лет тому назад, когда о Kubernetes еще мало кто слышал, казалось, что технологическим миром будет править система контейнеризации Docker и что надо внедрять решения на ее основе. Но вышло по-другому: создатели Docker из одноименного стартапа раскрыли формат контейнеров, а Google передала сообществу Open Source свою разработку Kubernetes. В результате Docker стал лишь катализатором развития экосистемы Kubernetes. Альтернативой решению с открытым кодом мог бы стать оркестровщик контейнеров Mesosphere и другие, но поскольку Kubernetes взяли на вооружение тяжеловесы во главе с Microsoft, этого не произошло. Если история повторится, внедрять сейчас гибридную платформу на базе Kubernetes, — это все равно что несколько лет тому назад полностью перейти на Mesosphere. Все будет работать, пока будет сохраняться «хайп», но когда мода пройдет, возможно, понадобится полная перестройка.

И, напоследок, в процессе выбора стоит учесть еще один фактор. В целом гибридные облака на Kubernetes обеспечивают больше гибкости, чем среды, зависимые от собственных инструментов облачного оператора. Например, если вы пользуетесь Azure Stack, то в случае необходимости будет трудно перейти на AWS Outposts, ведь по сути это потребует полноценной миграции из Azure в AWS. А вот переход с Anthos на Tanzu пройдет проще (хотя тоже не идеально легко), поскольку обе платформы базируются на Kubernetes.

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

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

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

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

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

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

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

Задач кстати при помощи ИИ можно решить больше множество, например описание к товарам, создавать статьи для клуба, делать справочный центр для поставщиков и покупателей и ещё куча других вещей 

Нет, другие опции к этому отношения не имеют  

Все сработало, большое спасибо, а другие опции нужно снимать, например модератор, кладовщик? 

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

Сергей Андрющенко

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