Разработчики переходят от локальных технологий к использованию преимуществ облачной инфраструктуры. Вместе с этим, монолитную архитектуру вытесняет микросервисный подход, благодаря которому приложения становятся доступнее, их проще устанавливать и обновлять.
В этой статье мы расскажем о платформе Kubernetes для фронтенд-программистов и объясним, почему Kubernetes является неотъемлемой частью готовой к производству микросервисной архитектуры. Мы обсудим некоторые ключевые термины, которые важно понимать для успешной совместной работы в команде, и в заключение дадим краткое описание процесса развертывания Kubernetes, чтобы новички могли начать работать с этой системой.
Что такое Kubernetes?
Платформа Kubernetes (также известная как k8s) была разработана инженерами компании Google и появилась в середине 2014 года. В настоящее время она широко используется в экосистеме разработки программного обеспечения. Согласно определению в документации: Kubernetes — это платформа с открытым исходным кодом для управления контейнеризированными рабочими нагрузками и сервисами, поддерживающая возможности декларативной настройки и автоматизации. Она позволяет разработчикам создавать контейнеризированные приложения, которые могут реагировать на критические потребности в случае скачка трафика или сбоя в обслуживании.
Dockers и контейнеры
Docker — самый популярный инструмент для реализации контейнерных технологий. Это эффективное средство создания, запуска и развертывания контейнеризированных приложений. Код приложения, библиотеки, инструменты, зависимости и другие файлы — все это содержится в образе Docker; при запуске пользователем образ превращается в контейнер. Созданный образ всегда будет запускать только один контейнер (образ может иметь несколько слоев, а затем использоваться для создания нескольких образов, но на основе образа всегда создается только один контейнер).
Образы Docker можно сравнить с шаблоном инструкций по сборке контейнера. Он помогает абстрагировать код приложения от базовой инфраструктуры, тем самым упрощая управление версиями и обеспечивая переносимость в различные среды развертывания.
Как правило, контейнеризированное приложение — это приложение без сохранения состояния (stateless), т.е. оно не сохраняет информацию о сеансе. И поскольку несколько экземпляров образа контейнера могут выполняться одновременно, разработчики используют контейнеры в качестве экземпляров, которые можно инициировать для замены вышедших из строя, не прерывая работу приложения.
С точки зрения управления ресурсами, важно знать, что использование ресурсов сильно ограничено, в отличие от виртуальных машин, поскольку их доступ к физическим ресурсам (памяти, хранилищу и процессору) ограничивается операционной системой хоста. В результате контейнеры легче и лучше масштабируются, чем виртуальные машины.
Для развертывания контейнера используется сервер, на котором размещаются контейнеры с поддержкой ОС вместе с инструментом управления контейнерами, таким как Docker или ContainerD. Когда возникает потребность в возможностях приложения, таких как масштабирование под нагрузкой и восстановление после аппаратных сбоев без прерывания работы или без вмешательства человека, тогда необходим инструмент оркестровки.
Kubernetes(K8s) — это инструмент оркестровки контейнеров, выполняющий задачи, которые в противном случае потребовали бы вмешательства человека. С его помощью можно исключить трудоемкие рутинные проверки, изменения в конфигурации, обновления и другие работы по обслуживанию ПО. Kubernetes помогает автоматизировать такие повторяющиеся процессы и упрощает выполнение вручную множества задач при работе над готовым к производству приложением.Почему фронтенд-разработчики используют Kubernetes?
Для улучшения цифрового взаимодействия микросервисы были успешно внедрены такими технологическими гигантами, как Netflix, Google, Amazon и другими лидерами отрасли; компании рассматривают эту архитектуру как экономически эффективное средство расширения своей операционной деятельности. С другой стороны, микросервисная архитектура приобрела популярность в последние годы благодаря своей эффективности в разработке, развертывании и масштабировании множества серверных частей приложений.
Внедрение микросервисной архитектуры в производство считается хорошей практикой, когда приложение становится слишком большим для полноценной поддержки одним разработчиком, или если после каждого релиза происходит повышение уровня оркестровки и взаимодействия между сервисами. Важно понимать, что для получения выгоды от использования Kubernetes необязательно использовать микросервисы на всех уровнях бизнес-организации.
K8s или Docker Compose: что лучше использовать?
Docker Compose — это инструмент, который принимает файл YAML, определяющий кросс-контейнерное приложение, и автоматизирует создание и удаление всех этих контейнеров без необходимости написания нескольких команд docker для каждого из них. Его целесообразно использовать для тестирования и разработки.
С другой стороны, Kubernetes — это платформа для управления готовыми к производству контейнеризированными рабочими нагрузками и сервисами, которая допускает декларативную настройку и автоматизацию.
Знакомство с терминологией
Чтобы эффективно использовать Kubernetes, необходимо иметь представление об используемой терминологии. Вот ключевые термины, которые помогут вам начать работу с Kubernetes:
-
Docker — контейнерный ресурс, ссылающийся на образ Docker и предоставляющий все конфигурации, необходимые Kubernetes (развертывание, выполнение, предоставление доступа, мониторинг и защита контейнера Docker);
-
Контейнер — это стандартная единица программного обеспечения, которая упаковывает код и все компоненты, от которых зависит надежная работа приложения.
-
Под — это объединение из одного или нескольких контейнеров с общим хранилищем и сетевыми ресурсами, а также набором правил, определяющих, как должны выполняться контейнеры. Это минимальная развертываемая единица, создаваемая и управляемая в Kubernetes.
-
Узлы — компоненты (физические компьютеры или виртуальные машины), на которых выполняются эти приложения, называются рабочими узлами. Рабочие узлы выполняют задачи, которые им назначил главный узел.
-
Кластер — это объединение узлов, которые используются для запуска контейнеризированных приложений. Кластер Kubernetes состоит из набора главных узлов и нескольких рабочих узлов. Новым пользователям, которые хотят научиться создавать кластеры Kubernetes, настоятельно рекомендуется использовать minikube.
-
Объекты — это сущности постоянного хранения в системе Kubernetes. Kubernetes использует объекты для представления состояния кластера. Они описывают желаемое состояние для выполняемых приложений, доступные ресурсы для приложений и политики, действующие в отношении этих приложений. Объект содержит информацию о рабочей нагрузке кластера.
-
Пространства имен — это способ распределения ресурсов кластера, необходимых для использования в ситуациях с различными командами или проектами с большим числом пользователей.
Контроллер входа — это объект API, который управляет доступом внешних пользователей к сервисам в кластере Kubernetes, предоставляя правила маршрутизации. Этот внешний запрос обычно делается с использованием протокола HTTPS/HTTP. Можно легко настроить правила маршрутизации трафика с помощью контроллера входа без создания множества балансировщиков нагрузки или предоставлять доступ к каждому сервису на узле.
Монолитная и микросервисная архитектура
Монолитная архитектура — это распространенный способ построения инфраструктуры как единого целого, включая пользовательский интерфейс, серверный каркас и реляционную базу данных. Поскольку все слои и компоненты приложения взаимосвязаны, изменение одного компонента требует обновления всего приложения.
Другой подход — микросервисная архитектура. При использовании микросервисного подхода сложная программа разбивается на слабо связанные части. Слабая связанность создает систему, в которой каждый сервиса или компонент имеет свой собственный логически отличный жизненный цикл, протоколы и базу данных. Такой автономный компонент можно проектировать, внедрять, масштабировать и управлять им отдельно от остальной части приложения, которое будет продолжать нормально функционировать.
Когда мы рассматриваем эти два метода, встает вопрос о том, как все это может взаимодействовать. Именно здесь возникает контейнеризация: каждый автономный блок упаковывается в контейнер, который затем помещается в под (включающий в себя несколько контейнеров, совместно используемых в кластере узлов). Под содержит несколько контейнеров, и они обрабатываются как единое целое, и все контейнеры в поде одновременно используют ресурсы пода, включая пространство имен, IP-адрес и сетевые порты.
(K8s) — менеджер инфраструктуры, ориентированной на контейнеры. Он управляет жизненными циклами контейнеров, то есть оптимизирует развертывание оркестровки контейнеров путем предоставления подов (их создания и уничтожения) на основе требований приложения. Kubernetes предоставляет поды для запросов, используя объект Service, который сопоставляет IP-адреса с набором подов. Этот сервис обеспечивает маршруты к подам из любого авторизованного источника (внутри или за пределами кластера) через назначенный порт.
Что касается фронтенд-разработчиков, то им нужно обладать базовыми знаниями о настройке взаимодействия между этой инфраструктурой и сервисами. Очень важно иметь четкое понимание того, как все функционирует. Часто говорят, что это проблема оперативного управления (Ops), и, игнорируя ее, мы упускаем шанс понять возможности того, что мы создаем, и как мы можем улучшить доступность приложения в производстве.
Специалисты Ops должны отвечать за настройку, конфигурирование кластера и управление им, разработчик должен понимать и нести ответственность за обеспечение минимального уровня, необходимого для запуска своего приложения.
В результате понимание основ Kubernetes позволит вам оптимизировать конфигурацию вашего приложения, сделать его более масштабируемым и таким образом участвовать в процессе его выпуска.
Командам полезно иметь общее представление о Kubernetes для всего программного стека и возможность использования общей терминологии при работе над своими проектами. Это позволит полностью контролировать весь жизненный цикл проекта — от написания кода до реализации, — тестировать развертывание приложения, понять, как должен быть развернут проект, обеспечить поддержку соответствующего слоя и указать среду.
Хорошим примером может служить ситуация, которую несколько лет назад описала моя подруга Кари (инженер-программист), рассказав о своем опыте работы с командой, в которой бэкенд-программисты были заинтересованы в разработке внешнего интерфейса и использовании Kubernetes. Они охотно выбрали изучение Kubernetes и не хотели бы напрямую работать с бэкенд-слоями, а только использовать его. Команде нравилось иметь возможность определять, как будет происходить развертывание их приложения в Kubernetes.
Наличие такого контроля над проектом помогает участвовать в процессе релиза проектов и, что еще более важно, позволяет оптимизировать конфигурацию приложения и улучшить его масштабируемость. Кроме того, понимание конфигурации производственного развертывания помогает разработчикам выявлять и устранять важные проблемы с производительностью такие как кэширование, количество запросов и время до первого байта, а также определить, чем подготовка/тестирование отличается от производства, прежде чем выпускать приложение.Существуют сценарии, при которых используемая фронтенд- и бэкенд-командами терминология часто совпадает, например:
-
Порт и сервисы — при указании версии развернутого приложения, а затем открытых портов, например, «мы можем взаимодействовать с приложением, используя имя сервиса и порт xx: xx»;
-
Пространства имен — когда мы знаем, что наш проект находится в пространстве имен Kubernetes. Пространства имен обеспечивают возможность для совместного использования ресурсов кластера несколькими пользователями.
-
RBAC (Role-Based Access and Control — управление доступом на основе ролей)
-
Когда мы знаем, как управление правами доступа в Kubernetes влияет на наши проекты.
Понимание того, как создаются и запускаются образы Docker, позволит командам четко формулировать требования для каждого приложения в кластере.
Развертывание и сервис
Указанные в конфигурации ресурсы создаются в процессе развертывания. Все ресурсы, которые должны быть в развертывании, указаны в файле конфигурации.
Чтобы выполнить развертывание, нам понадобится файл конфигурации. Для файла конфигурации необходим синтаксис YAML. Он содержит поля версии, имени, вида, поле реплик (желаемое количество ресурсов подов), селектора, поле метки и т.д., как показано ниже:
....
name:
spec:
selector:
matchLabels:
app:
tier:
replicas:
metadata:
labels:
app:
tier:
spec:
containers:
- name:
image:
...
Сервис Kubernetes — это уровень абстракции, который описывает логическую группу подов и позволяет использовать внешний трафик, балансировку нагрузки и обнаружение сервисов для этих подов.
Обновление развертывания
Развертывание может быть обновлено до желаемого состояния объекта из текущего состояния. Это обычно делается декларативно путем обновления соответствующих объектов в файле конфигурации, а затем их развертывания в качестве обновления. При внедрении стратегии непрерывного обновления старые ресурсы подов будут постепенно заменяться новыми. Это означает, что две версии ресурсов подов могут быть развернуты и доступны одновременно, что обеспечивает отсутствие простоев.
Объект бэкенд-сервиса
В этой статье поды в фроненд-развертывании будут запускать образ Nginx, который настроен для прокси-запросов к сервису с помощью ключа app: backend. Предположим, что бэкенд-команда уже запустила поды в кластере, и что мы хотим только создать и подключить наше приложение через развертывание к серверной части.
Чтобы разрешить доступ к серверному приложению, нам нужно создать для него сервис. Сервис создает постоянный IP-адрес и запись DNS-имени для данного приложения, что делает его доступным для других подов. Он также использует селекторы для поиска модулей, к которым он направляет трафик.
Вот пример файла конфигурации backend-service.yaml, который предоставляет доступ к бэкенд-приложению другим подам в кластере. Ниже приведен пример файла конфигурации сервиса для бэкенда:
---
apiVersion: v1
kind: Service
metadata:
name: backend-serv
spec:
selector:
app: hello
tier: backend
ports:
- protocol: TCP
port: 80
...
Приведенный выше файл YAML показывает, что сервис настроен на маршрутизацию трафика на поды, имеющие метку app: hello и tier: backend для подключения кластера только через порт 80.Создание клиентской части
Обычно мы создаем контейнерный образ нашего приложения и помещаем его в реестр (например, реестр docker), прежде чем ссылаться на него в поде. Поскольку это вводная статья, мы будем использовать пример фронтенд-образа из репозитория контейнеров Google. Фронтенд отправляет запросы на рабочие поды бэкенда, используя DNS-имя, данное бэкенд-сервису, которое является значением поля name в файле конфигурации backend-service.yaml.
Поды в фронтенд-развертывании запускают образ Nginx, настроенный для прокси-запросов к бэкенд-сервису. В файле конфигурации указываются сервер и порт прослушивания. Когда в Kubernetes создается вход, восходящие потоки nginx указывают на сервисы, соответствующие указанным селекторам.
nginx.conf configuration file
upstream Backend {
server backend-serv;
}
server {
listen 80;
location / {
proxy_pass http://Backend;
}
}
Обратите внимание, что для указания используется внутреннее DNS-имя, используемое бэкенд-сервисом внутри Kubernetes. Фронтенд, как и бэкенд, имеет развертывание и сервис. Настройка для фронтенд-сервиса имеет параметр type: LoadBalancer; это означает, что сервис будет использовать балансировщик нагрузки, предоставленный поставщиком облачных услуг, и будет доступен извне кластера.
---
apiVersion: v1
kind: Service
metadata:
name: frontend-serv
spec:
selector:
app: hello
tier: frontend
ports:
- protocol: "TCP"
port: 80
targetPort: 80
type: LoadBalancer
...
---
apiVersion: apps/v1
kind: Развертывание
metadata:
name: frontend-depl
spec:
selector:
matchLabels:
app: hello
tier: frontend
track: stable
replicas: 1
template:
metadata:
labels:
app: hello
tier: frontend
track: stable
spec:
containers:
- name: nginx
image: "gcr.io/google-samples/hello-frontend:1.0"
...
Создание развертывания и сервиса для фронтенда
Теперь, когда файлы конфигурации готовы, мы можем выполнить команду kubectl apply, чтобы создать указанные ресурсы:
kubectl apply -f [insert URL to saved frontend-deployment YAML file]
kubectl apply -f [insert URL to saved frontend-service YAML file]
Выходные данные подтверждают, что были созданы оба ресурса:
deployment.apps/frontend-depl created
service/frontend-serv createdВзаимодействие с развертывание и сервисом для фронтенда
Мы можем использовать эту команду для получения внешнего IP-адреса после создания сервиса LoadBalancer:
kubectl get service frontend-serv –watch
Она показывает конфигурации фронтенд-сервиса и отслеживает изменения. Внутренний IP-адрес кластера предоставляется сразу, а внешний IP-адрес изначально помечен как ожидающий:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend-serv LoadBalancer 10.xx.xxx.xxx <pending> 80/TCP 10s
Однако, когда предоставлен внешний IP-адрес, конфигурация обновляется и уже включает новый IP-адрес в заголовок: EXTERNAL-IP:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend-serv LoadBalancer 10.xx.xxx.xx XXX.XXX.XXX.XXX 80/TCP 1m
Выделенный IP-адрес может использоваться для связи с фронтенд-сервисом извне кластера. Теперь мы можем отправлять трафик через фронтенд, так как фронтенд и бэкенд теперь связаны между собой. Используя команду curl на внешнем IP-адресе фронтенд-сервиса, мы можем достичь конечной точки.
Заключение
Общее видение необходимости надежного программного обеспечения может быть обусловлено пониманием возможностей Kubernetes (ссылка на куср) и того, как ваше приложение работает в Kubernetes. Микросервисная архитектура лучше подходит для сложных и развивающихся приложений. Она обеспечивает эффективные решения для управления сложной системой различных функций и сервисов в рамках одного приложения.
«Микросервисы идеальны, когда речь идет о платформах, охватывающих множество пользовательских сценариев и рабочих процессов. Но без хороших знаний микросервисов применение этой модели невозможно».
Однако важно понимать, что микросервисный дизайн подходит не для всех уровней бизнес-организации. Вероятно, следует начать с монолита, если ваша бизнес-идея новая и вы хотите ее проверить. Для небольшой технической команды, пытающейся разработать базовое и легковесное приложение, микросервисы могут оказаться излишними, поскольку монолитную архитектуру можно без проблем развернуть через Kube, и в этом случае все равно можно пользоваться опциями репликации и другими функциями.
Присоединяйтесь к нашему курсу и станьте гуру Kubernetes: https://ibs-training.ru/kurs/praktika_raboty_s_kubernetes_bazovye_temy.html
Источник: https://www.smashingmagazine.com/2022/05/kubernetes-front-end-developers/