Cloud native: 4 тенденции Kubernetes
Давайте подробнее рассмотрим каждую из четырех cloud-native тенденций.
1. Kubernetes и GitOps
Контейнеры теперь используются в качестве стандартных единиц развертывания, и Kubernetes благодаря своей способности к высокому уровню абстрагирования инфраструктуры де-факто стал оркестровщиком контейнеров. Платформа также способствовала появлению GitOps, в котором команды разработчиков программного обеспечения управляют инфраструктурой так же, как кодом приложения.
GitOps — это:
модель эксплуатации для Kubernetes и cloud native, предоставляющая набор лучших практик для развертывания, управления и мониторинга собранных в контейнеры кластеров и приложений;
путь к созданию ориентированного на разработчиков окружения для управления приложениями.
GitOps предоставляет подход к управлению средой, который использует контроль версий для конфигураций инфраструктуры и управляет изменениями среды как новыми версиями.
Это идеально подходит для микросервисов и контейнеров, а также для любой сложной среды, охватывающей несколько ветвей разработки и версий ПО. Отказываясь от серверов и виртуальных машин как таковых, разработчики могут сосредоточиться на проблемах более высокого уровня, например, на добавлении функций и процессах доставки. Инфраструктура для таких тестовых и продуктивных сред может существовать в виде кода в хранилище приложения.
2. Репозитории и контроль версий
Контроль версий, движущая технология GitOps, позволяет разработчикам отслеживать все изменения, внесенные в код, в специальном хранилище, во избежание конфликтов внутри кода и быстрого откатывания на предыдущую версию, если что-то пойдет не так. GitHub — популярный пример платформы для управления версиями. Система контроля версий отслеживает, кто и когда вносил изменения, зачем это было сделано и что подверглось изменениям. Это позволяет без проблем откатиться к более ранним версиям и нивелирует сложности с устранением неполадок. Такой подход особенно полезен в распределенных проектах, где разные разработчики одновременно работают над своими собственными сервисами и функциями.
Использование контроля версий для управления файлами конфигурации Kubernetes основано на декларативном характере Kubernetes. В отличие от пошагового подхода для достижения определенной конфигурации Kubernetes заботится только о желаемом конечном состоянии кластера.
3. Service mash
Service mesh — явление, которое ещё не имеет устойчивого перевода на русский язык. Кто-то переводит этот термин как "сетка сервисов", другие — как "сервисное сито". Фактически, service mash — это множество userspace-прокси, расположенных «рядом» с сервисами, плюс набор управляющих процессов. Прокси в совокупности получили название data plane, а управляющие процессы именуются control plane.
В то время как Kubernetes управляет контейнерами, пользователь должен управлять связью между этими контейнерами. Архитектура корпоративного программного обеспечения может включать в себя сотни или тысячи контейнеров, которые по умолчанию настроены на связь друг с другом. Короткий срок службы контейнеров и их динамическая природа затрудняют поддержание однородности во время работы. Это проблема, которую и стремится решить технология service mash и решения на подобие Istio и Linkerd.
Сетки сервисов не зависят от инфраструктуры и позволяют пользователям отслеживать и контролировать трафик через набор сервисов и ресурсов. Большинство service mash решений, таких как Istio и Linkerd, построены на основе прокси-сервера sidecar, который работает вместе с контейнерами приложений, имитируя их поведение и облегчая процессы настройки и регистрации. В дополнение к возможностям управления трафиком, безопасностью и мониторингом service mash решения часто включают в себя встроенные функции для балансировки нагрузки.
4. Проблемы безопасности
Безопасность является главной задачей для бизнеса в облаке, особенно в связи с растущей сложностью облачных сред Kubernetes. Хотя Kubernetes доказал, что можно управлять распределенной средой с помощью декларативных политик, обеспечение безопасности — задача совсем другого уровня. Например, в 2019 году оркестратор подвергся уязвимости runC — CVE-2019-11247.
Команды Kubernetes должны понимать свою ответственность за безопасность при использовании облачных сервисов. Как правило, IaaS-провайдер берет на себя большую часть забот, но исключительно усилиями поставщика услуг ограничиваться нельзя. Это означает, что пользователи должны самостоятельно старательно следить за вопросами безопасности и находить возможные уязвимости.
Нужна виртуальная инфраструктура? Возьмите в аренду один или несколько виртуальных серверов требуемой конфигурации для реализации ваших ИТ- и бизнес-задач в облаке ИТ-ГРАД, оплачивайте фактическое потребление ресурсов или гарантированные мощности. Узнайте о реализованных проектах на нашем сайте.