Что такое Кубернетес? Руководство по контейнеризации и развертыванию

Некоторое время назад мы использовали монолитное веб-приложение: огромные кодовые базы, которые разрастались новыми функциями и функциями, пока не превратились в огромных, неповоротливых, трудноуправляемых гигантов. Сейчас все больше разработчиков, архитекторов и DevOps-экспертов приходят к мнению, что лучше использовать микросервисы, чем гигантский монолит. Обычно использование архитектуры на основе микросервисов означает разделение вашего монолита как минимум на два приложения: интерфейсное приложение и серверное приложение (API). После решения использовать микросервисы возникает вопрос: В какой среде лучше запускать микросервисы? Что мне следует выбрать, чтобы сделать мой сервис стабильным, а также простым в управлении и развертывании? Короткий ответ: используйте Docker!

В этой статье я познакомлю вас с контейнерами, объясню Kubernetes и научу вас, как контейнеризовать и развертывать приложение в кластере Kubernetes с помощью CircleCI.

Докер? Что такое Докер?

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

Используя контейнеры, разработчики могут легко (повторно) развернуть образ в любой ОС. Просто установите Docker, выполните команду, и ваше приложение заработает. Да, и не беспокойтесь о каких-либо несоответствиях с новой версией библиотек в хост-ОС. Кроме того, вы можете запускать больше контейнеров на одном хосте — это будет одно и то же приложение или другое? Это не имеет значения.

Похоже, Docker — отличный инструмент. Но как и где запускать контейнеры?

Существует множество вариантов того, как и где запускать контейнеры: AWS Elastic Container Service (AWS Fargate или зарезервированный экземпляр с горизонтальным и вертикальным автоматическим масштабированием); облачный экземпляр с предустановленным образом Docker в Azure или Google Cloud (с шаблонами, группами экземпляров и автомасштабированием); на собственном сервере с Docker; или, конечно же, Kubernetes! Kubernetes был создан специально для виртуализации и контейнеров инженерами Google в 2014 году.

Кубернетес? Что это такое?

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

Так почему я должен его использовать?

С Kubernetes вы можете максимально использовать вычислительные ресурсы. С Kubernetes вы будете капитаном своего корабля (инфраструктуры), а Kubernetes наполнит ваши паруса. С Kubernetes ваш сервис будет HA. И самое главное, с Kubernetes вы сэкономите много денег.

Выглядит многообещающе! Особенно, если это сэкономит деньги! Давайте поговорим об этом больше!

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

Под капотом: что такое Kubernetes?

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

Master Node — панель управления для всего кластера Kubernetes. Компоненты мастера могут быть запущены на любом узле кластера. Ключевые компоненты:

• Сервер API: точка входа для всех команд REST, единственный компонент главного узла, доступный пользователю.
• Хранилище данных. Надежное, согласованное и высокодоступное хранилище ключей и значений, используемое кластером Kubernetes.
• Планировщик: отслеживает вновь созданные модули и назначает их узлам. Развертывание модулей и сервисов на узлах происходит из-за планировщика.
• Диспетчер контроллеров: запускает все контроллеры, обрабатывающие рутинные задачи в кластере.
• Рабочие узлы: агент основного узла, также называемый узлами-миньонами. Здесь запускаются стручки. Рабочие узлы содержат все необходимые службы для управления сетью между контейнерами, связи с главным узлом и назначения ресурсов запланированным контейнерам.
• Docker: работает на каждом рабочем узле и загружает образы и стартовые контейнеры.
• Kubelet: отслеживает состояние модуля и гарантирует, что контейнеры запущены и работают. Он также взаимодействует с хранилищем данных, получая информацию о сервисах и записывая сведения о вновь созданных.
• Kube-proxy: сетевой прокси и балансировщик нагрузки для службы на одном рабочем узле. Он отвечает за маршрутизацию трафика.
• Kubectl: CLI-инструмент для взаимодействия пользователей с API-сервером Kubernetes.

Что такое модули и сервисы?

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

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

Простой пример развертывания

Я буду использовать простое приложение Ruby on Rails и GKE в качестве платформы для запуска Kubernetes. На самом деле вы можете использовать Kubernetes в AWS или Azure или даже создать кластер на собственном оборудовании или запускать Kubernetes локально с помощью minikube — все варианты, которые вы найдете на этой странице.

Исходные файлы для этого приложения можно найти в этом репозитории GitHub.

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

 rails new blog

