🤔 Что такое Kubernetes — Open Standards (OCI, CRI, CNI, CSI, SMI, CPI)?

Kubernetes активно использует стандарты с открытым исходным кодом для обеспечения совместимости и расширяемости. Основные из них включают OCI, CRI, CNI, CSI, SMI и CPI. Эти стандарты определяют интерфейсы и протоколы, которые позволяют Kubernetes взаимодействовать с различными компонентами и инструментами.

🚩OCI (Open Container Initiative)

Проект Linux Foundation, который определяет стандарты для контейнеров. Основные спецификации OCI:
🟠OCI Image Format: Стандартный формат для контейнерных образов.
🟠OCI Runtime: Стандарт для выполнения контейнеров.

Kubernetes использует OCI-совместимые образы и среды выполнения, такие как runc, для обеспечения универсальной совместимости контейнеров.

🚩CRI (Container Runtime Interface)

Это интерфейс, который позволяет Kubernetes взаимодействовать с различными средами выполнения контейнеров. CRI определяет набор API, через которые kubelet может запускать и управлять контейнерами.
🟠containerd
🟠CRI-O
🟠Docker (через dockershim, который вскоре будет удален)

🚩CNI (Container Network Interface)

Это стандарт для настройки сетевых интерфейсов контейнеров и управления их жизненным циклом. CNI обеспечивает гибкость и расширяемость сетевых решений в Kubernetes.
🟠Calico
🟠Flannel
🟠Weave
🟠Cilium

🚩CSI (Container Storage Interface)

Это стандарт, который позволяет Kubernetes взаимодействовать с различными системами хранения данных. CSI определяет API для создания, удаления, монтирования и управления томами.
🟠Ceph
🟠 Amazon EBS
🟠Google Persistent Disk
🟠Azure Disk

🚩SMI (Service Mesh Interface)

Стандартный интерфейс для управления сервисными сетями (service mesh) в Kubernetes. SMI предоставляет набор абстракций для таких функций, как маршрутизация, телеметрия и управление трафиком.
🟠Istio
🟠Linkerd
🟠Consul Connect

🚩CPI (Cloud Provider Interface)

Интерфейс, который позволяет Kubernetes взаимодействовать с различными облачными провайдерами. CPI управляет ресурсами облака, такими как виртуальные машины, сети и хранилища, в контексте Kubernetes-кластера.
🟠AWS
🟠Google Cloud
🟠Microsoft Azure
🟠OpenStack

🚩Применение стандартов в Kubernetes

🟠Совместимость и расширяемость: Использование открытых стандартов обеспечивает совместимость между различными компонентами и упрощает интеграцию новых технологий.
🟠Упрощение управления: Стандарты, такие как CRI, CNI и CSI, упрощают управление контейнерами, сетями и хранилищами, предоставляя единообразные интерфейсы и API.
🟠Масштабируемость и гибкость: Открытые стандарты позволяют Kubernetes легко адаптироваться к различным средам и требованиям, обеспечивая гибкость и масштабируемость приложений.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие коды сообщений или ошибок HTTP знаешь и что это значит?

🚩HTTP коды статуса — это трехзначные числовые коды, которые сервер возвращает клиенту в ответ на HTTP запрос. Эти коды указывают на статус обработки запроса и помогают клиенту понять результат выполнения запроса. Коды делятся на пять категорий:

🟠1xx: Информационные коды
- 100 Continue: Сервер получил начальную часть запроса и клиент может продолжать отправку запроса.
- 101 Switching Protocols: Сервер переключается на другой протокол, указанный в заголовке Upgrade.

🟠2xx: Коды успешного выполнения
- 200 OK: Запрос выполнен успешно. Наиболее распространенный код для успешных запросов.
- 201 Created: Запрос успешно выполнен и приведен к созданию ресурса. Используется, например, при отправке данных на сервер для создания новой записи.
- 202 Accepted: Запрос принят для обработки, но обработка еще не завершена.
- 204 No Content: Запрос выполнен успешно, но тело ответа пусто.

