[Kubernetes, Анализ и проектирование систем] K8s в проде и в разработке: четыре мифа (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Начав экспериментировать с Kubernetes, многие сталкиваются с одним из самых больших заблуждений: они считают в проде K8s будет работать так же, как и в среде разработки или тестирования.Не будет.Когда речь заходит о Kubernetes, и вообще о контейнерах и микросервисах, существует большая разница между запуском в «лабораторных» условиях и в полноценной эксплуатации. Такая же разница, как между просто запуском и запуском с обеспечением безопасности и надёжности.В этом утверждении есть важный исходный постулат: это проблема не Kubernetes, а всего разнообразия контейнеров и микросервисов. Развернуть контейнер относительно «просто». А использовать и масштабировать контейнеры (и контейнеризированные микросервисы) в боевой среде уже значительно сложнее.С оркестрацией контейнеров обычно та же ситуация. Например, компания The New Stack три года назад провелаисследование и выяснила, что внедрение контейнеров подтолкнуло к внедрению Kubernetes, потому что компании искали мощную технологию, способную помочь им в решении сложных эксплуатационных задач. Хотя у Kubernetes есть альтернативы, однако он быстро стал синонимом оркестрации и стандартом де-факто. И может быть большая разница между запуском K8s в песочнице и в боевых условиях.Когда ИТ-специалисты начинают работать с контейнерами и K8s в небольших объёмах, они могут столкнуться с резким подъёмом кривой обучения, переходя от «локальной настройки» к «выкатыванию в прод». Рекомендую развеять некоторые заблуждения, прежде чем вы окажетесь в такой ситуации. Об этом нужно думать заранее.Миф первый: запуск Kubernetes в среде разработки или тестирования гарантирует, что ваши эксплуатационные потребности будут удовлетвореныВ реальности: запуск Kubernetes в среде разработки или тестирования позволяет кое-что упростить или вообще не возиться с эксплуатационной нагрузкой, которая появится при выкатывании в прод. Соображения эксплуатации и безопасности — это главные сферы, в которых проявляется разница между запуском K8s в бою и в среде разработки или тестирования. Потому что если кластер упадёт в лабораторных условиях, то в этом ничего страшного нет.Разницу между запуском в проде и запуском в одной из сред можно сравнить с разницей между гибкостью (agility) и гибкостью в сочетании с надёжностью и производительностью. И в последнем случае придётся поработать.Разработчики используют контейнеры, чтобы добиться гибкости работы с приложениями при разработке, а также для тестирования новых приложений и кода. А эксплуатационщикам нужно обеспечивать надёжность, масштабирование, производительность и безопасность, которая требует применения устойчивой, проверенной временем платформы корпоративного уровня.Повышается критичность автоматизации при использовании Kubernetes (и вообще контейнеров) в бою. Нужно автоматизировать развёртывание эксплуатационных кластеров, чтобы обеспечить повторяемость процесса и гарантировать согласованность. Также это помогает при восстановлении работы системы.Также для операций в проде критически важно версионирование. По мере возможности управлять версиями нужно везде, в том числе в конфигурации развёртывания сервисов, политиках и инфраструктуре (посредством подхода инфраструктура-как-код). Это обеспечивает повторяемость сред. Также обязательно версионируйте образы контейнеров, не нужно применять тэг «последний» для развёртывания в средах, так можно легко прийти к разнобою версий.Миф второй: вы обеспечили надёжность и безопасностьВ реальности: если вы используете Kubernetes только в небоевых средах, то скорее всего не обеспечили, по крайней мере пока. Но не расстраивайтесь, вы к этому придёте. Это лишь вопрос планирования и проработки архитектуры до выкатывания в прод.Очевидно, что в боевых средах выше требования к производительности, масштабированию, доступности и безопасности. Важно закладывать эти требования в архитектуру и встраивать управление безопасностью и масштабированием в планы по развертыванию K8s, в графики Helm и т.д.Как эксперименты в среде разработки или тестирования могут привести к ложной уверенности?Это нормально, когда в упомянутых средах открыты все сетевые подключения. Возможно, даже желательно убедиться, что любой сервис может обратиться к любому другому сервису. Открытые подключения — это настройка по умолчанию в Kubernetes. Но в боевой среде такой подход вряд ли будет разумным, потому что простои и увеличение атакуемых площадей представляют очень большую угрозу для бизнеса.Когда речь идёт о контейнерах и микросервисах, нужно потратить немало усилий, чтобы создать высоконадёжную, высокодоступную систему. В этом нам помогает оркестрация, но она не волшебная палочка. Всё то же самое касается и безопасности. Придётся много потрудиться, чтобы защитить Kubernetes и уменьшить атакуемую площадь. Очень важно перейти к модели с минимальными привилегиями и принудительным использованием сетевых политик, оставив только те каналы связи, которые нужны сервисам.Уязвимости образов контейнеров могут быстро превратиться в критическую проблему эксплуатационной среды, а в средах разработки и тестирования опасность может быть невелика или вообще отсутствовать. Обращайте внимание, какие базовые образы вы используете для сборки контейнеров. По мере возможности используйте доверенные официальные образы, или раскатывайте собственные. В локальной среде может быть проще использовать неизвестные образы, но это создаёт риски для безопасности. Вряд ли вам захочется, чтобы ваш Kubernetes-кластер помогал кому-то майнить крипту.Рекомендуется относиться к безопасности контейнеров как к десятиуровневой системе, охватывающей стек контейнеров (хост и реестры), а также вопросы, связанные с жизненным циклом контейнеров (например, управление API). Подробно об этих десяти уровнях и их связи с инструментами оркестрации вроде Kubernetes рассказывается в подкасте со специалистом по безопасности из Red Hat, а также в статье Ten Layers of Container Security.Миф третий: оркестрация превращает масштабирование в пустякВ реальности: хотя профессионалы обычно считают оркестраторы вроде Kubernetes совершенно необходимым инструментом для масштабирования контейнеров, будет заблуждением думать, что оркестрация сразу облегчит масштабирование в эксплуатационной среде. Объём данных там гораздо больше, и вашему мониторингу тоже потребуется масштабирование. С ростом объёмов всё меняется. Невозможно удостовериться в полноценной реализации интерфейсов всех компонентов K8s, пока не выкатишь их в прод. Не получится автоматически определять, что Kubernetes работает нормально, и что API-сервер и другие управляющие компоненты масштабировались в соответствии с вашими потребностями.Повторюсь, в средах разработки и тестирования всё может выглядеть несколько проще. И со временем придётся поработать над тем, чтобы удовлетворить потребности и поддерживать это состояние. В локальных средах легко пропустить какие-то основы, например, прописывание правильных ресурсов и ограничений на запросы. А если не сделать этого в проде, то однажды у вас может всё рухнуть.Масштабирование кластера в ту или другую сторону — основной пример, когда задача может выглядеть просто при локальных экспериментах, но явно усложняется в боевой среде. Продуктивные кластеры масштабировать сложнее, чем кластеры для разработки или наладки. Хотя в Kubernetes довольно просто масштабировать приложения горизонтально, но DevOps нужно помнить о некоторых нюансах, особенно когда речь идёт о поддержании работы сервисов при масштабировании инфраструктуры. Важно убедиться, что основные сервисы, а также системы оповещения об уязвимостях и нарушении безопасности, были распределены по узлам кластера и работали со stateful-томами, чтобы данные не терялись при масштабировании вниз.Как и в случае с другими задачами, всё дело в правильном планировании и ресурсах. Вам нужно понимать свои потребности в масштабировании, планировать, а главное — тестировать. Ваша продуктивная среда должна выдерживать гораздо более высокие нагрузки.Миф четвёртый: Kubernetes везде работает одинаковоВ реальности: различия в работе в разных средах могут быть подобно тому, как различается запуск Kubernetes на ноутбуке разработчика и на боевом сервере. Многие считают, что если K8s работает локально, то он будет работать и в любой эксплуатационной среде. Хотя он обеспечивает согласованные среды, однако в зависимости от вендора могут быть серьёзные отличия.Для ввода кластера в промышленную эксплуатацию нужны компоненты, которых в локальных средах обычно нет: мониторинг, журналирование, управление сертификатами и учётными данными. Вам нужно это учитывать, это одна из главных проблем, усиливающих разницу между боевыми средами и средами разработки и тестирования.Впрочем, всё сказанное относится не столько к Kubernetes, сколько к контейнерам и микросервисам в целом, особенно в гибридных облачных и многооблачных средах.Публично-приватные внедрения Kubernetes сложнее, чем кажется на бумаге, потому что многие необходимые сервисы являются проприетарными, например, балансировщики нагрузки и файрволы. Контейнер, который прекрасно работает в локальной среде, в облаке с другим набором инструментов может вообще не запуститься, или работать в незащищённом режиме. Поэтому технологии service mesh вроде Istio привлекают столько внимания. Они обеспечивают доступность сервисов приложений везде, где работает ваш контейнер, так что вам не нужно думать об инфраструктуре — а это главная фишка контейнеров.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Kevin Casey
===========Похожие новости:
- [Java, Open source, Openshift, Учебный процесс в IT] 10 Kubernetes-инструментов из разряда «важно», шпаргалка по созданию Kubernetes-операторов на Java… и многое другое
- [DevOps, Kubernetes, Серверное администрирование, Системное администрирование] Обновлённый анонс обновлённых интенсивов: Kubernetes oт альфы до омеги
- [Виртуализация, Администрирование баз данных, Хранение данных] Вебинар «Интернет-магазин в облаке: с 0 до Aliexpress» 22 сентября от Mail.ru Group
- [Kubernetes, Системное администрирование] Как получить идеальный курс? Сделать самому
- [PostgreSQL, Резервное копирование] Как вписать «свободную» PostgreSQL в суровое enterprise окружение
- [PHP, Анализ и проектирование систем, Конференции, Микросервисы] 26 сентября приглашаем на оффлайн-митап HOT Backend&Web в Краснодаре
- [IT-стандарты, Анализ и проектирование систем] Как создать шаблон описания системы и начать его использовать
- [DevOps, Kubernetes, Системное администрирование, Серверное администрирование] Эфемерные тома с отслеживанием емкости хранилища: EmptyDir на стероидах (перевод)
- [DevOps, Kubernetes] Простое объяснение CRD в Kubernetes и как его использовать (перевод)
- [*nix, DevOps, Git, Kubernetes, Системное администрирование] Разбираемся с Custom Tooling в Argo CD
Теги для поиска: #_kubernetes, #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_kubernetes, #_k8s, #_blog_kompanii_infosistemy_dzhet (
Блог компании Инфосистемы Джет
), #_kubernetes, #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:26
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Начав экспериментировать с Kubernetes, многие сталкиваются с одним из самых больших заблуждений: они считают в проде K8s будет работать так же, как и в среде разработки или тестирования.Не будет.Когда речь заходит о Kubernetes, и вообще о контейнерах и микросервисах, существует большая разница между запуском в «лабораторных» условиях и в полноценной эксплуатации. Такая же разница, как между просто запуском и запуском с обеспечением безопасности и надёжности.В этом утверждении есть важный исходный постулат: это проблема не Kubernetes, а всего разнообразия контейнеров и микросервисов. Развернуть контейнер относительно «просто». А использовать и масштабировать контейнеры (и контейнеризированные микросервисы) в боевой среде уже значительно сложнее.С оркестрацией контейнеров обычно та же ситуация. Например, компания The New Stack три года назад провелаисследование и выяснила, что внедрение контейнеров подтолкнуло к внедрению Kubernetes, потому что компании искали мощную технологию, способную помочь им в решении сложных эксплуатационных задач. Хотя у Kubernetes есть альтернативы, однако он быстро стал синонимом оркестрации и стандартом де-факто. И может быть большая разница между запуском K8s в песочнице и в боевых условиях.Когда ИТ-специалисты начинают работать с контейнерами и K8s в небольших объёмах, они могут столкнуться с резким подъёмом кривой обучения, переходя от «локальной настройки» к «выкатыванию в прод». Рекомендую развеять некоторые заблуждения, прежде чем вы окажетесь в такой ситуации. Об этом нужно думать заранее.Миф первый: запуск Kubernetes в среде разработки или тестирования гарантирует, что ваши эксплуатационные потребности будут удовлетвореныВ реальности: запуск Kubernetes в среде разработки или тестирования позволяет кое-что упростить или вообще не возиться с эксплуатационной нагрузкой, которая появится при выкатывании в прод. Соображения эксплуатации и безопасности — это главные сферы, в которых проявляется разница между запуском K8s в бою и в среде разработки или тестирования. Потому что если кластер упадёт в лабораторных условиях, то в этом ничего страшного нет.Разницу между запуском в проде и запуском в одной из сред можно сравнить с разницей между гибкостью (agility) и гибкостью в сочетании с надёжностью и производительностью. И в последнем случае придётся поработать.Разработчики используют контейнеры, чтобы добиться гибкости работы с приложениями при разработке, а также для тестирования новых приложений и кода. А эксплуатационщикам нужно обеспечивать надёжность, масштабирование, производительность и безопасность, которая требует применения устойчивой, проверенной временем платформы корпоративного уровня.Повышается критичность автоматизации при использовании Kubernetes (и вообще контейнеров) в бою. Нужно автоматизировать развёртывание эксплуатационных кластеров, чтобы обеспечить повторяемость процесса и гарантировать согласованность. Также это помогает при восстановлении работы системы.Также для операций в проде критически важно версионирование. По мере возможности управлять версиями нужно везде, в том числе в конфигурации развёртывания сервисов, политиках и инфраструктуре (посредством подхода инфраструктура-как-код). Это обеспечивает повторяемость сред. Также обязательно версионируйте образы контейнеров, не нужно применять тэг «последний» для развёртывания в средах, так можно легко прийти к разнобою версий.Миф второй: вы обеспечили надёжность и безопасностьВ реальности: если вы используете Kubernetes только в небоевых средах, то скорее всего не обеспечили, по крайней мере пока. Но не расстраивайтесь, вы к этому придёте. Это лишь вопрос планирования и проработки архитектуры до выкатывания в прод.Очевидно, что в боевых средах выше требования к производительности, масштабированию, доступности и безопасности. Важно закладывать эти требования в архитектуру и встраивать управление безопасностью и масштабированием в планы по развертыванию K8s, в графики Helm и т.д.Как эксперименты в среде разработки или тестирования могут привести к ложной уверенности?Это нормально, когда в упомянутых средах открыты все сетевые подключения. Возможно, даже желательно убедиться, что любой сервис может обратиться к любому другому сервису. Открытые подключения — это настройка по умолчанию в Kubernetes. Но в боевой среде такой подход вряд ли будет разумным, потому что простои и увеличение атакуемых площадей представляют очень большую угрозу для бизнеса.Когда речь идёт о контейнерах и микросервисах, нужно потратить немало усилий, чтобы создать высоконадёжную, высокодоступную систему. В этом нам помогает оркестрация, но она не волшебная палочка. Всё то же самое касается и безопасности. Придётся много потрудиться, чтобы защитить Kubernetes и уменьшить атакуемую площадь. Очень важно перейти к модели с минимальными привилегиями и принудительным использованием сетевых политик, оставив только те каналы связи, которые нужны сервисам.Уязвимости образов контейнеров могут быстро превратиться в критическую проблему эксплуатационной среды, а в средах разработки и тестирования опасность может быть невелика или вообще отсутствовать. Обращайте внимание, какие базовые образы вы используете для сборки контейнеров. По мере возможности используйте доверенные официальные образы, или раскатывайте собственные. В локальной среде может быть проще использовать неизвестные образы, но это создаёт риски для безопасности. Вряд ли вам захочется, чтобы ваш Kubernetes-кластер помогал кому-то майнить крипту.Рекомендуется относиться к безопасности контейнеров как к десятиуровневой системе, охватывающей стек контейнеров (хост и реестры), а также вопросы, связанные с жизненным циклом контейнеров (например, управление API). Подробно об этих десяти уровнях и их связи с инструментами оркестрации вроде Kubernetes рассказывается в подкасте со специалистом по безопасности из Red Hat, а также в статье Ten Layers of Container Security.Миф третий: оркестрация превращает масштабирование в пустякВ реальности: хотя профессионалы обычно считают оркестраторы вроде Kubernetes совершенно необходимым инструментом для масштабирования контейнеров, будет заблуждением думать, что оркестрация сразу облегчит масштабирование в эксплуатационной среде. Объём данных там гораздо больше, и вашему мониторингу тоже потребуется масштабирование. С ростом объёмов всё меняется. Невозможно удостовериться в полноценной реализации интерфейсов всех компонентов K8s, пока не выкатишь их в прод. Не получится автоматически определять, что Kubernetes работает нормально, и что API-сервер и другие управляющие компоненты масштабировались в соответствии с вашими потребностями.Повторюсь, в средах разработки и тестирования всё может выглядеть несколько проще. И со временем придётся поработать над тем, чтобы удовлетворить потребности и поддерживать это состояние. В локальных средах легко пропустить какие-то основы, например, прописывание правильных ресурсов и ограничений на запросы. А если не сделать этого в проде, то однажды у вас может всё рухнуть.Масштабирование кластера в ту или другую сторону — основной пример, когда задача может выглядеть просто при локальных экспериментах, но явно усложняется в боевой среде. Продуктивные кластеры масштабировать сложнее, чем кластеры для разработки или наладки. Хотя в Kubernetes довольно просто масштабировать приложения горизонтально, но DevOps нужно помнить о некоторых нюансах, особенно когда речь идёт о поддержании работы сервисов при масштабировании инфраструктуры. Важно убедиться, что основные сервисы, а также системы оповещения об уязвимостях и нарушении безопасности, были распределены по узлам кластера и работали со stateful-томами, чтобы данные не терялись при масштабировании вниз.Как и в случае с другими задачами, всё дело в правильном планировании и ресурсах. Вам нужно понимать свои потребности в масштабировании, планировать, а главное — тестировать. Ваша продуктивная среда должна выдерживать гораздо более высокие нагрузки.Миф четвёртый: Kubernetes везде работает одинаковоВ реальности: различия в работе в разных средах могут быть подобно тому, как различается запуск Kubernetes на ноутбуке разработчика и на боевом сервере. Многие считают, что если K8s работает локально, то он будет работать и в любой эксплуатационной среде. Хотя он обеспечивает согласованные среды, однако в зависимости от вендора могут быть серьёзные отличия.Для ввода кластера в промышленную эксплуатацию нужны компоненты, которых в локальных средах обычно нет: мониторинг, журналирование, управление сертификатами и учётными данными. Вам нужно это учитывать, это одна из главных проблем, усиливающих разницу между боевыми средами и средами разработки и тестирования.Впрочем, всё сказанное относится не столько к Kubernetes, сколько к контейнерам и микросервисам в целом, особенно в гибридных облачных и многооблачных средах.Публично-приватные внедрения Kubernetes сложнее, чем кажется на бумаге, потому что многие необходимые сервисы являются проприетарными, например, балансировщики нагрузки и файрволы. Контейнер, который прекрасно работает в локальной среде, в облаке с другим набором инструментов может вообще не запуститься, или работать в незащищённом режиме. Поэтому технологии service mesh вроде Istio привлекают столько внимания. Они обеспечивают доступность сервисов приложений везде, где работает ваш контейнер, так что вам не нужно думать об инфраструктуре — а это главная фишка контейнеров. =========== Источник: habr.com =========== =========== Автор оригинала: Kevin Casey ===========Похожие новости:
Блог компании Инфосистемы Джет ), #_kubernetes, #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:26
Часовой пояс: UTC + 5