Простое руководство по оркестровке контейнеров с помощью Kubernetes

Введение

Вы получите максимальную пользу от этого руководства, если вы хотите изучить оркестровку контейнеров с Kubernetes.

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

Объедините информацию, полученную из всех этих руководств и курсов, с некоторой практикой, и вы будете на пути к мастерству в оркестровке контейнеров.

Что вы узнаете

Это руководство посвящено промежуточной теме в системном администрировании Linux. Ожидается, что после прочтения вы поймете:

• Что такое оркестровка контейнеров
• Что такое Kubernetes и
• Оркестровка контейнеров с помощью Kubernetes с использованием AWS.

Основы оркестровки контейнеров

Оркестровка контейнеров является частью конвейера CI/CD в DevOps, она используется для автоматизации управления, развертывания, масштабирования и сетевого взаимодействия контейнеров.

В процессе CI/CD существует несколько платформ оркестровки контейнеров, две основные из них — Kubernetes и Docker swarm. Это руководство будет посвящено Kubernetes.

Если вы знакомы с CI/CD или DevOps, вы уже должны знать, что такое контейнеры, они представляют собой форму виртуальных машин, на которых размещается операционная система, их можно использовать для запуска небольших микросервисных приложений и даже больших приложений.

Зачем нужна оркестровка?
Оркестровка — это автоматизированное управление жизненным циклом нашего приложения.

• Оркестровка помогает нам автоматизировать процесс развертывания для непрерывного развертывания
• Оркестровка помогает нам справиться со сложными рабочими процессами при развертывании нашего приложения

Понимание того, как работают контейнеры

Контейнеры — это стандартизированная упаковка для микросервисных приложений со всем необходимым кодом приложения и зависимостями.

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

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

Проще говоря, используя виртуальные машины, я могу создать два разных приложения, которые требуют двух разных версий, скажем, node, т.е. node v17.2.0 и node v18.6.0. Если вы собираете эти два приложения на локальной машине, невозможно использовать две разные версии node одновременно.

Теперь самое интересное: хотя контейнеры похожи на VM, контейнеры гораздо круче. Контейнеризация позволяет развернуть несколько приложений, использующих одну и ту же операционную систему, на одной виртуальной машине или сервере.

Что такое Kubernetes?

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

Почитайте, что говорят о Kubernetes в документации

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

Kubernetes состоит из двух основных компонентов для процесса непрерывного развертывания, стручков и сервисов.

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

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

ПРИМЕЧАНИЕ:

• Балансировка нагрузки: обработка трафика путем распределения его по различным конечным точкам.
• Горизонтальное масштабирование: обработка возросшего трафика путем создания дополнительных реплик, чтобы трафик можно было распределить между ними.
• Реплика: избыточная копия ресурса, часто используемая для резервного копирования или балансировки нагрузки.

Практический обзор

Предварительные условия
Этот практический аспект предполагает, что у вас есть предыдущие знания по созданию образов и контейнеров с помощью docker и базовые знания по облачным вычислениям с AWS.

Что вам понадобится

• Интерфейс командной строки
• Учетная запись docker hub
• Образ и контейнер docker
• Учетная запись AWS

Пора пачкаться, надевайте перчатки, готовьте инструменты, давайте начнем.

Установка Kubernetes

Существует множество сервисов, которые можно использовать для установки Kubernetes, но в этом руководстве мы сосредоточимся на использовании AWS.

Почему именно AWS?
Настроить Kubernetes с нуля довольно сложно, но AWS делает это проще. В этом руководстве вы узнаете, как создать кластер Kubernetes с помощью AWS и как создать узел на AWS.

Примечание:

• Кластер Kubernetes состоит из набора узлов, на которых запускаются контейнерные приложения. При развертывании Kubernetes вы получаете кластер, и каждый кластер имеет как минимум один рабочий узел.
• Nodes — это абстракция стручков, управляемых плоскостью управления, плоскость управления управляет планированием стручков на всех узлах кластера.

Подготовка нашего контейнера

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

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

Первая конфигурация — это файл «deployment.yaml».

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: simple-node
        image: YOUR_DOCKER_HUB/simple-node
        ports:
        - containerPort: 80

Затем второй файл «service.yaml»;

apiVersion: v1
kind: Service
metadata:
  name: my-app
  labels:
    run: my-app
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: my-app

Как только этот файл будет доступен, следующее, что нужно сделать, это создать кластер Kubernetes с помощью Elastic Kubernetes Service на AWS. Войдя в консоль AWS, вы можете легко найти его, набрав в строке поиска eks, а затем щелкнув по нему.

Следующим шагом будет создание кластера EKS, перейдите в раздел кластеров на левой панели, нажмите на кнопку создать кластер,

