Kubernetes для начинающих

Давно хотел написать эту публикацию, собрать свой опыт в удобном для прочтения виде, а речь, как не сложно догадаться, пойдёт про одну из самых замечательных систем оркестрации контейнеров Kubernetes, пристегните ремни, мы начинаем :)

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

Великий и ужасный

Кстати, у меня есть канал в Telegram, где я рассказываю про разные ИТ штуки типа нейросетей, Docker, ARM вообще и RaspberryPi в частности.

Введение

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

Теперь немного истории (информация взята из английской Википедии и с сайта RosinStack), Kubernetes был анонсирован компанией Google в середине 2014 года. Проект был создан коллективом из Joe Beda, Brendan Burns и Craig McLuckie, которые вскоре объединились с другими инженерами Google, включая Brian Grant и Tim Hockin.

Kubernetes (κυβερνήτης, kubernḗtēs) происходит от греческого слова, означающего "кормчий" или "проводник" и является этимологическим корнем кибернетики.

Дизайн и разработка Kubernetes были вдохновлены системой управления кластерами Google Borg. Большинство ключевых разработчиков Kubernetes ранее работали над Borg. Они назвали свой проект "Project 7" в честь персонажа "Семь из девяти" из телесериала "Star Trek", который является бывшим боргом, и разработали логотип с семью лучами (который к слову не гуглится никак). В отличие от Borg, написанного на C++, исходный код Kubernetes написан на языке программирования Go.

Kubernetes 1.0 был выпущен 21 июля 2015 года. Google сотрудничал с Linux Foundation для создания Cloud Native Computing Foundation (CNCF) и предложил Kubernetes в качестве технологии-основы. В феврале 2016 года был выпущен менеджер пакетов Helm для Kubernetes.

Изначально Kubernetes взаимодействовал исключительно с Docker через "Dockershim". Однако с ноября 2020 года по апрель 2022 года Kubernetes отказался от Dockershim в пользу прямого взаимодействия с контейнером через Containerd или замены Docker на совместимую с Container Runtime Interface (CRI) среду выполнения. С выпуском v1.24 в мае 2022 года "Dockershim" был полностью удален.

Терминология и понятия

Для начала быстренько пробежимся по базовым терминам и понятиям, с которыми вам придется столкнуться при работе с Kubernetes:

