Платформы контейнеризации широко используются, однако их эксплуатация сопровождается целым рядом проблем и сложностей. К чему надо быть готовым при развёртывании контейнеров? Как устранять проблемы с минимальными затратами?
- 1. Введение
- 2. Несколько слов о технологии контейнеризации
- 3. Почему возникают проблемы с K8s
- 4. Сложности с настройкой
- 5. Слепые зоны в мониторинге
- 6. Просадки в производительности
- 7. Другие проблемные точки K8s
- 8. Пути решения
- 9. Выводы
Введение
Бизнесу нужны не серверы, а сервисы, причём с минимальными затратами. В нынешней экономической ситуации это особенно важно. Технологии виртуализации и, как частный случай, контейнеризации позволяют запускать несколько экземпляров различных систем на одном физическом сервере.
Контейнеризация также позволяет изолировать приложения от основной среды исполнения, упрощает масштабирование за счёт кластеризации, сокращает сроки вывода сервисов в эксплуатацию. Поэтому отказаться от неё, по крайней мере до появления альтернативных технологий, невозможно, поскольку это приведёт к увеличению затрат. Особенно в нынешних условиях дефицита компонентов для производства серверного оборудования и значительного роста цен.
По итогам 2025 года, согласно данным Strategy Partners, общий объём российского рынка систем контейнеризации составил 5,4 млрд рублей, что на 26 % выше уровня 2024 года. На российские продукты приходилось 89 % рынка. Почти две трети рынка заняли три компании: «Флант», Basis и «Штурвал».
Также аналитики констатировали практически полное вытеснение внутренних разработок и продуктов с открытым кодом промышленными вендорскими решениями. Это связано с тем, что основной спрос обеспечивают крупные заказчики, которым нужны высокая масштабируемость, способность работать при высоких нагрузках, а в ряде случаев — и наличие сертификатов регуляторов.
Рисунок 1. Российский рынок контейнеризации, млрд рублей, фактические данные и прогноз Strategy Partners
Однако контейнеризация сопряжена с целым рядом особенностей, которые могут приводить к возникновению различных проблем при реальной эксплуатации. По мнению практически всех без исключения опрошенных нами экспертов, это обусловлено объективной сложностью технологии.
Решению различных проблем отводится значительное место на конференциях, и российская Kuber Community Day, которая в текущем году проводилась уже во второй раз, не стала исключением. По оценке участников форума, наиболее часто приходится сталкиваться со следующими сложностями:
- Следствия сложности конфигурирования кластеров Kubernetes.
- Особенности организации мониторинга инфраструктуры контейнеров, которые оставляют много «слепых зон».
- Резкое снижение производительности без каких-либо видимых причин.
Опытом их решения делились спикеры, представлявшие компании из разных отраслей, включая банки, маркетплейсы, розничные сети и поставщиков облачных услуг.
Несколько слов о технологии контейнеризации
Контейнеризация (синонимы – виртуализация на уровне операционной системы, контейнерная виртуализация, зонная виртуализация) является частным случаем виртуализации. В отличие от полноценной виртуализации, где на хостовой системе через специальное ПО или с помощью программно-аппаратной технологии запускается несколько гостевых операционных систем, при контейнеризации приложения запускаются внутри нескольких изолированных пользовательских пространств вместо одного.
Существует около полутора десятков реализаций технологии контейнеризации. Среди них есть как программные, так и программно-аппаратные. Некоторые из них предполагают использование практически полного эмулятора операционной системы, как, например, контейнеры Virtuozzo или встроенные в ОС Solaris, так и минимального окружения, как это сделано в наиболее часто используемых Jail или Docker. Некоторые считают частным случаем контейнеризации даже аппаратные разделы WPAR в IBM iSeries на базе ОС AIX.
Рисунок 2. Различия между виртуализацией и контейнеризацией
Технология Kubernetes позволяет объединять контейнеризированные приложения в кластеры. Также эта платформа содержит большой набор инструментов для управления и оркестрации основных операций с контейнерами, включая развёртывание и масштабирование. При этом Kubernetes (K8s) поддерживает практически все реально используемые технологии контейнеризации.
K8s был разработан в Google и изначально применялся для внутренних нужд компании. Затем исходный код был открыт, а развитие проекта передано Cloud Native Computing Foundation, аффилированной с Linux Foundation.
Рисунок 3. Архитектура Kubernetes
Ванильный K8s является свободным ПО. Однако его развёртывание требует глубоких знаний и соответствующих навыков. Кроме того, его использование для оказания сервисов может противоречить требованиям регуляторов. Эти проблемы отчасти решают коммерческие дистрибутивы, а также управляемые облачные сервисы. Такие продукты и сервисы предлагают и российские компании. Тем не менее, как показал опрос зрителей эфира AM Live «Kubernetes в крупном бизнесе: строить самому или использовать коробку вендора?», 37 % заявили, что используют ванильную версию.
Рисунок 4. Какую версию K8s вы используете. Результаты опроса зрителей AM Live
Почему возникают проблемы с K8s
Сложности с инфраструктурой K8s возникают, по мнению опрошенных нами экспертов, очень часто. Архитектор Nord Clan Владислав Степанов и вовсе считает, что сложности возникают практически во всех проектах. Они делятся на организационные (обычно связаны с нехваткой компетенций или издержками быстрого развития платформы) и технологические.
«Платформа умеет перезапускать контейнеры и распределять нагрузку, но не исправляет неверные настройки приложений, сетей, хранилищ и прав доступа. А чем больше кластеров, команд и обновлений, тем выше вероятность, что небольшая ошибка приведёт к сбою или деградации сервиса», — такими видит причины сбоев генеральный директор CorpSoft24 Константин Рензяев. Доля тех, кто сталкивается с трудностями, по оценкам различных исследований, зависит от отрасли и колеблется от трети до трёх четвертей организаций.
Как предупреждает директор по продукту платформы «Штурвал» Владимир Утратенко, разного рода сложности с платформой K8s возникают регулярно и затрагивают специалистов любого уровня независимо от их опыта. Это связано с высоким порогом входа в технологию: для эффективной работы необходима глубокая экспертиза как в контейнерной оркестрации, так и в управлении ИТ-инфраструктурой.
«Мы в "Платформе Боцман" видим: как только кластеров становится больше двух-трёх, а команд, использующих инсталляции, больше пяти, эксплуатация без платформенных инструментов превращается в хаос», — отметил руководитель продуктового направления платформы «Боцман» Артём Кижменев. По его оценке, с различными сложностями приходится сталкиваться в 90 % проектов.
Руководитель отдела администрирования и DevOps ГК Softline Александр Дёмин обратил внимание на то, что в наибольшей степени рискуют столкнуться с различными проблемами с K8s компании без зрелых DevOps-практик и выделенных SRE-команд. Уязвимы даже те, кто пользуется управляемыми облачными сервисами. По его наблюдениям, возникают сложности с безопасностью (RBAC, секреты, изоляция), сетевыми настройками (CNI, ingress), обновлениями кластера и управлением зависимостями. Также распространена проблема так называемого конфигурационного дрейфа и недостаточной стандартизации.
Руководитель департамента информационных технологий MONS (входит в ГК «КОРУС Консалтинг») Евгений Пивоваров считает, что это является обратной стороной гибкости и мощности платформы, платой за которые является сложность. Вопрос, по его мнению, лишь в масштабе: кто-то сталкивается с малозначительными сложностями, а у кого-то ошибки в настройке приводят к серьёзным последствиям. Наиболее велик риск столкнуться со сложностями, по наблюдениям Евгения, в первые два года эксплуатации платформы.
Директор по развитию компании UDV Group Максим Хараск назвал основной причиной сбоев быстрое, часто неконтролируемое разрастание инфраструктуры кластеров. Особенно если это происходит до того, как сформированы единые правила использования и контроля.
Как уточняет руководитель направления DevOps «Рексофт» Александр Кучин, когда речь идёт о небольших кластерах для сред разработки или сравнительно небольших приложений с несколькими десятками микросервисов (40–50), вероятность столкнуться с серьёзными эксплуатационными проблемами невысока. Но по мере роста инфраструктуры, увеличения нагрузки, внедрения дополнительных требований к безопасности, сетевой политике, отказоустойчивости и соответствию корпоративным стандартам сложность эксплуатации возрастает, как и вероятность сбоев.
Однако организации, которые используют проверенные архитектурные решения, следуют лучшим практикам и внедряют автоматизацию управления кластерами, значительно снижают риск возникновения эксплуатационных ошибок.
Сложности с настройкой
Для настройки кластеров K8s используются текстовые конфигурационные файлы в формате YAML. Он похож на XML и JSON, но минималистичнее и ориентирован на создание протоколов автоматизации. Он используется не только для конфигурирования кластеров из контейнеров, но и в некоторых редакциях платформы OpenStack, Ruby on Rails, Dancer, Symfony, GAE Framework, Google App Engine и Dart.
Однако, как отметил в своём выступлении руководитель направления по развитию платформ разработки «Райффайзенбанка» Владимир Романов, конфигурирование K8s с помощью YAML даёт 36 возможностей для ошибки.
Ошибки в YAML, как считает руководитель центра разработки «Базис» Филипп Игнатенко, обычно связаны не столько с самим синтаксисом, сколько с отсутствием полноценной проверки манифестов до их применения в кластере. Если в CI/CD-конвейере нет валидации по схемам, проверки политик и даже базового линтера, ошибка легко доходит до промышленной среды.
По мнению Константина Рензяева, проблемы с YAML имеют более глубокую природу. Они связаны с отсутствием проверок конфигураций, тестового контура и контроля изменений. Смежные проблемы с обновлениями Kubernetes, безопасностью и управлением доступом реже заметны в повседневной работе, но именно там ошибка может иметь наиболее тяжёлые последствия.
Как напомнил Владимир Утратенко, согласно отчёту Komodor Enterprise Kubernetes Report 2025, большинство инцидентов в продуктивной среде Kubernetes вызваны изменениями конфигурации. В среднем команды тратят 134 рабочих часа в год на обнаружение и 141 час на разбор подобных проблем. 38 % организаций сталкиваются с высококритичными авариями как минимум раз в неделю, а 62 % компаний оценивают стоимость одного часа простоя в один млн долларов. Причём ошибки в YAML — одна из типовых причин инцидентов, с которыми сталкиваются те, кто обслуживает инфраструктуру K8s.
«Ошибки в YAML действительно встречаются часто, только причина обычно глубже синтаксиса. В конфигурации нужно описать структуру развёртывания и выбрать образы. Там же задаются лимиты ресурсов и связи с другими контейнерами. Ошибка в одном параметре может повлиять на весь сервис», — говорит старший партнёр интегратора «Энсайн» Алексей Постригайло.
Технический директор компании «Смарт Бизнес Автоматизация» Андрей Фатеев назвал сложность написания конфигураций и правильную настройку ограничений для приложений, чтобы они не мешали друг другу, главными проблемами для пользователей K8s, прежде всего на начальной стадии эксплуатации. Это связано с высоким уровнем динамичности самой среды, и из-за одной неверной строчки в настройках система начинает работать медленнее или скрывать сбои.
Александр Дёмин также назвал ошибки в конфигурационных файлах типовой, но при этом критичной проблемой. Из-за декларативного подхода языка YAML даже небольшая неточность может привести к некорректному развёртыванию или сбоям в работе кластеров.
«Один неверный отступ, неправильно указанный параметр или забытый лимит ресурсов, и приложение либо вообще не запускается, либо начинает работать совсем не так, как ожидалось. Даже опытные инженеры регулярно используют автоматические проверки конфигураций, потому что вручную отследить все нюансы становится сложно», — делится своими наблюдениями Евгений Пивоваров. По его оценке, ошибки в YAML являются характерной чертой K8s.
Как дополнил Артём Кижменев, среди последствий неправильных настроек — регулярные зависания и перезапуски элементов кластера, что вызвано ошибками в параметрах сервисных учётных записей.
Как рассказала в своём выступлении на конференции Kuber Community Day инженер группы DevOps-экспертизы MTS Web Services Анастасия Калугина, часто ошибки в конфигурациях являются последствиями штатного обновления как хостовой системы, так и самой платформы. С подобным довольно часто сталкиваются пользователи практически всех Unix-подобных систем. Наиболее распространённым последствием таких ошибок, по наблюдениям Анастасии, является рассинхронизация узлов кластеров, что, в свою очередь, приводит к снижению общей производительности. Не редкость и полная потеря работоспособности платформы.
Как отметил Филипп Игнатенко, неправильный подход к обновлениям повышает риски. Если этот процесс происходит не регулярно, а с пропуском каких-то релизов, вероятность проблемных обновлений, в том числе тех, при которых может быть изменён конфигурационный файл, возрастает.
Слепые зоны в мониторинге
Сложности с организацией мониторинга в среде K8s носят объективный характер. Это связано с высокой изменчивостью состояния контейнеров. Артём Кижменев даже привёл сравнение K8s с «котом Шрёдингера»: разные компоненты появляются и исчезают десятки раз в минуту.
Также, как напоминает Евгений Пивоваров, срок жизни контейнеров иногда составляет лишь десятки минут. В целом инфраструктура очень изменчива, поэтому классические подходы к мониторингу просто не работают. Владимир Утратенко на круглом столе «Цена кривого деплоя K8s» даже поделился таким наблюдением: если статусы в Zabbix горят зелёным, значит, с инфраструктурой K8s случилось что-то очень серьёзное.
Алексей Постригайло обратил внимание на то, что сбор журналов приложений в K8s из коробки не реализован. А именно комплекс из метрик, логов и трассировок, по мнению Александра Дёмина, необходим для создания полноценной системы мониторинга. Классические подходы к её построению в такой динамичной среде, как кластеры контейнеров, не работают.
По мнению Филиппа Игнатенко, проблемы с мониторингом чаще возникают из-за отсутствия единой модели наблюдаемости. Команды собирают метрики инфраструктуры, но не связывают их с показателями, которые отражают качество работы сервиса для пользователя.
Как подчеркнул Андрей Фатеев, создание системы мониторинга является одним из главных вызовов в процессе эксплуатации инфраструктуры K8s. Без этого невозможно решить комплекс возникающих проблем.
Без полноценного мониторинга, по мнению Максима Хараска, персонал не видит, какие контейнеры продолжают использоваться, какие уже заброшены, где вычислительных ресурсов не хватает, а где они расходуются избыточно. В результате сложнее находить причины сбоев, растёт количество конфигурационных ошибок и увеличиваются затраты на инфраструктуру.
Просадки в производительности
Эта проблема наиболее коварна и неприятна. Она может быть как следствием ошибок или нарушений в конфигурации кластера, так и результатом ошибок разработчиков контейнеризированных приложений или аппаратной инфраструктуры. Причём, как поделился своим наблюдением руководитель направления DevOps в «ПочтаТех» Василий Куценко, частота просадок производительности в контейнеризированных приложениях прямо коррелирует с их значимостью для бизнеса.
Как отметил Филипп Игнатенко, просадки производительности в большинстве случаев связаны с неверно заданными гарантированными и максимальными объёмами ресурсов для контейнеров. Это приводит к троттлингу из-за ограничений CPU, вытеснению подов, переподписке узлов и другим проблемам с распределением ресурсов. Реже причиной становятся задержки дисковой подсистемы, влияющие на etcd, или накладные расходы сети. Эти проблемы, по оценке Филиппа, являются одними из типовых, возникающих в ходе эксплуатации инфраструктуры K8s.
По мнению Владислава Степанова, часто причиной снижения производительности является избыточное резервирование ресурсов: больше половины подов запрашивают больше CPU и памяти, чем реально потребляют. Артём Кижменев привёл данные Kubecost, согласно которым до 50 % ресурсов заказывается, но не используется. В итоге каким-то подам и контейнерам их может не хватать.
Андрей Фатеев даже сравнил поведение контейнеризированных приложений с шумными соседями по коммуналке. Одно прожорливое приложение может случайно забрать себе все ресурсы, из-за чего остальные сервисы просто отключатся. Кроме того, они могут перегрузить внутреннюю сеть своими запросами или «застрять» при автоматическом переезде с одного сервера на другой. Андрей советует сразу разделить приложения по изолированным комнатам, закрыть им доступ к чужим данным и установить для каждого жёсткие лимиты на процессорное время и память, выше которых они физически не смогут подняться.
Александр Кучин выразил такое мнение:
«Чаще речь идёт о правильном планировании ресурсов, распределении нагрузки и проектировании инфраструктуры. Это уже область capacity planning и архитектуры системы. На небольших кластерах такие проблемы встречаются редко, а вот в крупных инфраструктурах, где работают сотни сервисов и предъявляются высокие требования к производительности и отказоустойчивости, они действительно становятся актуальными.
Лучший способ минимизировать подобные проблемы — выстраивать грамотную эксплуатацию с самого начала. Это включает регулярное обучение специалистов, изучение новых возможностей и изменений в каждой версии Kubernetes, своевременные обновления, использование лучших практик сообщества и периодический аудит собственной инфраструктуры.
Важно регулярно задавать себе вопросы: “Какие риски есть в текущей архитектуре?”, “Что произойдёт при отказе того или иного компонента?”, “Какие процессы можно автоматизировать?”. Такой проактивный подход позволяет значительно снизить вероятность возникновения критических проблем и сделать эксплуатацию кластера более предсказуемой и надёжной».
По мнению участников круглого стола «Цена кривого деплоя K8s», проблемы с производительностью часто связаны с низким качеством самих контейнеризированных приложений. Разработчики очень часто не учитывают специфику контейнерных сред, что приводит к плачевным результатам.
Руководитель отдела наблюдаемости и надёжности инфраструктуры «Петрович Тех» Антон Скутин также посетовал на резкое снижение качества кода из-за массового использования сервисов генеративного искусственного интеллекта. Как показывают исследования, такие инструменты применяют до 80 % российских компаний. При этом 95 % из них осознают связанные с этим риски.
В качестве примера Анастасия Калугина привела некорректный SQL-запрос в одном из приложений, который вызывал перегрузку ввода-вывода. Выявлять такие ошибки, по крайней мере с помощью традиционных инструментов, довольно сложно.
Также участники дискуссии «Цена кривого деплоя K8s» напомнили, что многие пытаются контейнеризировать приложения, которые плохо работают в такой среде. Это, например, серверы баз данных. К слову, этот класс приложений всегда был довольно проблемным для сред виртуализации. Основные вендоры и сообщества разработчиков продуктов с открытым кодом только в середине 2010-х годов адаптировали основные СУБД к работе в виртуальных средах. До этого делать это категорически не рекомендовалось.
Другие проблемные точки K8s
Есть и другие сложности, связанные с эксплуатацией инфраструктуры K8s. Прежде всего, они связаны с обеспечением безопасности контейнеров. Для этого существуют специализированные средства защиты, но есть немало разнообразных нюансов, обусловленных спецификой самой инфраструктуры.
Для многих насущных задач готовых решений до сих пор не существует. На это посетовал, в частности, ИБ-директор «СберЗдоровья» Дмитрий Тараненко применительно к построению системы защиты персональных данных, особенно высоких категорий.
«До сих пор встречаются кластеры, где сервисные аккаунты имеют избыточные права, отсутствуют NetworkPolicy, контейнеры запускаются в привилегированном режиме, а секреты хранятся в открытом виде в манифестах. Если злоумышленник получает доступ хотя бы к одному контейнеру, подобные ошибки значительно упрощают дальнейшее развитие атаки внутри кластера», — предупреждает Евгений Пивоваров.
Владимир Утратенко обратил внимание на то, что многие заказчики связаны регуляторными требованиями: они подпадают под требования законодательства о защите критической информационной инфраструктуры, приказа ФСТЭК России № 117 и прочих нормативных актов. Однако сертифицированные дистрибутивы могут иметь ограниченную функциональность. Возникает «вилка» между тем, как обеспечить необходимые требования, с одной стороны, и максимальный набор функций — с другой.
Также, как отметил Филипп Игнатенко, многие проблемы не обсуждают на конференциях. Причём именно они наиболее значимы и болезненны. Применительно к инфраструктуре K8s Филипп назвал последствия некорректных обновлений, нарушения прав доступа и вопросы, связанные с хранением данных. Также риски связаны с попытками использования непроверенных дистрибутивов и готовых контейнеризированных приложений из публичных источников.
Довольно остро, как обратил внимание представитель «Базиса», стоит также проблема сайзинга оборудования. По его наблюдениям, нередка ситуация, когда утилизация кластера составляет 20–30 %, но при этом лицензии на ПО оплачены полностью.
Пути решения
Основным способом решения проблем с конфигурированием является применение средств автоматизации. Владимир Романов подчеркнул, что при достижении определённого уровня сложности о ручном создании YAML-файлов речи уже не идёт. Он поделился опытом использования инструмента на базе Flux, который команда «Райффайзенбанка» применяет для создания и отладки конфигурационных файлов для кластеров K8s.
«Если говорить про YAML, то сообщество уже давно выработало инструменты, которые позволяют избежать большинства типичных ошибок. Существуют линтеры, валидаторы, механизмы проверки схем, а также процессы CI/CD, которые позволяют обнаружить некорректные манифесты ещё до их применения. Конечно, инженеру всё равно необходимо понимать, что именно он описывает, как устроено приложение и какие объекты Kubernetes используются. Но на практике эту сложность часто удаётся снизить за счёт использования более высокоуровневых инструментов, таких как Helm», — рекомендует Александр Кучин.
Что касается создания систем мониторинга, то, как предупреждает Илья Кукшинов, готовых рецептов нет. В «СберЗдоровье» инструментарий мониторинга, который позволял закрыть «слепую» зону, оставляемую штатными средствами платформы, разрабатывали самостоятельно.
Есть примеры и того, когда для мониторинга ИТ-инфраструктуры, в том числе кластеров K8s, использовали не традиционные системы вроде Zabbix и его версий от различных вендоров, а, например, SIEM-системы. Но, опять же, для этого применяли решения собственной разработки. И такая практика, как оказалось, довольно широко распространена в крупных российских компаниях.
Александр Кучин считает, что здесь существуют проверенные шаблоны и стеки мониторинга, которые позволяют наблюдать не только за контейнерами, но и за состоянием самого Kubernetes-кластера, его компонентами, приложениями и потреблением ресурсов.
«Для снижения рисков нужны автоматическая проверка конфигураций и предварительное тестирование. Отдельно следует контролировать сеть и состояние серверов. Журналы нужно собирать централизованно, а восстановление регулярно проверять», — рекомендует Алексей Постригайло. Он также советует внимательнее присмотреться к управляемым облачным сервисам, особенно если нет квалифицированной опытной команды. В этом случае решение внешнего поставщика обойдётся существенно дешевле.
«Снижать риски нужно комплексно: хранить конфигурации в Git, автоматически проверять YAML и политики до развёртывания, собирать метрики, логи и трассировки, задавать обоснованные лимиты ресурсов, регулярно обновлять кластер и обязательно проверять восстановление из резервной копии на практике», — такие советы даёт Константин Рензяев.
Владимир Утратенко назвал главной задачей средств автоматизации снижение когнитивной нагрузки на команды эксплуатации и уменьшение требований к уровню экспертизы. И зарубежный, и российский рынки постепенно движутся в сторону решений, которые берут на себя всё больше технической сложности: упрощают развёртывание, автоматизируют рутинные операции и снижают зависимость от узкопрофильных специалистов.
Есть примеры успешного применения средств с искусственным интеллектом для поиска и автоматического устранения целого комплекса проблем, связанных с поиском ошибок конфигурации и разного рода «узких мест» в инфраструктуре. Таким опытом поделилась Анастасия Калугина. Несмотря на то что он оказался не вполне однозначным из-за галлюцинаций моделей, которые могли выдавать полностью выдуманные сообщения о проблемах или отчётах на непонятном языке (не русском и не английском), всё же удалось создать работающую систему, которая позволяет успешно решать все поставленные задачи.
Что касается просадок производительности, то здесь сложнее всего. Однако, как сообщил, ссылаясь на личный опыт, Василий Куценко, в 90 % случаев это является прямым следствием недостатка места на дисках.
Филипп Игнатенко рекомендует манифесты и образы проверять ещё на стадии разработки, требования оформлять в виде автоматически применяемых политик, а конфигурации инфраструктуры хранить в Git и развёртывать через GitOps. Важно также регулярно проводить учения по восстановлению, строить наблюдаемость вокруг пользовательских показателей и предоставлять разработчикам готовые проверенные шаблоны вместо полностью «чистого» Kubernetes.
Залогом успеха здесь, как подчеркнул Александр Дёмин, являются зрелость процессов и наличие экспертизы, а не только выбор технологий.
Евгений Пивоваров обращает внимание на то, что команды часто недооценивают необходимость и значимость резервного копирования. Многие уверены, что, если приложение контейнеризировано, его всегда можно быстро развернуть заново. На практике восстанавливать нужно не только контейнеры, но и данные, состояние кластера, конфигурации и секреты. Во время реальных инцидентов именно отсутствие проверенных процедур восстановления нередко становится причиной длительного простоя.
Выводы
Основная масса наиболее неприятных проблем, связанных с эксплуатацией инфраструктуры K8s, обусловлена ошибками разработчиков контейнеризированных приложений или ошибками при проектировании аппаратной инфраструктуры. Чуть реже возникают проблемы, связанные с неправильными настройками.
В качестве средств устранения этих сложностей эксперты рекомендуют использовать средства автоматизации, в том числе с применением искусственного интеллекта. Также необходимо развивать экспертизу и повышать зрелость процессов. Если же это невозможно сделать в обозримой перспективе, то лучшим решением станет переход на управляемую облачную инфраструктуру. Это позволит существенно снизить затраты и избежать многих ошибок, связанных с сайзингом оборудования и расчётом стоимости лицензий на ПО.