Но перед этим откройте новую вкладку, найдите IAM, теперь…

Шаг 1: Создайте IAM-роль кластера EKS:

Перейдите на вкладку Роли в панели управления идентификацией и доступом (IAM) в AWS Console.

1. Нажмите Создать роль
2. Выберите тип доверенной сущности:
3. Выберите EKS в качестве сценария использования
4. Выберите EKS-кластер
5. Нажмите Далее: Разрешения
6. Нажмите Далее: Теги
7. Нажмите Далее: Обзор
8. Дайте роли имя, например, EKSClusterRole
9. Нажмите Создать роль

Шаг 2: Создание пары SSH

1. Перейдите на вкладку Ключевые пары в панели инструментов EC2 Dashboard
2. Нажмите кнопку Создать пару ключей
3. Дайте паре ключей имя, например mykeypair.
4. Выберите RSA и .pem
5. Нажмите кнопку Создать пару ключей

Шаг 3: Создайте кластер EKS

1. Перейдите на вкладку Кластеры на панели Amazon EKS в консоли AWS Console.
2. Нажмите Создать кластер
3. Укажите: уникальное имя (например, MyEKSCluster), версию Kubernetes (например, 1.21), роль службы кластера (выберите роль, которую вы создали выше, например, EKSClusterRole).
4. Нажмите Далее
5. В поле Specify networking look for Cluster endpoint access выберите радиокнопку Public.
6. Нажмите Далее и Далее
7. В разделе Обзор и создание нажмите Создать

Создание кластера EKS может занять 5-15 минут.

Устранение неполадок: Если вы получите сообщение следующего вида:

Cannot create cluster the targeted availability zone does not currently have sufficient capacity to support the cluster

выберите другую зону доступности и повторите попытку. Вы можете установить зону доступности в правом верхнем углу консоли AWS.

Шаг 4: Создайте группу узлов
Теперь вернитесь на открытую вкладку IAM,

— Создайте IAM-роль узла кластера EKS.

1. На вкладке Роли IAM нажмите Создать роль
2. Выберите тип доверенной сущности:
3. Выберите EC2 в качестве сценария использования
4. Выберите EC2
5. Нажмите Далее: Разрешения
6. В разделе Прикрепить политики разрешений найдите каждую из следующих и установите флажок слева от политики, чтобы прикрепить ее к роли: «AWSAmazonEC2ContainerRegistryReadOnly, AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy».
7. Нажмите Далее: Теги
8. Нажмите Далее: Обзор
9. Дайте роли имя, например, NodeRole
10. Нажмите Создать роль

Теперь вернитесь на вкладку Кластер…

Создание узла

1. Перейдите на вкладку Compute во вновь созданном кластере.
2. Нажмите Добавить группу узлов
3. Укажите: уникальное имя (например, MyNodeGroup)
4. Роль службы кластера (выберите роль, которую вы создали выше, например, NodeRole).
5. Создайте и укажите SSH-ключ для группы узлов
6. В конфигурации вычислений группы узлов установите тип экземпляра t3.micro и размер диска 4*, чтобы минимизировать затраты.
7. В конфигурации масштабирования группы узлов установите количество узлов равным 2.
8. Нажмите кнопку Далее
9. В конфигурации сети группы узлов установите флажок Настроить SSH доступ к узлам.
10. Выберите созданную выше пару EC2 (например, mykeypair).
11. Выберите Все
12. Нажмите Далее
13. Просмотрите конфигурацию и нажмите «Создать».

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

В дальнейшем для взаимодействия с нашим кластером будет использоваться инструмент командной строки Kubernetes (kubectl). Созданные нами YAML-файлы будут загружаться с помощью этого инструмента.

Взаимодействие с кластером

• Установите kubectl
• Настройте aws-iam-authenticator
• Установите kubeconfig

Следующим шагом будет загрузка конфигураций Infrastructure as Code(IaC).

Загрузите файлы YAML, это файлы deployment.yaml и service.yaml. Загрузите их в ресурс Amazon EKS с помощью следующих команд:

kubectl apply -f deployment.yaml

Шаг 1: Развертывание ресурсов

Отправьте файлы YAML в Kubernetes для создания ресурсов. Это создаст определенное количество копий указанного образа:

kubectl apply -f deployment.yaml

и создаст службу:

kubectl apply -f service.yaml

Шаг 2: Подтвердите развертывание

Убедитесь, что ресурсы были созданы:

kubectl get pods

и проверьте, что они были созданы правильно:

kubectl describe services

Чтобы получить дополнительные метаданные о кластере, выполните команду :

kubectl cluster info dump

Загрузив эти конфигурационные файлы в кластер Kubernetes, вы настроили Kubernetes на получение созданного вами образа Docker из учетной записи DockerHub.