🟠3xx: Коды перенаправления
- 301 Moved Permanently: Ресурс был перемещен на новый постоянный URL. Клиент должен использовать новый URL для будущих запросов.
- 302 Found: Ресурс временно доступен по другому URL. Клиент должен использовать оригинальный URL для будущих запросов.
- 304 Not Modified: Ресурс не был изменен с момента последнего запроса. Клиент может использовать кэшированную версию.

🟠4xx: Коды ошибок клиента
- 400 Bad Request: Сервер не может обработать запрос из-за ошибки клиента (например, неверный синтаксис запроса).
- 401 Unauthorized: Запрос требует аутентификации. Клиент должен предоставить учетные данные для доступа к ресурсу.
- 403 Forbidden: Сервер понял запрос, но отказывается его выполнять. Клиент не имеет необходимых прав для доступа к ресурсу.
- 404 Not Found: Ресурс не найден. Сервер не может найти запрошенный ресурс.
- 405 Method Not Allowed: Метод, указанный в запросе, не поддерживается для данного ресурса.
- 409 Conflict: Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.
- 429 Too Many Requests: Клиент отправил слишком много запросов за короткий период. Используется для ограничения скорости запросов.

🟠5xx: Коды ошибок сервера
- 500 Internal Server Error: Общая ошибка сервера. Сервер столкнулся с неожиданной ситуацией, которая помешала выполнению запроса.
- 501 Not Implemented: Сервер не поддерживает функциональность, необходимую для выполнения запроса.
- 502 Bad Gateway: Сервер, выступающий в роли шлюза или прокси, получил недопустимый ответ от вышестоящего сервера.
- 503 Service Unavailable: Сервер временно недоступен, обычно из-за перегрузки или технического обслуживания.
- 504 Gateway Timeout: Сервер, выступающий в роли шлюза или прокси, не получил своевременный ответ от вышестоящего сервера.

1: 200 OK

GET /index.html HTTP/1.1
Host: www.example.com

```http
HTTP/1.1 200 OK
Content-Type: text/html
<html>
<head><title>Example</title></head>
<body>Example page</body>
</html>

2: 404 Not Found

http
GET /nonexistent.html HTTP/1.1
Host: www.example.com

http
HTTP/1.1 404 Not Found
Content-Type: text/html
<html>
<head><title>404 Not Found</title></head>
<body>Page not found</body>
</html>`


Ставь 👍 и забирай 📚 Базу знаний

🤔 Что есть Docker, а что Docker daemon?

💬 Спрашивают в 13% собеседований

🚩Что такое Docker

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

Основные компоненты Docker
🟠Docker Engine: Основной компонент Docker, включающий Docker daemon, CLI и API.
🟠Контейнеры: Легковесные и портативные окружения, содержащие все необходимое для запуска приложения.
🟠Образы (Images): Шаблоны для создания контейнеров, включающие файловую систему и настройки для запуска приложения.
🟠Docker Hub: Регистратор Docker-образов, где можно хранить и распространять образы.

Docker daemon (dockerd) — это основной процесс Docker, который управляет контейнерами, образами, сетями и хранилищами. Docker daemon отвечает за выполнение команд, отправляемых через Docker CLI или API, и контролирует все операции, связанные с контейнерами.

Основные функции Docker daemon

🟠Управление контейнерами:
- Создание, запуск, остановка, перезапуск и удаление контейнеров.
- Мониторинг состояния контейнеров и их взаимодействия с хостовой системой.

🟠Управление образами:
- Загрузка, создание, тегирование и удаление Docker-образов.
- Кэширование слоев образов для оптимизации повторного использования.

🟠 Управление сетями:
- Создание и управление виртуальными сетями для контейнеров.
- Поддержка различных сетевых драйверов (bridge, host, overlay и т.д.).

🟠Управление хранилищами:
- Создание и управление томами (volumes) для постоянного хранения данных контейнеров.