• Узел (Node) — это работающая машина (физическая или виртуальная) в кластере Kubernetes, на которой запускаются контейнеры. Узлы могут быть сгруппированы по меткам (labels), что позволяет создавать логические группы узлов для развертывания приложений.
• Кластер (Cluster) — это группа узлов, объединенных для работы вместе. Кластер обеспечивает автоматическое масштабирование, высокую доступность и эффективное использование ресурсов узлов.
• Pod — это минимальная единица работы в Kubernetes, состоящая из одного или нескольких контейнеров, которые размещены вместе на одном узле. Контейнеры внутри Pod разделяют те же сетевые ресурсы (IP-адрес и порты) и могут взаимодействовать друг с другом через локальный хост.
• Deployment — это конфигурация для развертывания и управления множеством копий приложения (реплик) в виде Pod'ов. Deployment позволяет обновлять приложение с минимальными перерывами, выполнять откаты к предыдущим версиям и масштабировать количество реплик.
• ReplicaSet — это механизм для поддержания определенного количества копий Pod. ReplicaSet гарантирует, что указанное количество реплик будет работать, создавая или удаляя Pod при изменении состояния кластера.
• Service — это абстракция, определяющая доступ к приложению, работающему на одном или нескольких Pod. Service может распределять сетевой трафик между Pod'ами, обеспечивая балансировку нагрузки и высокую доступность.
• Namespace предоставляет изоляцию ресурсов между различными группами пользователей или приложений. Он позволяет иметь одноименные ресурсы в разных пространствах имен и управлять доступом к ресурсам с помощью RBAC (Role-Based Access Control).
• ConfigMap — это объект, позволяющий хранить и управлять конфигурационными данными приложения без изменения образов контейнеров. ConfigMap может быть использован для хранения файлов конфигурации, переменных среды и других конфигурационных данных.
• Secret — это объект, используемый для хранения чувствительных данных, таких как пароли, ключи API или сертификаты. Secret обеспечивает безопасное хранение и передачу такой информации между различными компонентами приложений.
• Volume — это механизм хранения данных, предоставляющий возможность сохранять данные на уровне контейнера или Pod. Kubernetes поддерживает множество типов томов, таких как emptyDir, hostPath, nfs, cephfs и других, позволяя выбирать подходящее хранилище для вашего приложения.
• Ingress — это объект, обеспечивающий доступ к вашим приложениям из внешних сетей. Ingress контролирует внешние HTTP и HTTPS маршруты для приложений, работающих на кластере, и может предоставлять дополнительные функции, такие как SSL/TLS-терминирование, балансировка нагрузки и аутентификация.
• Persistent Volume (PV) — это объект, представляющий собой абстракцию от физического хранилища данных в кластере Kubernetes. PV предоставляет независимость от подключаемых хранилищ и позволяет администраторам определить ресурсы хранения без знания подробностей о том, как они будут использоваться.
• Persistent Volume Claim (PVC) — это заявка на использование Persistent Volume, созданная разработчиком приложения. PVC определяет требования к хранилищу (размер, скорость доступа, тип хранилища), а система автоматически назначает соответствующий PV для этого PVC.
• Horizontal Pod Autoscaler (HPA) — это объект, автоматически масштабирующий количество реплик Pod на основе наблюдаемой загрузки CPU или пользовательских метрик. HPA управляет количеством реплик в Deployment или ReplicaSet для обеспечения эффективного использования ресурсов и обеспечения производительности приложения.
• StatefulSet — это объект, позволяющий развертывать и управлять приложениями, требующими сохранения состояния. StatefulSet гарантирует уникальные и стабильные имена хостов для каждого экземпляра Pod, а так же последовательное развертывание и удаление Pod'ов. Это полезно для приложений, таких как базы данных, которые требуют стабильного сетевого идентификатора и сохранения данных между обновлениями.
• DaemonSet — это объект, гарантирующий запуск определенного контейнера на каждом узле в кластере или на узлах, соответствующих определенным критериям. Это полезно для развертывания системных служб, таких как сборщики метрик, логгеры или агенты мониторинга.
• Job — это объект, позволяющий запускать одноразовые задачи, которые выполняются до успешного завершения. Job управляет созданием и удалением Pod'ов, а также контролирует их выполнение и повторные попытки в случае сбоев.
• CronJob — это объект, предназначенный для запуска Job'ов по расписанию. CronJob управляет временем запуска Job и может автоматически удалять завершенные экземпляры для экономии ресурсов.
• Resource Quota — это объект, определяющий ограничения на количество ресурсов, которые могут быть использованы в определенном пространстве имен. Это позволяет администраторам контролировать потребление ресурсов и предотвращать злоупотребления.
• RBAC (Role-Based Access Control) — это механизм управления доступом в Kubernetes на основе ролей. С помощью RBAC можно определить разрешения на выполнение различных операций для пользователей, групп и сервисных аккаунтов, а также назначать эти разрешения в разных пространствах имен.
• Operators — это расширения Kubernetes, разработанные для автоматизации управления, масштабирования и обновления составных приложений и служб. Операторы представляют собой пользовательские контроллеры (Custom Controllers) и специфичные для ресурса пользовательские объекты (Custom Resource Definitions, CRD), которые управляют определенными приложениями или службами. Важно отметить, что операторы не являются частью базовой функциональности Kubernetes и создаются сторонними разработчиками или организациями. Однако они могут быть очень полезными для автоматизации и управления сложными приложениями и сервисами в кластере Kubernetes.

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