Чтобы настроить соединение MySQL для производства в config/database.yml file :

 production: adapter: mysql2 encoding: utf8 pool: 5 port: 3306 database: <%= ENV['DATABASE_NAME'] %> host: 127.0.0.1 username: <%= ENV['DATABASE_USERNAME'] %> password: <%= ENV['DATABASE_PASSWORD'] %>

Чтобы создать модель статьи, контроллер, представления и миграцию, выполните:

 rails g scaffold Article title:string description:text

Чтобы добавить драгоценные камни в Gemfile:

 gem 'mysql2', '< 0.6.0', '>= 0.4.4' gem 'health_check'

Чтобы создать образ Docker, возьмите мой Dockerfile и выполните:

 docker build -t REPO_NAME/IMAGE_NAME:TAG . && docker push REPO_NAME/IMAGE_NAME:TAG

Пришло время создать кластер Kubernetes. Откройте страницу GKE и создайте кластер Kubernetes. Когда кластер будет создан, нажмите кнопку «Подключиться» и скопируйте команду — убедитесь, что у вас установлены и настроены инструмент gCloud CLI (как это сделать) и kubectl. Выполните скопированную команду на своем ПК и проверьте подключение к кластеру Kubernetes; выполнить kubectl cluster-info .

Приложение готово к развертыванию в кластере k8s. Давайте создадим базу данных MySQL. Откройте страницу SQL в консоли gCloud и создайте экземпляр базы данных MySQL для приложения. Когда экземпляр будет готов, создайте пользователя и БД и скопируйте имя подключения экземпляра .

Кроме того, нам нужно создать ключ сервисной учетной записи на странице API & Services для доступа к базе данных MySQL из контейнера sidecar. Вы можете найти больше информации об этом процессе здесь. Переименуйте загруженный файл в service-account.json . Мы вернемся позже к этому файлу.

Мы готовы развернуть наше приложение в Kubernetes, но сначала мы должны создать секреты для нашего приложения — секретный объект в Kubernetes, созданный для хранения конфиденциальных данных. Загрузите ранее загруженный файл service-account.json :

 kubectl create secret generic mysql-instance-credentials \ --from-file=credentials.json=service-account.json

Создайте секреты для приложения:

 kubectl create secret generic simple-app-secrets \ --from-literal=username=$MYSQL_PASSWORD \ --from-literal=password=$MYSQL_PASSWORD \ --from-literal=database-name=$MYSQL_DB_NAME \ --from-literal=secretkey=$SECRET_RAILS_KEY

Не забудьте заменить значения или установить переменные среды своими значениями.

Прежде чем создавать развертывание, давайте взглянем на файл развертывания. Я объединил три файла в один; первая часть — это служба, которая будет открывать порт 80 и перенаправлять все соединения, поступающие на порт 80, на порт 3000. У службы есть селектор, с помощью которого служба знает, на какие модули она должна пересылать соединения.

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

Последняя часть — автомасштабирование Horizontal Pod. HPA имеет довольно простую конфигурацию. Имейте в виду, что если вы не установите ресурсы для контейнера в разделе развертывания, HPA не будет работать.

Вы можете настроить вертикальное автомасштабирование для своего кластера Kubernetes на странице редактирования GKE. Он также имеет довольно простую конфигурацию.

Пришло время отправить его в кластер GKE! Прежде всего, мы должны запустить миграцию через job. Выполнять:

kubectl apply -f rake-tasks-job.yaml — это задание будет полезно для процесса CI/CD.

kubectl apply -f deployment.yaml — для создания службы, развертывания и HPA.

А затем проверьте свой pod, выполнив команду: kubectl get pods -w

 NAME READY STATUS RESTARTS AGE sample-799bf9fd9c-86cqf 2/2 Running 0 1m sample-799bf9fd9c-887vv 2/2 Running 0 1m sample-799bf9fd9c-pkscp 2/2 Running 0 1m

Теперь давайте создадим вход для приложения:

1. Создайте статический IP-адрес: gcloud compute addresses create sample-ip --global
2. Создайте вход (файл): kubectl apply -f ingress.yaml
3. Убедитесь, что вход создан, и получите IP-адрес: kubectl get ingress -w
4. Создайте домен/субдомен для вашего приложения.

CI/CD

Давайте создадим конвейер CI/CD с помощью CircleCI. На самом деле, с помощью CircleCI легко создать конвейер CI/CD, но имейте в виду, что быстрый и грязный полностью автоматизированный процесс развертывания без подобных тестов будет работать для небольших проектов, но, пожалуйста, не делайте этого для чего-то серьезного, потому что , если какой-либо новый код имеет проблемы в производстве, вы потеряете деньги. Вот почему вы должны подумать о разработке надежного процесса развертывания, запускать канареечные задачи до полного развертывания, проверять ошибки в логах после запуска канареечного и так далее.