🚩Как работает Docker daemon

Docker daemon работает в фоновом режиме и взаимодействует с Docker CLI и API для выполнения команд. Когда пользователь вводит команду через Docker CLI (например, docker run), CLI отправляет эту команду Docker daemon через API. Docker daemon обрабатывает команду, выполняет необходимые действия и возвращает результат через CLI.

🟠Команда запуска контейнера: Пользователь вводит команду docker run hello-world в терминале.
🟠Docker CLI: Docker CLI отправляет запрос на запуск контейнера Docker daemon через API.
🟠Docker daemon: Docker daemon проверяет локальное наличие образа hello-world. Если образ отсутствует, он загружает его из Docker Hub.
🟠Docker daemon создает и запускает контейнер на основе образа hello-world.
🟠Docker daemon возвращает результат выполнения команды Docker CLI.

Результат: Пользователь видит вывод в терминале, подтверждающий успешный запуск контейнера.

$ docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Чем отличается процесс от потока?

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

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

🚩Основные характеристики процесса:

🟠Изоляция: Каждый процесс имеет свое собственное адресное пространство и ресурсы (файлы, память).
🟠Контекст выполнения: Процесс имеет свой собственный контекст выполнения, включая регистры процессора, виртуальную память и дескрипторы файлов.
🟠Создание процессов: Создание нового процесса (например, с помощью системного вызова fork в Unix-подобных системах) занимает больше времени и ресурсов по сравнению с созданием потоков.
🟠Межпроцессное взаимодействие (IPC): Для обмена данными между процессами требуются механизмы IPC.

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

🚩Основные характеристики потока:

🟠Разделение ресурсов: Потоки одного процесса разделяют одно адресное пространство и ресурсы, такие как открытые файлы и память.
🟠Контекст выполнения: Каждый поток имеет свой собственный контекст выполнения, включая регистры процессора и стек, но разделяет память с другими потоками процесса.
🟠Создание потоков: Создание нового потока (например, с помощью pthread_create в POSIX-системах) быстрее и требует меньше ресурсов по сравнению с созданием нового процесса.
🟠Синхронизация: Потоки часто используют примитивы синхронизации, такие как мьютексы (mutexes), семафоры (semaphores) и условные переменные (condition variables) для координации доступа к общим ресурсам.

🚩Сравнение процессов и потоков

Память и ресурсы:
🟠Процессы: Изолированы друг от друга, имеют собственное адресное пространство и ресурсы.
🟠Потоки: Разделяют адресное пространство и ресурсы процесса.

Создание и управление:
🟠Процессы: Создание и управление процессами более затратное по времени и ресурсам.
🟠Потоки: Создание и управление потоками быстрее и менее затратное.

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

Пример создания процесса (на C с использованием fork):

#include <stdio.h>
#include <unistd.h>
int main() {
    pid_t pid = fork();
    if (pid == 0) {
        printf("Это дочерний процесс\n");
    } else if (pid > 0) {
        printf("Это родительский процесс\n");
    } else {
        perror("fork");
        return 1;
    }
    return 0;
}

Пример создания потока (на C с использованием pthreads):