Основные команды kubectl

Kubectl (куб-катл, куб-си-ти-эл) – это утилита командной строки для работы с Kubernetes. Она позволяет управлять кластером, создавать, обновлять и удалять различные ресурсы Kubernetes. В этой главе мы рассмотрим основные команды kubectl и их применение.

Kubectl может быть установлен на различные платформы. Инструкции по установке можно найти в официальной документации Kubernetes.

Работа с ресурсами

Kubectl предоставляет множество команд для работы с различными ресурсами Kubernetes, такими как Pods, Deployments, Services, и др. Некоторые основные команды включают:

• kubectl get: Получение информации о ресурсах. Например, kubectl get pods покажет список всех подов, работающих в текущем неймспейсе.
• kubectl create: Создание ресурса из файла конфигурации. Например, kubectl create -f my-pod.yaml создаст Pod, определенный в файле my-pod.yaml.
• kubectl apply: используется для создания или обновления ресурсов в кластере. Команда принимает файл или директорию с конфигурационными файлами YAML или JSON.

Создать или обновить ресурсы, описанные в файле:

kubectl apply -f my-resource.yaml

Создать или обновить ресурсы, описанные во всех файлах в директории:

kubectl apply -f my-resources-directory/

• kubectl delete: Удаление ресурса. Например, kubectl delete pod my-pod удалит Pod с именем my-pod.
• kubectl logs: Получение логов ресурса. Например, kubectl logs my-pod покажет логи Pod с именем my-pod.
• kubectl exec: Запуск команды в контейнере ресурса. Например, kubectl exec my-pod -- ls /app выполнит команду ls /app в контейнере Pod с именем my-pod.

Работа с неймспейсами

В Kubernetes ресурсы разделены на неймспейсы. Если неймспейс не указан явно, kubectl будет использовать неймспейс "default". Чтобы указать конкретный неймспейс, используйте флаг -n или --namespace. Например:

kubectl get pods -n my-namespace

Чтобы посмотреть список всех неймспейсов, используйте следующую команду:

kubectl get namespaces

Контексты kubectl

Kubectl использует контексты для работы с разными кластерами, пользователей и неймспейсов. Контексты определяются в файле конфигурации kubectl (~/.kube/config). Чтобы посмотреть список доступных контекстов и текущий активный контекст, выполните следующую команду:

kubectl config get-contexts

Чтобы изменить текущий контекст, используйте команду kubectl config use-context. Например:

kubectl config use-context my-context

Работа с манифестами

Для управления ресурсами Kubernetes обычно используются файлы конфигурации в формате YAML или JSON. Вот пример YAML-файла для создания Deployment:

Чтобы создать ресурсы из файла, используйте команду kubectl create -f. Например:

kubectl create -f my-deployment.yaml

Чтобы обновить ресурсы из файла, используйте команду kubectl apply -f. Например:

kubectl apply -f my-deployment.yaml

Установка тестового окружения

На выбор предлагаю два варианта настройки тестовой среди окружения, при помощи Minikube и при помощи k3s, первый - хорошо подходит для локальных экспериментов и не подходит для создания кластера распределённого на нескольких машинах, а вот второй - как-раз может работать как локально, так и на нескольких машинах.

Вариант 1 - Развёртывание Minikube

Теперь поговорим про самый простой способ быстро развернуть у себя всю эту красоту и погрузиться в эксперименты!

Самый простой способ начать изучать Kubernetes

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

Установка Minikube

1. Установите гипервизор для виртуализации, например, VirtualBox или KVM для Linux, HyperKit для macOS или Hyper-V для Windows

2. Скачайте и установите Minikube:
Для Linux:

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
chmod +x minikube
sudo mv minikube /usr/local/bin/

Для macOS:

brew install minikube

Для Windows:

choco install minikube

Запуск Minikube

Запустите Minikube, выполнив следующую команду:

