Архитектурные приложения для Kubernetes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя конфигурация приложенияcanдолжна быть встроена в образы контейнеров, лучше всего сделать ваши компоненты настраиваемыми во время выполнения для поддержки развертывания в нескольких контекстах и ​​обеспечения более гибкого администрирования. Для управления параметрами конфигурации среды выполнения Kubernetes предлагает два объекта с именамиConfigMaps иSecrets.

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

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

ConfigMaps и Secrets помогают избежать размещения конфигурации непосредственно в определениях объектов Kubernetes. Вы можете сопоставить ключ конфигурации вместо значения, что позволит вам обновить конфигурацию на лету, изменив ConfigMap или Secret. Это дает вам возможность изменять активное поведение во время выполнения модулей и других объектов Kubernetes без изменения определений ресурсов Kubernetes.

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

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

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

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

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

Развертывания - это составные объекты, основанные на других приматах Kubernetes для добавления дополнительных возможностей. Они добавляют возможности управления жизненным циклом к ​​промежуточным объектам, называемымreplicasets, например, возможность выполнять скользящие обновления, откат к более ранним версиям и переход между состояниями. Эти репликационные наборы позволяют задавать шаблоны модулей для ускорения и управлять несколькими копиями одного проекта модуля. Это поможет вам легко масштабировать инфраструктуру, управлять требованиями к доступности и автоматически перезагружать модули в случае сбоя.

Эти дополнительные функции обеспечивают административную структуру и возможности самовосстановления для относительно простой абстракции модуля. Хотя модули - это модули, которые в конечном итоге выполняют заданные вами рабочие нагрузки, они не являются единицами, которые вы обычно должны предоставлять и управлять ими. Вместо этого думайте о модулях как о строительном блоке, который может надежно запускать приложения, когда они предоставляются через объекты более высокого уровня, такие как развертывания.

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

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

Kubernetes предлагает довольно большую гибкость в определении и управлении ресурсами, развернутыми в вашем кластере. Используя такие инструменты, какkubectl, вы можете в обязательном порядке определять специальные объекты для немедленного развертывания в вашем кластере. Хотя это может быть полезно для быстрого развертывания ресурсов при изучении Kubernetes, у этого подхода есть недостатки, которые делают его нежелательным для долгосрочного управления производством.

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

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

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