В настоящее время у нас есть небольшой простой проект, поэтому давайте создадим полностью автоматизированный процесс развертывания CI/CD без тестирования. Во-первых, вы должны интегрировать CircleCI с вашим репозиторием — вы можете найти все инструкции здесь. Затем мы должны создать файл конфигурации с инструкциями для системы CircleCI. Конфиг выглядит довольно просто. Суть в том, что в репозитории GitHub есть две ветки: master и production .

1. Ветка master предназначена для разработки, для свежего кода. Когда кто-то отправляет новый код в основную ветку, CircleCI запускает рабочий процесс для основной ветки — сборка и тестирование кода.
2. Производственная ветвь предназначена для развертывания новой версии в производственной среде. Рабочий процесс для рабочей ветки выглядит следующим образом: отправьте новый код (или, что еще лучше, откройте PR из основной ветки в рабочую), чтобы запустить новый процесс сборки и развертывания; во время сборки CircleCI создает новые образы Docker, отправляет их в GCR и создает новый релиз для развертывания; если развертывание не удается, CircleCI запускает процесс отката.

Перед запуском любой сборки вы должны настроить проект в CircleCI. Создайте новую учетную запись службы в API и страницу Службы в GCloud с этими ролями: полный доступ к GCR и GKE, откройте загруженный файл JSON и скопируйте содержимое, затем создайте новую переменную среды в настройках проекта в CircleCI с именем GCLOUD_SERVICE_KEY и вставьте содержимое файла сервисной учетной записи в качестве значения. Кроме того, вам необходимо создать следующие переменные окружения: GOOGLE_PROJECT_ID (его можно найти на домашней странице консоли GCloud), GOOGLE_COMPUTE_ZONE (зона для вашего кластера GKE) и GOOGLE_CLUSTER_NAME (имя кластера GKE).

Последний шаг (деплой) в CircleCI будет выглядеть так:

 kubectl patch deployment sample -p '{"spec":{"template":{"spec":{"containers":[{"name":"sample","image":"gcr.io/test-d6bf8/simple:'"$CIRCLE_SHA1"'"}]}}}}' if ! kubectl rollout status deploy/sample; then echo "DEPLOY FAILED, ROLLING BACK TO PREVIOUS" kubectl rollout undo deploy/sample # Deploy failed -> notify slack else echo "Deploy succeeded, current version: ${CIRCLE_SHA1}" # Deploy succeeded -> notify slack fi deployment.extensions/sample patched Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 2 of 3 updated replicas are available... Waiting for deployment "sample" rollout to finish: 2 of 3 updated replicas are available... deployment "sample" successfully rolled out Deploy succeeded, current version: 512eabb11c463c5431a1af4ed0b9ebd23597edd9

Заключение

Похоже, процесс создания нового кластера Kubernetes не так уж и сложен! И процесс CI/CD действительно потрясающий!

Да! Кубернетес — это круто! С Kubernetes ваша система станет более стабильной, легко управляемой и сделает вас ее капитаном. Не говоря уже о том, что Kubernetes немного геймифицирует систему и дает +100 баллов за ваш маркетинг!

Теперь, когда у вас есть основы, вы можете пойти дальше и превратить это в более продвинутую конфигурацию. Я планирую рассказать больше в следующей статье, а пока вот вам задача: создайте надежный кластер Kubernetes для вашего приложения с БД с отслеживанием состояния, расположенной внутри кластера (включая sidecar Pod для создания резервных копий), установите Jenkins внутри тот же кластер Kubernetes для конвейера CI/CD, и пусть Jenkins использует модули в качестве подчиненных для сборок. Используйте certmanager для добавления/получения SSL-сертификата для вашего входа. Создайте систему мониторинга и оповещения для своего приложения с помощью Stackdriver.

Kubernetes хорош тем, что его легко масштабировать, нет привязки к поставщику, и, поскольку вы платите за инстансы, вы экономите деньги. Тем не менее, не все являются экспертами Kubernetes или имеют время для настройки нового кластера — с другой стороны, коллега по Toptaler Амин Шах Гилани приводит доводы в пользу использования Heroku, GitLab CI и большого количества средств автоматизации, которые он уже придумал. для написания большего количества кода и выполнения меньшего количества рабочих задач в How to Build an Effective Initial Deployment Pipeline .