minikube start

Эта команда создаст и запустит виртуальную машину с предустановленным одноузловым кластером Kubernetes.

Проверьте состояние кластера с помощью команды:

minikube status

Если все в порядке, вы увидите сообщение о том, что Minikube работает и доступен.

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

kubectl get nodes

Работа с Minikube

Minikube использует файл ~/.kube/config для хранения настроек и информации о подключении к кластеру. При запуске Minikube автоматически обновляет этот файл. Вы можете использовать kubectl для работы с кластером Minikube, как и с любым другим кластером Kubernetes.

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

minikube stop

Эта команда остановит виртуальную машину и освободит ресурсы компьютера.

Для удаления ресурсов Minikube, связанных с вашим кластером, используйте команду:

minikube delete

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

Minikube предоставляет встроенный инструмент для управления аддонами Kubernetes. Чтобы просмотреть список доступных аддонов, выполните команду:

minikube addons list

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

minikube addons enable <addon_name>
minikube addons disable <addon_name>

Если вам нужно получить доступ к веб-интерфейсу Kubernetes Dashboard, Minikube может открыть его для вас. Для этого выполните команду:

minikube dashboard

Браузер автоматически откроет Kubernetes Dashboard, и вы сможете управлять кластером через веб-интерфейс.

Внешний вид Kubernetes Dashboard

Возможно, вам потребуется доступ к локально развернутому приложению, работающему в кластере Minikube. Для этого используйте команду minikube service:

minikube service <service_name>

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

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

Вариант 2 - Развёртывание k3s

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

Проще чем k8s

Существует несколько вариантов установки, например в режиме standalone приложения, в режиме композиции из Docker контейнеров, рассмотрим оба вариантов.

Установка k3s с использованием Docker Compose

Прежде всего, создайте файл docker-compose.yml с примером следующего содержимого:

Этот файл описывает развёртывание k3s сервера и агента, однако, важно обратить внимание на одну маленькую его особенность.

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

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

Когда вы настраиваете k3s, K3S_TOKEN указывается на сервере и передается каждому агенту, который будет подключаться к серверу. В файле docker-compose.yml или в юните systemd для агента (в зависимости от вашего способа установки k3s), вы должны указать токен в переменной среды K3S_TOKEN. Это гарантирует, что агенты используют правильный токен для аутентификации на сервере.

С токером разобрались, поэтому далее создадим пустой файл kubeconfig.yaml чтобы после первого запуска сервер положил в него конфигурации, которые позже надо будет скопировать себе в ~/.kube/config

touch kubeconfig.yaml

Для запуска, выполните следующую команду в каталоге с файлом docker-compose.yml:

docker-compose up -d

Это создаст и запустит контейнеры k3s сервера и агента, а также сгенерирует файл конфигурации kubeconfig.yaml.

Standalone установка в паре с systemd

K3s также может быть установлен и запущен стандартным способом. Для установки k3s, выполните следующую команду:

curl -sfL https://get.k3s.io | sh -

После успешной установки, создайте юниты systemd для сервера и агента. Создайте файл /etc/systemd/system/k3s-server.service с содержимым:

[Unit]
Description=k3s server
After=network.target

[Service]
ExecStart=/usr/local/bin/k3s server
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Далее создайте файл /etc/systemd/system/k3s-agent.service с содержимым:

[Unit]
Description=k3s agent
After=network.target

[Service]
ExecStart=/usr/local/bin/k3s agent --server https://myserver:6443 --token mysecrettoken
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Замените myserver на адрес вашего k3s сервера и mysecrettoken на токен, сгенерированный сервером. Выполните следующие команды, чтобы перезапустить systemd и запустить k3s сервер и агента:

sudo systemctl daemon-reload
sudo systemctl enable k3s-server
sudo systemctl start k3s-server
sudo systemctl enable k3s-agent
sudo systemctl start k3s-agent