Устранение неполадок

Если вы столкнулись с некоторыми проблемами:

• Проверьте, были ли успешно созданы группы узлов в вашем кластере EKS. Если нет, Kubernetes не имеет достаточного количества настроенных стручков.
• Если вы получили сообщение об ошибке, касающееся невозможности извлечь ваши образы Docker, убедитесь, что ваш репозиторий DockerHub установлен на public.

Что дальше?

Следующим шагом будет обеспечение безопасности и настройка служб Kubernetes для работы на производстве.

Управление стоимостью

Мы можем начать с настройки кластеров для значительного снижения затрат (т.е. указать количество создаваемых реплик, а также минимизировать используемые ресурсы, такие как CPU).

Сознание безопасности
Убедитесь, что ваш кластер Kubernetes защищен от злоумышленников, это можно сделать, настроив, кто имеет доступ к подсистемам и сервисам Kubernetes.

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

Подготовка к масштабированию и доступности

Убедитесь, что служба Kubernetes способна обрабатывать количество/размер пользовательских запросов, а приложение быстро реагирует, т.е. может быть использовано, когда это необходимо.

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

Обработка обратных запросов с помощью обратного прокси-сервера

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

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

Nginx — это веб-сервер, который может быть использован в качестве обратного прокси, конфигурация может быть задана с помощью файла nginx.conf.

Доступ к кластеру Kubernetes с помощью обратного прокси-сервера

Сначала проверьте pods, чтобы увидеть, что запущено, что используется:

Затем проверьте сервисы, чтобы найти точку входа для доступа к стручку:

kubectl describe services

В результатах вы найдете имя службы (например, alamz-app-svc) и тип (ClusterIP), что означает, что служба доступна только внутри кластера.

Теперь создайте файл nginx.conf. Пример файла nginx.conf выглядит следующим образом:

events {
}
http {
    server {
        listen 8080;
        location /api/ {
            proxy_pass http://alamz-app-svc:8080/;
        }
    }
}

Служба Nginx принимает запросы на порту 8080. Любые запросы с конечными точками с префиксом /api/ будут перенаправлены на службу Kubernetes alamz-app-svc. alamz-app-svc — это имя, которое наш кластер Kubernetes распознает внутри.

Поместите его в свой Dockerfile:

FROM nginx:alpine

COPY nginx.conf /etc/nginx/nginx.conf

nginx.conf настраивает сервис на прослушивание запросов, поступающих на порт 8080, и перенаправляет любые запросы к конечной точке API на конечную точку http://my-app-svc в приложении.

Настройка YAML-файлов для обратного прокси-сервера

Настройка аналогична предыдущему yaml-файлу, созданному в этом руководстве. Основная функциональность заключается в следующем: Создайте один модуль с именем reverseproxy и настройте его на ограничение ресурсов.

Ваш файл «deployment.yaml» должен выглядеть следующим образом:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    service: reverseproxy
  name: reverseproxy
spec:
  replicas: 1
  template:
    metadata:
      labels:
        service: reverseproxy
    spec:
      containers:
      - image: YOUR_DOCKER_HUB/simple-reverse-proxy
        name: reverseproxy
        imagePullPolicy: Always          
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "1024Mi"
            cpu: "500m"       
        ports:
        - containerPort: 8080
      restartPolicy: Always

Ваш файл «service.yaml» должен выглядеть следующим образом:

apiVersion: v1
kind: Service
metadata:
  labels:
    service: reverseproxy
  name: reverseproxy-svc
spec:
  ports:
  - name: "8080"
    port: 8080
    targetPort: 8080
  selector:
    service: reverseproxy

Развертывание обратного прокси

Наконец, мы готовы развернуть наш обратный прокси. Разверните обратный прокси с помощью:

kubectl apply -f reverseproxy_deployment.yaml
kubectl apply -f reverseproxy_service.yaml

kubectl — это инструмент командной строки, используемый для взаимодействия с нашим кластером kubernetes, а файл YAML — это инфраструктура как код (IaC), определяющая конфигурацию нашего обратного прокси.

Спасибо, друзья

Поздравляю, если вы внимательно следовали до этого момента, спасибо, амигос! Хотя я прекрасно понимаю, что это руководство не является всеобъемлющим, я обязательно укажу вам правильное направление, где вы можете получить информацию, которая не была включена.

Между тем, я размещаю это руководство здесь, чтобы служить в качестве MVP (минимального жизнеспособного продукта)… что? Это теперь класс по управлению продуктом? Ну… Нет. Я просто облачный DevOps-инженер с опытом проектирования продуктов, который каким-то образом влюбился в писательство. Ладно, хватит обо мне.

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

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