Kubernetes для фронтенд-разработчиков

22.12.2022 1005
IBS Training Center Telegram
Подписывайтесь на наш канал в Telegram:
больше материалов экспертов, анонсы бесплатных вебинаров и задачки для IT-специалистов
Подписаться

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

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

Что такое Kubernetes?

Платформа Kubernetes (также известная как k8s) была разработана инженерами компании Google и появилась в середине 2014 года. В настоящее время она широко используется в экосистеме разработки программного обеспечения. Согласно определению в документации: Kubernetes — это платформа с открытым исходным кодом для управления контейнеризированными рабочими нагрузками и сервисами, поддерживающая возможности декларативной настройки и автоматизации. Она позволяет разработчикам создавать контейнеризированные приложения, которые могут реагировать на критические потребности в случае скачка трафика или сбоя в обслуживании.

11235261_10502.jpg

Dockers и контейнеры

Docker — самый популярный инструмент для реализации контейнерных технологий. Это эффективное средство создания, запуска и развертывания контейнеризированных приложений. Код приложения, библиотеки, инструменты, зависимости и другие файлы — все это содержится в образе Docker; при запуске пользователем образ превращается в контейнер. Созданный образ всегда будет запускать только один контейнер (образ может иметь несколько слоев, а затем использоваться для создания нескольких образов, но на основе образа всегда создается только один контейнер).

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

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

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

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

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


Почему фронтенд-разработчики используют Kubernetes?

Для улучшения цифрового взаимодействия микросервисы были успешно внедрены такими технологическими гигантами, как Netflix, Google, Amazon и другими лидерами отрасли; компании рассматривают эту архитектуру как экономически эффективное средство расширения своей операционной деятельности. С другой стороны, микросервисная архитектура приобрела популярность в последние годы благодаря своей эффективности в разработке, развертывании и масштабировании множества серверных частей приложений.

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

7732641_5268.jpg

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-адресе фронтенд-сервиса, мы можем достичь конечной точки.

7732609_5236.jpg

Заключение

Общее видение необходимости надежного программного обеспечения может быть обусловлено пониманием возможностей 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/



Расскажи друзьям:

Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!
Спасибо.
Вы подписаны на ежемесячный дайджест.
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.