#include <stdio.h>
#include <pthread.h>
void* thread_function(void* arg) {
    printf("Это поток\n");
    return NULL;
}
int main() {
    pthread_t thread;
    pthread_create(&thread, NULL, thread_function, NULL);
    pthread_join(thread, NULL);
    printf("Главный поток\n");
    return 0;
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Почему сейчас systemd используется чаще чем init?

Systemd стала основной системой инициализации для Unix-подобных ОС, управляя процессами и службами при загрузке и вытеснив традиционные системы, такие как System V init.

🚩Основные преимущества systemd

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

🟠Управление зависимостями:
init: Ограниченные возможности управления зависимостями между сервисами.
systemd: Предоставляет сложное управление зависимостями, автоматически определяя порядок запуска и останова сервисов.

🟠Мониторинг и перезапуск сервисов:
init: Ограниченные возможности мониторинга и автоматического перезапуска упавших сервисов.
systemd: Встроенные функции для мониторинга состояния сервисов и автоматического их перезапуска в случае сбоя.

🟠Унификация конфигурации:
init: Различные дистрибутивы могут использовать разные форматы и скрипты инициализации.
systemd: Стандартизированный формат конфигурационных файлов (unit-файлов), что упрощает администрирование и переносимость.

🟠Журналирование:
init: Использует отдельные инструменты для журналирования, такие как syslog.
systemd: Встроенная система журналирования (journald), которая объединяет логи всех сервисов и предоставляет мощные возможности для их анализа.

🟠Управление состоянием системы:
init: Ограниченные возможности управления состоянием системы, такими как спящий режим, гибернация и выключение.
systemd: Встроенные команды для управления состоянием системы, такие как systemctl suspend, systemctl hibernate и systemctl poweroff.

🚩Примеры использования systemd

Запуск и остановка сервисов:

systemctl start httpd.service

Остановка сервиса:

systemctl stop httpd.service     

Проверка статуса сервиса:

systemctl status httpd.service   

Включение автозапуска:

systemctl enable httpd.service    

Отключение автозапуска:

systemctl disable httpd.service     

Пример unit-файла для сервиса Nginx:

[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target
[Service]
ExecStart=/usr/sbin/nginx
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/usr/sbin/nginx -s quit
PIDFile=/run/nginx.pid
Restart=always
[Install]
WantedBy=multi-user.target

Ставь 👍 и забирай 📚 Базу знаний

🤔 Почему если поставить докер и создать образ он может не запускаться в чем может быть причина?

🟠Ошибки в Dockerfile
Ошибки в синтаксисе или логике Dockerfile могут приводить к созданию некорректного образа. Если указаны неверные пути или отсутствуют необходимые файлы, образ может не работать. Если директория app/ отсутствует, команда COPY завершится с ошибкой.

COPY app/ /usr/src/app
CMD ["python", "/usr/src/app/app.py"]

🟠Отсутствие зависимостей
Если необходимые библиотеки или пакеты не установлены, приложение не сможет запуститься. Если app.py требует внешних библиотек, их нужно установить с помощью RUN pip install.

FROM python:3.8
COPY app.py /
CMD ["python", "/app.py"]

🟠Неправильная рабочая директория
Если не указана правильная рабочая директория, команды могут выполняться в неверном контексте. Если не указать WORKDIR /app, Node.js не сможет найти index.js.

FROM node:14
COPY . /app
WORKDIR /app
CMD ["node", "index.js"]

🟠Ошибки конфигурации
Отсутствие или неправильная настройка переменных окружения может приводить к сбоям. Если контейнер слушает на порту, который не открыт, он не будет доступен извне. Если default.conf имеет ошибки конфигурации, Nginx не запустится.

FROM nginx
COPY default.conf /etc/nginx/conf.d/

🟠Проблемы с правами доступа
Если файлы или директории имеют неправильные права доступа, приложение может не запуститься. Некоторые приложения требуют выполнения от имени определенного пользователя. Если nobody не имеет права выполнения скрипта, контейнер не запустится.

FROM ubuntu
COPY script.sh /
RUN chmod +x /script.sh
USER nobody
CMD ["/script.sh"]

🟠Недостаток ресурсов
Недостаток памяти или процессорного времени может привести к сбою при запуске контейнера. Если приложение требует больше памяти, оно не запустится.

docker run -m 256m myapp

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

docker run --network=none myapp

🟠Логи и диагностика
Используйте команды docker logs и docker inspect для диагностики проблем.

docker logs <container_id>
docker inspect <container_id>

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие команды порождают слой?

В Docker образ состоит из нескольких слоев, каждый из которых представляет собой изменения, внесенные в файловую систему контейнера. Эти слои создаются при выполнении команд в Dockerfile. Слои позволяют эффективно использовать кэширование и делиться образами. Основные команды, которые создают слои, включают:

🚩Команды и их влияние

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

FROM ubuntu:20.04

RUN — эта команда выполняет команды в новом слое поверх текущего образа и создает новый образ. Часто используется для установки пакетов и выполнения скриптов.

RUN apt-get update && apt-get install -y python3

COPY — эта команда копирует файлы и директории из контекста сборки (локальной файловой системы) в файловую систему контейнера. Она создает новый слой с добавленными или измененными файлами.

COPY . /app

ADD — аналогична команде COPY, но с дополнительными возможностями. Она может извлекать архивы и загружать файлы из URL. Эта команда также создает новый слой.

ADD myfile.tar.gz /app

🚩Команды, не создающие новые слои

- CMD: Определяет команду по умолчанию для выполнения при запуске контейнера.
- ENTRYPOINT: Устанавливает исполняемую команду для контейнера.
- ENV: Устанавливает переменные окружения.
- EXPOSE: Указывает на порты, которые контейнер будет слушать.
- WORKDIR: Устанавливает рабочую директорию для последующих команд.

ENV PATH=/app/bin:$PATH
EXPOSE 8080
WORKDIR /app

🚩Кэширование слоев

Docker использует кэширование для ускорения сборки образов. Если инструкция и контекст для команды не изменились, Docker использует закэшированный слой вместо создания нового.

# Если requirements.txt не изменился, этот слой будет закэширован
COPY requirements.txt /app/
RUN pip install -r /app/requirements.txt

# Остальные файлы копируются
COPY . /app

Ставь 👍 и забирай 📚 Базу знаний

🤔 Почему плохо запускать контейнер от рута?

Запуск контейнеров от имени пользователя root (рута) в Docker является обычной практикой, но это может привести к серьезным проблемам безопасности. Вот основные причины, почему это считается плохой практикой:

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

🟠Отсутствие изоляции:
Гостевая изоляция: Контейнеры должны быть изолированы от хост-системы. Запуск контейнера от имени root нарушает эту изоляцию, так как root внутри контейнера — это также root на хосте.
Повышенные привилегии: Контейнеры, запущенные от имени root, могут иметь доступ к системным ресурсам, что увеличивает риск нарушения безопасности.

🟠Нарушение принципа наименьших привилегий:
Принцип наименьших привилегий: Этот принцип гласит, что процесс должен иметь только те привилегии, которые необходимы для выполнения его задач. Запуск контейнера от имени root нарушает этот принцип, предоставляя ему избыточные права.

🚩Примеры проблем

🟠Повышение привилегий:
Если в контейнере, запущенном от имени root, найдена уязвимость, злоумышленник может использовать ее для выполнения команд с привилегиями root на хосте, что может привести к серьезным нарушениям безопасности.

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

🚩Как избежать запуска контейнеров от рута

Использование непривилегированных пользователей:
В Dockerfile можно создать пользователя с ограниченными привилегиями и переключиться на него.

FROM ubuntu:20.04
RUN useradd -m myuser
USER myuser
CMD ["myapp"]     

Использование флага --user:
При запуске контейнера можно использовать флаг --user, чтобы указать непривилегированного пользователя.

docker run --user 1000:1000 myapp

Использование механизмов безопасности Docker:
Использование профилей seccomp для ограничения системных вызовов.
Использование AppArmor или SELinux для ограничения доступа контейнеров к системным ресурсам.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какой опыт работы со stateful set?

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

🚩Основные возможности StatefulSet

🟠Уникальные идентификаторы подов:
Каждый под в StatefulSet имеет стабильный уникальный идентификатор, который сохраняется при перезапусках.
🟠Порядковый запуск и завершение:
Поды запускаются и завершаются в определенном порядке, что важно для приложений.
🟠Стабильные сетевые идентификаторы:
Каждый под имеет постоянное DNS-имя, что упрощает связь между компонентами приложения.
🟠Постоянное хранилище:
StatefulSet использует PersistentVolume (PV) для хранения данных, что обеспечивает сохранение данных при перезапусках или пересоздании подов.

🚩Пример использования

Запуск базы данных
Один из наиболее распространенных случаев использования StatefulSet — это развертывание и управление кластерами баз данных, такими как Cassandra, MySQL или PostgreSQL.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: mysql-persistent-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Объяснение полей конфигурации
🟠apiVersion: Версия API Kubernetes для объекта StatefulSet.
🟠kind: Тип объекта, в данном случае StatefulSet.
🟠metadata: Метаинформация о StatefulSet, включая имя.
🟠spec: Спецификация StatefulSet.
🟠serviceName: Имя службы, используемой для управления доступом к подам.
🟠replicas: Количество реплик, которые StatefulSet должен поддерживать.
🟠selector: Метки для выбора подов, управляемых этим StatefulSet.
🟠template: Шаблон пода, включающий метаданные и спецификацию контейнеров.

🚩Опыт использования

1⃣Развертывание кластеров баз данных:
Успешное развертывание и управление кластерами MySQL и Cassandra, обеспечивая высокую доступность и отказоустойчивость.

2⃣Поддержание состояния приложений:
Развертывание приложений, требующих сохранения состояния, таких как Zookeeper и Kafka.

3⃣Порядковое обновление подов:
Управление порядковым обновлением подов для обеспечения правильной последовательности операций и минимизации времени простоя.

4⃣Мониторинг и масштабирование:
Настройка мониторинга состояния подов и автоматическое масштабирование StatefulSet для адаптации к изменяющимся нагрузкам.

🚩Плюсы

➕Стабильность и предсказуемость: StatefulSet обеспечивает стабильные сетевые идентификаторы и уникальные имена для подов, что упрощает управление состоянием.
➕Постоянство данных: Использование PersistentVolume гарантирует, что данные сохраняются между перезапусками подов.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какой основной параметр у stateful set?

Это объект, который управляет развертыванием и масштабированием наборов подов с гарантией их уникальных идентификаторов и стабильных сетевых идентификаторов. Основной параметр, который определяет поведение StatefulSet, это `serviceName`.

🚩Основной параметр: serviceName

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

🚩Важные параметры и их функции

replicas:
Определяет количество реплик подов, которые должен поддерживать StatefulSet.

replicas: 3

selector:
Указывает метки, которые должны быть на подах, управляемых StatefulSet.

selector:
matchLabels:
app: myapp     

template:
Шаблон пода, который используется для создания новых реплик.

template:
  metadata:
    labels:
      app: myapp
  spec:
    containers:
    - name: myapp-container
      image: myapp:latest
      ports:
      - containerPort: 80

volumeClaimTemplates:
Шаблоны PersistentVolumeClaim для создания постоянных хранилищ для каждого пода.

volumeClaimTemplates:
- metadata:
    name: myapp-storage
  spec:
    accessModes: [ "ReadWriteOnce" ]
    resources:
      requests:
        storage: 1Gi

🚩Пример конфигурации StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp-statefulset
spec:
  serviceName: "myapp-service"
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:latest
        ports:
        - containerPort: 80
        volumeMounts:
        - name: myapp-storage
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: myapp-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

🚩Объяснение полей

apiVersion: Версия API Kubernetes для объекта StatefulSet.
kind: Тип объекта, в данном случае StatefulSet.
metadata: Метаинформация о StatefulSet, включая имя.
spec: Спецификация StatefulSet.
serviceName: Имя службы, связанной с StatefulSet, обеспечивающей стабильные сетевые идентификаторы.
replicas: Количество реплик подов.
selector: Метки для выбора подов.
template: Шаблон пода, включающий метаданные и спецификацию контейнеров.
volumeClaimTemplates: Шаблоны для создания PersistentVolumeClaim.

Ставь 👍 и забирай 📚 Базу знаний