Режим сервера и режим обычной ноды

Как вы могли заметить K3s может быть развернут в двух режимах: режим сервера и режим обычной ноды (агент).

• Режим сервера: В этом режиме k3s выполняет функции управления кластером и является главным узлом. Он управляет остальными узлами, следит за состоянием кластера и обрабатывает запросы от kubectl. В режиме сервера k3s обеспечивает необходимые сервисы, такие как etcd, контроллеры и API-сервер Kubernetes.
• Режим обычной ноды (агент): В этом режиме k3s выполняет функции рабочего узла, обрабатывая нагрузки, запускаемые в кластере, и выполняя назначенные задачи. Агент подключается к серверу, получает конфигурацию и инструкции, и выполняет назначенные ему контейнеры и задачи.

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

Теперь, когда вы узнали о развёртывании k3s, вы можете перейти к следующим шагам и опробовать разные виды объектов, которые существуют в Kubernetes, а также научиться создавать Helm-чарты и работать с YML-конфигурациями.

Создание простого Pod

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

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

Если вы не указываете пространство имен при создании объектов, они будут создаваться в пространстве имен default. Если вы хотите разделить ресурсы и приложения между разными группами, проектами или средами, вы можете использовать Namespace для этого.

Для создания простого Pod с одним контейнером, создайте файл с именем my-pod.yaml со следующим содержанием:

В этом файле мы создаем объект типа Pod с именем my-pod в пространстве имен my-namespace. В Pod будет один контейнер, основанный на образе nginx:latest, который будет прослушивать порт 80.

Сначала создадим пространство имен, используя команду kubectl. Создайте файл my-namespace.yaml со следующим содержанием:

Создайте пространство имен, выполнив команду:

kubectl create -f my-namespace.yaml

Теперь, когда пространство имен создано, мы можем создать наш Pod:

kubectl create -f my-pod.yaml

Чтобы проверить статус созданного Pod, используйте следующую команду:

kubectl get pods -n my-namespace

Вы должны увидеть информацию о вашем Pod и его текущем состоянии. Если ваш контейнер успешно запущен, статус должен быть Running.

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

Deployment и ReplicaSet

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

Deployment

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

Рассмотрим пример создания Deployment. Создайте файл my-deployment.yaml со следующим содержанием:

Здесь мы создаем объект типа Deployment с именем my-deployment в пространстве имен my-namespace, указанном ранее. Мы указываем, что хотим иметь 3 копии нашего приложения, и определяем селектор, который будет использоваться для поиска соответствующих Pod. В спецификации шаблона (template) указывается конфигурация контейнеров.

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

kubectl create -f my-deployment.yaml

ReplicaSet

ReplicaSet — это объект Kubernetes, который отвечает за поддержание заданного числа копий Pod. Если Deployment обеспечивает управление версиями и стратегиями обновления, ReplicaSet отвечает только за масштабирование и восстановление после сбоев.

Deployment автоматически создает и управляет одним или несколькими ReplicaSet, а ReplicaSet, в свою очередь, создает и управляет подами. Когда Deployment обновляется, он создает новый ReplicaSet и начинает увеличивать количество подов в нем, одновременно уменьшая количество подов в старом ReplicaSet.

Таким образом, в большинстве случаев вам следует использовать Deployment вместо ReplicaSet, если вам необходимо управлять масштабированием и обновлениями вашего приложения.

Health Checks (Хелсчеки)

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

1. Liveness Probe - определяет, работает ли приложение в контейнере. Если эта проверка не пройдена, Kubernetes перезапустит контейнер.
2. Readiness Probe - определяет, готово ли приложение обрабатывать запросы. Если проверка не пройдена, Kubernetes не будет направлять трафик на этот контейнер.

Пример с хелсчеками в Deployment

Допустим, мы хотим добавить хелсчеки для нашего my-deployment:

В этом примере мы добавили livenessProbe и readinessProbe для контейнера my-container. Здесь использован тип проверки httpGet, который выполняет HTTP-запрос к указанному пути и порту контейнера. Параметры initialDelaySeconds и periodSeconds указывают задержку перед началом проверок и интервал между ними соответственно.

Это лишь один из вариантов хелсчеков; вы также можете использовать tcpSocket (для проверки открытого TCP-сокета) или exec (для выполнения произвольной команды в контейнере).

ConfigMap

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

В данном примере создадим ConfigMap для нашего деплоймента my-deployment, который будет содержать конфигурацию для приложения.

Создайте файл configmap.yaml:

Примените ConfigMap, выполнив команду:

kubectl apply -f configmap.yaml

Теперь нужно изменить Deployment, чтобы использовать данный ConfigMap. Отредактируйте файл my-deployment.yaml:

В этом примере мы добавили объявление тома config-volume, который ссылается на созданный ConfigMap my-deployment-config. Затем мы добавили volumeMounts в контейнере my-app-container, который монтирует том config-volume в директорию /app/config контейнера.

Теперь приложение в контейнере сможет обращаться к файлу /app/config/app-config.json, который будет содержать конфигурацию из ConfigMap.

Service

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

Рассмотрим пример создания Service для нашего Deployment my-deployment. Создайте файл my-service.yaml со следующим содержанием:

Здесь мы создаем объект типа Service с именем my-service в пространстве имен my-namespace. Мы указываем селектор, который будет использоваться для поиска соответствующих подов (в нашем случае поды с меткой app: my-app). Тип LoadBalancer означает, что Service будет использовать внешний балансировщик нагрузки для распределения трафика между подами.

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

kubectl create -f my-service.yaml

Ingress

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

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

Вот пример Ingress для нашего Service my-service. Создайте файл my-ingress.yaml со следующим содержанием:

Здесь мы создаем объект типа Ingress с именем my-ingress в пространстве имен my-namespace. Мы определяем правило маршрутизации для хоста my-app.example.com, которое направляет трафик на наш Service my-service.

Чтобы создать Ingress, выполните следующую команду:

kubectl create -f my-ingress.yaml

Wildcard домены и DNS

Wildcard домены позволяют направлять все поддомены определенного уровня на один и тот же IP-адрес или набор серверов. Например, запись DNS с wildcard-доменом *.example.com будет перенаправлять трафик с любого поддомена на один и тот же IP-адрес.

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

Чтобы настроить поддержку wildcard-доменов на вашем DNS-сервере, создайте запись с символом звездочки в качестве поддомена. Например, для домена example.com создайте запись *.example.com, указывающую на IP-адрес вашего Ingress-контроллера.

Теперь, когда мы настроили Ingress и поддержку wildcard-доменов, наш Deployment my-deployment будет работать корректно. Трафик, направленный на поддомены example.com, будет маршрутизироваться на наш Service my-service, который в свою очередь перенаправляет его на поды my-deployment.

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

Про Helm и чарты

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

То что нужно для удобства

Установка Helm

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

Создание Helm чарта

Для создания Helm чарта выполните команду helm create. Например:

helm create my-chart

Это создаст новый каталог с именем my-chart со следующей структурой:

my-chart/
├── Chart.yaml
├── .helmignore
├── values.yaml
├── templates/
│ ├── deployment.yaml
│ ├── ingress.yaml
│ ├── service.yaml
│ └── ...
└── charts/

Где:

• Chart.yaml – содержит метаданные о чарте, такие как имя, версия и описание.
• .helmignore – указывает, какие файлы и папки Helm должен игнорировать при работе с чартом.
• values.yaml – содержит настройки и значения по умолчанию, которые используются при генерации манифестов из шаблонов.
• templates/ – папка с шаблонами манифестов Kubernetes, которые будут генерироваться на основе значений из values.yaml.
• charts/ – папка для вложенных (зависимых) чартов.

