Kubernetes (от др.-греч. κυβερνήτης — «кормчий», «рулевой», часто также используется нумероним K8s) — открытое программное обеспечение для автоматизации развёртывания, масштабирования контейнеризированных приложений и управления ими. Поддерживает основные технологии контейнеризации, включая Docker, также возможна поддержка технологий аппаратной виртуализации. (Wikipedia)
В этой статье мы рассмотри базис из наиболее часто используемых ресурсов Kubernetes.
Pod
Pod - минимальный базовый примитив. Pod объединяет в себе набор контейнеров, нацеленных на выполнение одной задачи, например: фронтенд + бэкенд для какого-нибудь сервиса.
Pod предоставляет:
- объединение 1+ контейнеров
- инкапсуляция зависимостей
- контроль жизненного цикла: автоматический перезапуск контейнеров при ошибках, привязка к выделенному узлу и др.
- init-контейнеры: отдельный тип контейнеров, выполняемых перед запуском основного приложения, и выполняющих подготовку окружения/системы
- хранилище: на уровне pod возможно настроить привязку к контейнерам эфимерных (временных) или персистентных (постоянных) хранилищ данных
- метки: каждый pod обладает набором меток, которые можно использовать для фильтрации pod или в связях с другими ресурсами, например объединение pod в группу для балансировки нагрузки
В Kubernetes все ресурсы описываются в формате yaml. Описание простейшего pod выглядит так:
apiVersion: v1
kind: Pod
metadata:
name: manual-bash
spec:
containers:
- name: bash
image: ubuntu:18.04
command: bash
args: [-c, "while true; do sleep 1; date; done"]
Здесь мы создаем pod с названием manual-bash. Он включает в себя один контейнер с ОС ubuntu 18.04. При запуске контейнера, в нём будет выполнена команда bash -c "while true; do sleep 1; date; done"
Namespace
Ограниченный контур. Позволяет разграничивать:
- рабочие контура: dev, stage, prod
- песочницы для разработчиков
- отдельные приложения
ReplicaSet
Группа однотипных Pod. Основным его предназначением является упрощение масштабирования приложений. Для этого в описании ресурса присутствует параметр replicas, изменяя который, можно менять количество запущенных экземпляров
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# modify replicas according to your case
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
Помимо ручного изменения количества реплик, возможно настроить автоматическое масштабирование благодаря HPA (Horizontal Pod Autoscaler)
Deployment
Теперь давайте представим, что нам нужно не просто масштабировать приложения, а также и управлять его версиями:
- контролировать скорость и тип замены версий
- иметь возможность откатиться до предыдущей версии
Данные задачи выполняет Deployment, расширяющий ReplicaSet:
- включает настройки скорость и типа добавления/удаления реплик
- каждая версия сохраняется как отдельный ReplicaSet
Volume
Для многих контейнеризованных приложений достаточно стандартного временного хранилища контейнеров. Но часто требуется подключение внешнего постоянного хранилища, например, для баз данных. Для этих целей служат ресурсы типа Volume, которые предоставляют:
- контроль типа доступа: чтение-запись
- поддержка различных провайдеров: железные, программные, облачные
Kuberetes поддерживает широкий набор хранилищ:
- awsElasticBlockStore
- azureDisk
- azureFile
- cephfs
- cinder
- configMap
- csi
- downwardAPI
- emptyDir
- fc (fibre channel)
- flexVolume
- flocker
- gcePersistentDisk
- glusterfs
- hostPath
- iscsi
- local
- nfs
- persistentVolumeClaim
- projected
- portworxVolume
- quobyte
- rbd
- scaleIO
- secret
- storageos
- vsphereVolume
StatefulSet
StatefulSet представляет из себя модификацию deployment для stateful приложений. Его основные отличия:
- нумерованные реплики: app-0, app-1, … (обычный deployment использует случайный суффикс для реплик: например app-nfgie)
- отдельный Volume для каждой реплики (обычный deployment использует подключает общий диск ко всем репликам сразу)
Этот тип ресурсов хорошо подходит для баз данных.
Service
По-умолчанию ни одно приложение не имеет доступа извне кластера. Для предоставления внешного доступа к приложениям служит следующий тип ресурсов: Service - сетевой интерфейс для доступа к приложениям в кластере.
Он выполняет следующие функции:
- DNS-имя - каждый сервис получает фиксированное dns имя для доступа в кластере вида service-name.namespace.cluster.local
- фиксированный виртуальный IP, остающийся неизменным даже после перезапуска приложения на другом узле (в отличии от ip-адреса pod)
- выбор по селектору и балансировщик нагрузки - сервисы позволяют создавать интерфейс над группой экземпляров приложения (в том числе, объединять несколько версий одного приложения или несколько различных приложений) и балансировать нагрузку на них
Ingress
Service не позволяет настраивать выборочную маршрутизацию трафика - весь трафик балансируется по всем контейнерам, удовлетворяющим селектору. Таким образом, при необходимости предоставления публичного доступа ко многим приложениям в кластере, необходимо создавать множество сервисов, привязывать к каждому из них отдельный ip и для каждого домена прописывать свой адрес. Это не очень удобно.
Для решения этой проблемы существует Ingress - единая точка маршрутизации внешнего трафика к приложениям и сервисам внутри кластера. Он позволяет:
- маршрутизировать внешние запросы на основе домена, пути, заголовков…
- иметь единую точку для TLS-шифрования внешнего трафика
- имеет множество имплементаций, таких как Nginx, Istio и другие
ConfigMap и Secret
Secret - хранилище для разнообразных чувствительных (секретных) данных, таких как пароли или ключи API
ConfigMap - настройки/переменные приложений.
Оба данных типа ресурсов похожи в использовании:
- подключаются как файл или переменные окружения
- имеют множество форматов: одиночные значения / пару ключ-значение / многомерные структуры
Job и CronJob
Как можно догадаться из названия, данные типы ресурсов предназначены для выполнения разовых или регулярных задач.
В отличии от стандартных cron задач linux, данные ресурсы также предоставляют гарантии выполнения. Например, можно настроить задачу на перезапуск до N успешных выполнений.
На этом мы заканчиваем ознакомление с базисом ресурсов Kubernetes. Знание и понимание работы данных типов ресурсов позволят вам успешно использовать возможности kubernetes в своей работе.
Для более глубокого ознакомления с составными частями kubernetes я рекомендую воспользоваться официальной документацией: https://kubernetes.io/docs/home/
До новых встреч.