Шаблонизация манифестов

Основная идея Helm чартов заключается в использовании шаблонов на базе языка Go Template. Это позволяет динамически генерировать манифесты Kubernetes на основе значений из values.yaml или переданных пользователем. Например, в файле templates/deployment.yaml вы можете использовать следующий шаблон:

Значения, которые начинаются с .Values., будут подставляться из файла values.yaml или из переданных пользователем значений.

Установка чарта

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

helm install my-release ./my-chart

Это создаст новый релиз с именем my-release, используя манифесты, сгенерированные на основе шаблонов и значений по умолчанию из файла values.yaml.

Если вы хотите переопределить значения по умолчанию, вы можете передать их через флаг --set. Например:

helm install my-release ./my-chart --set deployment.replicas=3

Вы также можете создать файл values.override.yaml с переопределенными значениями и передать его с помощью флага -f:

Выполним команду:

helm install my-release ./my-chart -f values.override.yaml

Обновление и удаление релиза

Для обновления релиза выполните команду helm upgrade:

helm upgrade my-release ./my-chart

Для удаления релиза используйте команду helm uninstall:

helm uninstall my-release

Преимущества использования Helm чартов

Использование Helm чартов вместо обычных YAML-манифестов имеет ряд преимуществ:

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

Теперь, когда вы знакомы с основными аспектами работы с Kubernetes, вам должно быть легче начать использовать его в своих проектах. От простых Pod'ов и Deployment'ов до продвинутых Helm чартов и операторов – Kubernetes предоставляет мощные инструменты для управления и развертывания сложных приложений на разных платформах и архитектурах.

Трюки с Helm

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

Переключение контекста

Helm автоматически использует текущий контекст kubectl, но иногда вам может потребоваться работать с несколькими кластерами или неймспейсами одновременно. Для этого вы можете использовать переменную окружения KUBECONFIG:

KUBECONFIG=~/.kube/config-my-cluster helm list

Использование циклов в шаблонах

Helm поддерживает циклы и условные конструкции, что позволяет создавать более сложные и гибкие шаблоны. Например, вы можете использовать цикл range для генерации списка портов:

Использование вложенных шаблонов

Вы можете использовать вложенные шаблоны для создания более модульной и гибкой структуры:

Использование "хуков"

Хуки Helm позволяют выполнять действия на разных этапах жизненного цикла релиза, таких как установка, обновление, откат и удаление. Например, вы можете использовать хук post-install для автоматического создания ресурсов после установки релиза:

В этом примере после установки релиза будет запущена задача Job, выполняющая скрипт post-install.sh.

Использование управляемых апгрейдов

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

helm upgrade my-release my-chart --wait

Использование секретов Helm

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

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

Пользовательские функции

Helm позволяет использовать пользовательские функции в шаблонах, что может существенно упростить работу со сложными конфигурациями. Например, вы можете создать пользовательскую функцию для генерации URL из значения с использованием Go шаблонизатора:

Теперь вы можете использовать эту функцию в других шаблонах для генерации URL на основе значений конфигурации:

С использованием этой функции, конфигурационная карта будет содержать сгенерированный URL https://myapp.example.com/api.

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

Итог

В данной статье мы рассмотрели основы Kubernetes, его терминологию и ключевые понятия. Познакомились с различными типами объектов, такими как Pod, Deployment, ReplicaSet, Service, Ingress, хелсчеками и ConfigMap, а также научились использовать утилиту kubectl для управления ресурсами кластера. Мы также обсудили развёртывание мини-кластера с использованием Minikube и k3s, а также изучили Helm и его возможности для упрощения работы с конфигурациями в Kubernetes.

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

К тому же, если вы хотите поддержать мои усилия и вклад в развитие общества знаний, вы можете сделать пожертвование на CloudTips. Ваша поддержка поможет мне продолжать свою работу и делиться новыми открытиями с вами.

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