vault backup: 2026-05-24 15:03:28

2026-05-24 15:03:28 +03:00
parent 6189cfdd1c
commit 7335ca7c23
705 changed files with 18360 additions and 154 deletions
@@ -0,0 +1,46 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - containerization
+created: 2026-02-13
+updated: 2026-05-07
+title: Apache Mesos
+---
+
+# Apache Mesos
+
+- инструмент менеджмента кластерных решений по оркестрации контейнерных и не-контейнерных нагрузок.
+
+Архитектура основана на трех составляющих:
+
+![Picture background|200](Apache%20Mesos_mesos.png)
+
+1. Узлы управления (master node)
+2. Рабочие узлы (agent)
+3. Фреймворки (framework)
+
+Одновременно могут использоваться несколько фреймворки - именно они запускают рабочие нагрузки.
+
+Фреймворки состоят из:
+
+1. Планировщик фреймворка (scheduler)
+2. Исполнитель фреймворка (executor)
+
+Планировки устанавливается на всех узлах, а исполнитель выполняет задачи на рабочих узлах.
+
+Master-узлы предоставляют ресурсы используемым фреймворкам, а Scheduler фреймворка выбирает, на каких ресурсах agent-узлов Executor будет выполнять рабочее задание.
+
+Популярные фреймворки:
+
+1. Marathon (оркестрация контейнерных нагрузок) 
+2. Apache Aurora (оркестрация рабочих cron-заданий) - deprecated*
+3. Mesosphere dc/os (операционная система на базе Apache mesos и Marathon.   
+    Имеется community и enterprise-версии. ) - deprecated
+4. Mesosphere dc/os 2.0 (Kubernetes-совместимый фреймворк - nobest (не готово)
+
+Другие решения:
+[[Docker Swarm]]
+[[Kubernetes]]
+[[HashiCorp Nomad]]
@@ -0,0 +1,59 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - containerization
+  - docker
+created: 2026-02-13
+updated: 2026-05-07
+title: Docker Swarm
+---
+
+# Docker Swarm
+
+- встроенное в docker решение по обеспечению оркестрации контейнеров
+- оркестрирует только контейнеры и причем только docker
+- но весь прост в освоении
+
+![Picture background|200](Docker%20Swarm_daf199465f470.jpg)
+
+Архитектура делится на:
+
+1. Узлы управления (master)
+2. Рабочие узлы (worker)
+
+Docker Swarm не поддерживает шаблонизацию
+
+---
+
+Swarm поддерживает следующие типы сетей:
+
+- bridge
+- overlay
+- ingress (overlay с возможностью балансировки трафика)
+
+В Swarm есть поддержка **service-discovering** (обнаружение сервисов)
+
+Работа с персистентным хранением решается через Volumes.
+
+Нет автоскейлинга (масштабирования)
+
+Зато есть поддержка паттерна **rolling update** (постепенное обновление сервисов без downtime)
+
+Docker Swarm хорошо интегрируется с инструментами мониторинга.
+
+Существует встроенное хранилище секретами - docker secrets.
+
+Есть mTLS
+
+Сетевые политики (network policy) не поддерживаются.
+
+Другие решения:
+[[Apache Mesos]]
+[[Kubernetes]]
+[[HashiCorp Nomad]]
+
+## Связанные заметки
+- [[Сегментация сети]] — network policy в Swarm (не поддерживается нативно) решает ту же задачу изоляции трафика, что VLAN в физической сети
+- [[CA и NGINX]] — встроенный mTLS между нодами Swarm использует ту же PKI-инфраструктуру, что и SSL-сертификаты в NGINX
@@ -0,0 +1,40 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - containerization
+  - docker
+created: 2025-12-17
+updated: 2026-05-07
+title: Docker - Дополнительные Знания
+---
+
+# Docker - Дополнительные Знания
+
+## Запуск Контейнера С Непривилегированным Пользователем
+
+Рассмотрим пример работы с непривилегированным пользователем:
+
+- не использовать root внутри контейнера и не запускать его с повышенными привелегиями
+- создать пользователя можно сразу создать в Dockerfile
+- переключить пользователя можно с помощью директивы **USER** в Dockerfile
+
+```dockerfile
+FROM mariadb
+USER 999
+```
+
+## Rootless-mode - Podman
+
+Docker решил предпринять попытки отказаться от docker daemon и docker socket с root привилегиями и разрабатывает концепцию rootless-mode
+
+- Идея нетривиальна в реализации, так как возникают особенности установки бинарников и запуска скриптов.
+- Логичной заменой есть Podman, написанный на golang, она уже rootless и daemonless по умолчанию.
+- Podman обратно совместим в docker (в т.ч. собирает свои образы из Dockerfile)
+- Существует podman builder, позволяющий описывать образы с помощью **bash**.
+- Практически все команды докера существуют в подмане.
+
+## Связанные заметки
+- [[Super-user]] — "не использовать root внутри контейнера" — прямое применение принципа наименьших привилегий из Linux; rootless Podman реализует его на уровне демона
+- [[Проблемы дистрибутивов]] — реальный кейс: запуск Rails в контейнере как решение проблемы OpenSSL на Arch Linux
@@ -0,0 +1,91 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - containerization
+  - docker
+created: 2025-12-17
+updated: 2026-05-07
+title: Images, Dockerfile - Docker
+---
+
+# Images, Dockerfile - Docker
+
+Запуск контейнеров происходит на основе images (образов). Образы собираются с помощью Dockerfile.
+
+Основные инструкции в Dockerfile:
+
+- **FROM** - использование базового образа 
+- **RUN** - выполнение команд и создание слоя образа
+- **COPY** - копирование в контейнер файлов и папок
+- **ADD** - аналогично COPY, но с распаковкой архивов
+
+Дополнительные:
+
+- _LABEL_ - описание метаданных
+- _ENV_ - задание переменных среды
+- _CMD_ - описание команд с аргументами для выполнения при запуске контейнера
+- _WORKDIR_ - задание рабочей директории для следующей инструкции
+- _ARG_ - задание переменных для передачи во время сборки
+- _ENTRYPOINT_ - предоставление команды с аргументами для вызова во время выполнения контейнера
+- _VOLUME_ - создание точки монтирования для работы с docker volume
+- _EXPOSE_ - открытие порта в контейнере
+
+> Все эти команды создают отдельный слой (layer) для сборки контейнера
+
+## Оптимизация Образа
+
+```dockerfile
+FROM ubuntu
+
+RUN apt update
+RUN apt install python3 -y
+RUN apt install python3-dev -y
+```
+
+- Сокращение инструкций **RUN** (уменьшение количества слоев)
+
+```dockerfile
+FROM ubuntu
+
+RUN apt update
+RUN apt install python3 python3-dev -y
+```
+
+> Docker будет пересобирать только те слои, которые были изменены
+
+```dockerfile
+FROM ubuntu
+
+RUN apt update && \
+	apt install python3 python3-dev -y
+```
+
+- Удаление кеша пакетных менеджеров
+
+```dockerfile
+RUN apt update && \
+	apt install python3 python3-dev -y \
+	rm -rf /var/lib/apt/lists/*
+```
+
+- Удаление файлов в той же инструкции, где их создавали
+- Инструкции, которые предположительно будут часто изменяться, ставить ниже остальных
+- Сокращение количество инструкций **COPY**
+
+```dockerfile
+RUN apt update && \
+	apt install python3 python3-dev -y \
+	rm -rf /var/lib/apt/lists/*
+
+COPY file1 file2 file3 ./dir
+```
+
+- Использование легковесных базовых образов, где есть такая возможность
+
+![](Images,%20Dockerfile%20-%20Docke.png)
+
+## Связанные заметки
+- [[Environment Variables]] — инструкция `ENV` в Dockerfile устанавливает переменные окружения внутри контейнера; это расширение того же механизма Linux env vars
+- [[Volume - Docker]] — инструкция `VOLUME` в Dockerfile объявляет точки монтирования для Docker Volumes
@@ -0,0 +1,31 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - containerization
+  - docker
+created: 2025-12-17
+updated: 2026-05-07
+title: Multistaging - Docker
+---
+
+# Multistaging - Docker
+
+При сборке docker-образов мы можем использовать механизм многоэтапной сборки - Multistaging.
+
+При использовании multistaging мы разделяем процедуру сборки на несколько этапов, обозначая их метками.
+
+![](Multistaging%20-%20Docker_imag.png)
+
+**Использование механизма Multistaging позволяет:**
+
+- Собирать легковесные образы.
+- Сократить время сборки образов и запуска на основе контейнеров.
+- Повысить производительность работы контейнеров.
+- Переиспользовать вспомогательные образы из промежуточных этапов.
+- Сократить поверхность атаки на наши контейнеры для потенциального  
+    злоумышленника.
+
+## Связанные заметки
+- [[Основы - Docker]]
@@ -0,0 +1,83 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - containerization
+  - docker
+created: 2025-12-17
+updated: 2026-05-07
+title: Network Drivers - Docker
+---
+
+# Network Drivers - Docker
+
+При работе с docker возникает необходимость обеспечить работу контейнеров в сети:
+
+- настройка правил маршрутизации (iptables)
+- формирование пакетов
+- инкапсуляция пакетов
+- шифрование и безопасность
+
+Для этого используются Network Drivers
+
+Сетевых драйверов поддерживаются несколько вариаций, каждый из них способен обеспечить все основные функции:
+
+- bridge (мост)
+- host
+- overlay
+- macvlan
+- none
+- 3rd-party plugins
+
+**Bridge**
+
+Объединение контейнеров в bridge-сеть:
+
+- контейнеры обьеденены в сеть
+- контейнеры в сети имеют связь друг с другом
+- контейнеры из другой сети не имеют сетевой связности
+- используется в docker **по умолчанию**
+
+**Host**
+
+Использует сеть хоста (удаляется сетевая изоляция)
+
+- удаляет сетевую изоляцию между контейнером и хостом
+- возможны проблемы с занятым портов, сетевыми ограничениями хостовой сети (поддерживается только в Linux)
+
+**Overlay**
+
+Создание сети для объединения контейнеров на разных хостах путем создания оверлейной сети
+
+- не поддерживает шифрование на win-хостах
+
+**MacVLAN**
+
+Работа с контейнерами, как с физическими устройствами
+
+- присваивает каждому контейнеру в сети физический MAC-адрес
+- позволяет обращаться к контейнеру как к настоящему устройству
+- поддерживается только в Linux
+
+**None**
+
+Отключение всех сетей в контейнере
+
+- может быть использован для изоляции контейнера
+
+## Работа С Bridge-сетями
+
+Docker по умолчанию использует bridge-сеть, так как он позволяет добиться большей изоляции от внешних сетей хоста.
+
+Контейнеры внутри одного "бриджа" не имеют доступа к другим из других бридж сетей.
+
+Если нам нужна гибкая настройка сети внутри самого контейнера, потребуются доп. **capabilities** (например, **CAP_NET_ADMIN**)
+
+В качестве альтернативы можно рассмотреть CNI-плагины (сторонние - 3rd-party)
+
+## Связанные заметки
+- [[Модель OSI]] — bridge/overlay/macvlan реализуют концепции L2/L3 из модели OSI; iptables работает на L3/L4
+- [[VLAN - Base]] — bridge-изоляция контейнеров ≈ VLAN-изоляция устройств: разные бриджи не видят друг друга, как разные VLAN
+- [[VPN]] — overlay-сеть реализует принцип VPN: инкапсуляция трафика одной сети поверх другой
+- [[Сегментация сети]] — изоляция контейнеров по bridge-сетям = программная сегментация сети
@@ -0,0 +1,60 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - containerization
+  - docker
+created: 2025-12-17
+updated: 2026-05-07
+title: Storage Drivers - Docker
+---
+
+# Storage Drivers - Docker
+
+	Для работы с данными в контейнере имеется специальный контейнерный слой (**container layer**). Он появляется только в момент запуска контейнера, для работы с данными.
+
+![](1_Storage%20Drivers%20-%20Docker_i.png)
+
+Для работы с данными в контейнерном слое и работы со слоями образа _docker_ задействует _**драйверы хранилища**_ **(storage drivers).**
+
+Доступны в Docker 6 SD:
+
+![](Storage%20Drivers%20-%20Docker_i.png)
+
+## Block Level (блочные хранилища)
+
+- распределяют данные на блоки одинакового размеры по оборудованию
+- не зависит от пути к данным
+- быстрое получение
+
+Примеры: ZFS, DeviceMapper
+
+## File Level (файловые хранилища)
+
+- данные хранятся единым фрагментов
+- присутсвует иерархия директорий
+- доступ к файлу зависит от единственного пути
+- наиболее распространенный способ хранения данных
+
+Примеры: AUFS, Overlay, **Overlay2** (по умолчанию)
+
+## Object Level (объектно-ориентированные хранилища)
+
+- данные распределяются по оборудованию по частям
+- связывает объекты данных с их метадатой
+- объекты могут быть только перезаписаны (изменять нельзя)
+- для доступа требуется реализация API интерфейса
+
+По умолчанию, в Docker используется Overlay2, изменить это можно в `/etc/docker/daemon.json`
+
+**Backing Filesystem**
+
+Резервная файловая система, в которой расположен `/var/lib/docker`
+
+Для работы storage driver требуется **совместимая** backing filesystem.
+
+![](2_Storage%20Drivers%20-%20Docker_i.png)
+
+## Связанные заметки
+- [[Основы - Docker]]
@@ -0,0 +1,62 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - containerization
+  - docker
+created: 2025-12-17
+updated: 2026-05-07
+title: Volume - Docker
+---
+
+# Volume - Docker
+**Некоторые данные стоит хранить независимо от контейнера, для этого существует понятие Volume.**
+
+Стоит так хранить: БД, логи, конфиги, артефакты, настройки, …
+
+Для постоянного или персистентного хранения используются Docker Volume. Это буквально монтирование хостовой директории внутрь контейнера, для работы с данными контейнера напрямую.
+
+Возможности Docker Volumes:
+
+1. Выгрузка данных контейнера на постоянное хранение
+2. Работа в подмонтированных каталогах с интенсивной записью данных
+3. Совместное использование данных несколькими контейнерами
+
+Docker volumes создают тома, которые монтируются в контейнер.
+По умолчанию тома docker volumes создаются в каталоге `/var/lib/docker/volumes/`
+
+![](Volume%20-%20Docker_image.png)
+
+## Типы Volumes
+
+1. **Host** DV:
+    `docker run -v /home/mount/data:/var/lib/mysql/data`
+    При запуске контейнера, мы пробрасываем конкретный каталог на хосте в конкретный каталог в контейнере
+    (есть опция флагов, для редактирования прав доступа)
+2. **Anonymous** DV:
+    `docker run -v /var/lib/mysql/data`
+    При таком подходе, Volume создастся в `/var/lib/docker/volumes`
+3. **Names** DV:
+    `docker run -v name:/var/lib/mysql/data`
+    Аналогично второму варианту, Volume создается в директории по умолчанию, но ему присваивается метка `name`, которую можно переиспользовать.
+
+## Организация Доступа К Файлам В Docker Volumes
+
+По умолчанию, uid/gid внутри контейнера и на хосте идентичны, поэтому владелец/группа и права доступа внутри смонтированного каталога будут эквиванлентны.
+
+Изменить данные поведение поможет фича под названием "userns-remap" - она позволит соотнести uid/gid контейнера к другим uid/gid хоста
+
+Проблема в том, что по умолчанию, в volume владелец root - что не очень хорошо.
+
+Для управления этой фичей, нужно отредактировать конфигурацию по пути `/etc/docker/daemon.json` 
+
+```bash
+{
+	"userns-remap": "<username>"
+}
+```
+
+## Связанные заметки
+- [[File Permissions]] — uid/gid маппинг в Docker Volumes напрямую зависит от Linux-прав доступа; проблема "владелец root по умолчанию" решается через chmod/chown
+- [[Active Storage]] — Active Storage в Rails хранит файлы вне БД; в Docker-деплое они должны персистироваться через Volume, иначе теряются при перезапуске контейнера
@@ -0,0 +1,21 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - containerization
+  - docker
+created: 2025-12-17
+updated: 2026-05-07
+title: Основы - Docker
+---
+
+# Основы - Docker
+
+## Виртуализация
+
+**Виртуализация** - это набор вычислительных ресурсов, обеспечивающих логическую изоляцию процессов, выполняющихся на одном физ.хосте.
+
+## Связанные заметки
+- [[Storage Drivers - Docker]]
+- [[Multistaging - Docker]]
@@ -0,0 +1,51 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - containerization
+created: 2026-02-13
+updated: 2026-05-07
+title: HashiCorp Nomad
+---
+
+# HashiCorp Nomad
+
+**nomad** - фреймворк для построения кластерных решений, поддерживает не только контейнерные нагрузки, но и не-контейнерные. Существуют платные и бесплатные версии продукта.
+![Picture background|200](HashiCorp%20Nomad_nomad.svg)
+Существует возможность установки расширений:
+
+- consul (service-discovering)
+- vault (secret management)
+- prometheus, grafana, ELK (monitoring, logging, etc)
+- и т.д.
+
+Установка nomad проста, но с увеличением расширений _сложность администрирования возрастает_.
+
+Архитектура представляет собой совокупность управляющих (server) и управляемых (clients) узлов.
+
+В Nomad используется концепция "job-tasks", где task - это атомарная единица работы, выполняемая выполняемая тем или иным драйвером:
+
+- docker 
+- qemu
+- java
+- etc
+
+---
+
+Nomad не поддерживает использование шаблонизаторов.
+
+Для работы с манифестами nomad использует проприетарный язык HCL с ограниченной возможностью двусторонней конвертации HCL в json и yml.
+
+Nomad поддерживает использование CNI-плагинов, и имеется поддержка CSI (Container Storage Interface)
+
+Nomad поддерживает горизонтальное и вертикальное скалирование:
+
+1. Горизонтальное - создание новых инстансов для балансировки нагрузки.
+2. Вертикальное - увеличение ресурсов у уже существующих инстансов.
+3. Кластерное скалирование - увеличение рабочих и управляющих узлов.
+
+Другие решения:
+[[Docker Swarm]]
+[[Kubernetes]]
+[[Apache Mesos]]
@@ -0,0 +1,120 @@
+---
+status: processing
+type: concept
+tags:
+  - devops
+  - kubernetes
+created: 2025-12-17
+updated: 2026-05-07
+title: Control Plane - Плоскость управления
+---
+
+# Control Plane - Плоскость управления
+
+В k8s плоскостью управления выступают master-узлы, они контролируют работу worker-узлов и следят за здоровьем системы, в целом.
+
+К основным компонентам Control plane относятся:
+1) Etcd
+2) Kube-api-server
+3) Kube-scheduler
+4) Kube-controller-manager
+5) Cloud-controller-manager
+
+![[Pasted image 20260429090040.png|400]]
+
+## Etcd
+
+**Etcd** — Opensource *key-value* хранилище, использующее алгоритм консенсуса [[Алгоритм консенсуса raft|raft]] для обеспечения надежного способа хранения данных.
+
+- Рекомендуемое Kubernetes хранилище конфигурации кластера.
+- Единственный *Stateful*-компонент кластера Kubernetes.
+- Инсталлируется на каждую Master node.
+- Для выбора лидера используется алгоритм Raft.
+
+## Kube-api-server
+
+**Kube-api-server** — основной компонент для взаимодействия с кластером и обязательный посредник между всеми компонентами Kubernetes в Data и Control plane.
+
+- Использует REST API интерфейс.
+- Является точкой входа в кластер.
+- Обязательный участник любого взаимодействия между компонентами кластера.
+- Обеспечивает разграничение прав доступа к содержимому кластера (авторизация и аутентификация).
+- *Stateless*-компонент.
+- Инсталлируется на *каждую* Master node.
+- Выбор лидера происходит по алгоритму [[Алгоритм выбора лидера Lease|lease]].
+
+## Kube-controller-manager
+**Kube-controller-manager** — компонент, ответственный за работу множества kube-controllers.
+
+- Является *связующим* звеном при взаимодействии Kube-controllers и отвечает за их работу.
+- Отвечает за *сборку мусора* (Garbage collecting) в кластере Kubernetes.
+- *Stateless*-компонент.
+- Инсталлируется на каждую Master node.
+- Выбор лидера происходит по алгоритму [[Алгоритм выбора лидера Lease|lease]].
+
+### Распространенные kube-controllers
+- **Node-controller** (поддерживает связь с узлами кластера Kubernetes, инициирует перенаправление рабочих нагрузок с вышедших из строя узлов.
+- **Replicaset-controller** (инициирует процедуру создания и функционирования сущности Replicaset).
+- **Endpoint-controller** (выполняет создание endpoint - связи между Pod и его Service).
+- **Token-controller** (обеспечивает создание и работу токенов для доступа к API кластера Kubernetes).
+- **Account-controller** (обеспечивает функциональность учетных записей в Kubernetes).
+
+### Garbage collecting
+
+Обязанности за сборку мусора (Garbage collecting) в кластере Kubernetes также возложены на компонент *Kube-controller-manager*.
+
+Примером сборки мусора может выступать отслеживание и удаление старых версий наборов репликаций развертываний (Replicaset).
+
+Если в кластере превышен лимит старых ревизий Replicaset — наиболее старая ревизия становится *мусором* и ее нужно удалить.
+
+## Cloud-controller-manadger
+
+**Cloud-controller-manager** — компонент, ответственный за работу множества Cloud-controllers.
+
+> Не реализован в Kubernetes по умолчанию. Самостоятельная реализация привлекательна для вендоров, желающих предоставлять Kubernetes как облачную услугу.
+
+- Является связующим звеном при взаимодействии Cloud-controllers и отвечает за их работу.
+- Cloud-controller-manager, как и сами Cloud-controllers не реализованы по умолчанию.
+
+## Kube-scheduler
+
+**Kube-scheduler** — компонент, ответственный за выбор подходящих узлов Data plane для запуска рабочих нагрузок.
+
+При принятии решения руководствуется следующими факторами: *Requests/Limits*, *QoS*, *Affinity/Anti-affinity rules*, *Priority class/Preemption policy*
+
+- Отвечает за распределение рабочих нагрузок на узлы Data plane с учетом *определенных факторов*.
+- *Stateless*-компонент.
+- Инсталлируется на каждую Master node.
+- Выбор лидера происходит по алгоритму [[Алгоритм выбора лидера Lease|lease]].
+
+Kube-scheduler принимает к сведению имеющиеся у развертываний указания по минимальным и максимальным требованиям к вычислительным ресурсам (*Requests* и *Limits*).
+
+**Requests:** Минимальный объем вычислительной мощности (Cpu, Ram), необходимый для функционирования рабочей нагрузки.
+
+**Limits:** Максимальный объем вычислительных ресурсов, выделяемый рабочей нагрузке.
+
+![[Pasted image 20260429090719.png|200]]
+
+Kube-scheduler руководствуется присвоенным рабочей нагрузке значением QoS (Quality of Service).
+
+**В зависимости от указанных в развертывании Requests и Limits,** **уровень обслуживания (QoS) может принимать следующие** **значения:**
+
+- *BestEffort* (Requests и Limits не указаны вовсе).
+- *Burstable* (хотя бы для одного контейнера в Pod указаны requests по Cpu или Ram).
+- *Guaranteed* (все контейнеры в Pod имеют одинаковые Requests и Limits).
+
+**Affinity/Anti-affinity rules:**
+
+Kube-scheduler также руководствуется применяемыми к рабочей нагрузке Affinity/Anti-affinity rules.
+
+Правила Affinity и Anti-affinity описываются в спецификации развертывания и позволяют влиять на решение Kube-scheduler о направлении рабочих нагрузок на узлы кластера за счет расширения типов возможных ограничений.
+
+![[Pasted image 20260429090816.png|400]]
+
+**Политика вытеснения:**
+
+В критических ситуациях Kube-scheduler может прибегнуть к процедуре вынужденного *выселения* (*переселения*) рабочих нагрузок с низким приоритетом (Priority class) в пользу рабочих нагрузок с *высоким* приоритетом, руководствуясь "*политикой вытеснения*" (Preemption policy).
+
+Данное поведение характерно для ситуаций, при которых узел с рабочей нагрузкой высокого приоритета выходит из строя — в таком случае, во избежание Downtime *высокоприоритетного* развертывания, оно будет отправлено на узел, имеющий низко приоритетную нагрузку (и она будет выселена принудительно).
+
+![[Pasted image 20260429090930.png]]
@@ -0,0 +1,46 @@
+---
+status: processing
+type: concept
+tags:
+  - devops
+  - kubernetes
+created: 2025-12-17
+updated: 2026-05-07
+title: Data Plane - Плоскость данных
+---
+
+# Data Plane - Плоскость данных
+К плоскости данных (Data plane) кластера Kubernetes относят рабочие узлы (Workers), на которых запускаются рабочие нагрузки.
+
+Компоненты Kubelet и Kube-proxy устанавливаются как на узлы управления (Masters), так и на рабочие узлы (Workers), обеспечивая работоспособность рабочих нагрузок в Data-plane и отвечая за их связь с плоскостью управления (Control plane).
+
+![[Pasted image 20260429085656.png]]
+## Kubelet
+**kubelet** - агент на *каждом* узле кластера. 
+- Работает как процесс системы, а не контейнер;
+- поддержка *любой* k8s-совместимой системы оркестрации (CRI - docker, podman);
+- запускает контейнеры с *рабочими* нагрузками;
+- обеспечение проверок (**startup**, **readines**, **liveness probes**).
+
+Т.е. это агент k8s непосредственно на клиенте (как zabbix-agent, например), он взаимодействует с системой worker-node (и master, тоже)
+
+## Проверки kubelet
+1) **startup probe** - применяется первой для определения факта запуска контейнера;
+   ![[Pasted image 20260428175708.png|200]]
+2) **readiness probe** - проверка готовности развернутого в контейнере приложения принимать и обрабатывать рабочую нагрузку;
+   ![[Pasted image 20260428175716.png|200]]
+3) **liveness probe** - периодическая проверка запущенного приложения.
+   ![[Pasted image 20260428175720.png|200]]
+
+## Kube-proxy
+**kube-proxy** - компонент, отвечающий за *сетевое проксирование* и обеспечивающий *базовые* сетевые правила на узлах управления (Masters) и узлах данных (Workers).
+
+- Управляет основными сетевыми правилами на узлах кластера Kubernetes
+- Запускается в контейнере.
+- Может делегировать часть своих функций сетевым плагинам (CNI).
+
+### Интерфейсы универсального взаимодействия (плагины)
+1) **CRI (Container Runtime Interface)** — интерфейс *коммуникации* между компонентом *Kubelet* и используемой kubernetes-совместимой *системой контейнеризации*.
+2) **CNI (Container Network Interface)** — интерфейс для выполнения сетевых функций кластера Kubernetes-совместимыми сетевыми плагинами (Network plugins).
+3) **CSI (Container Storage Interface)** — интерфейс обеспечения необходимых действий над персистентным хранением данных рабочих нагрузок кластера kubernetes-совместимыми Volume-drivers.
+
@@ -0,0 +1,57 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - kubernetes
+  - container
+created: 2025-12-17
+updated: 2026-05-07
+title: Deployment и ReplicaSet
+---
+
+# Deployment и ReplicaSet
+
+Два ключевых контроллера k8s, отвечающих за развёртывание приложений.
+
+## Deployment
+
+**Deployment-controller** управляет декларативным описанием приложения для его развёртывания и обновления.
+
+Способен создать Deployment из образа или из готового манифеста:
+
+```sh
+kubectl create deployment mariadb --image=mariadb:4.0
+kubectl apply -f nginx-deployment-manifest.yaml
+```
+
+Deployment работает только с **Pods** и **ReplicaSets**.
+
+## ReplicaSet
+
+**ReplicaSet** — сущность k8s, обеспечивающая поддержку стабильного набора реплик Pod в любой момент времени.
+
+Приложение = Pod (объединение контейнеров). ReplicaSet управляет множеством таких Pod.
+
+## Service
+
+Для связи Pod с другими Pod и внешним миром используется **Service**.
+
+Pod связывается с Service через **Endpoint** (управляет Endpoint-controller).
+
+Создание Service:
+
+```bash
+kubectl expose deployment mariadb --port=8080
+kubectl apply -f nginx-service-manifest.yaml
+```
+
+## Возможности связки Deployment + ReplicaSet
+
+| Операция | Описание |
+|---|---|
+| Rolling update | Обновление без downtime |
+| Rollback | Откат текущего обновления |
+| Revision | Просмотр истории обновлений |
+| Rollback to revision | Откат до конкретной ревизии |
+| Scaling | Масштабирование приложения |
@@ -0,0 +1,42 @@
+---
+status: stable
+type: moc
+tags:
+  - devops
+  - container
+  - kubernetes
+created: 2026-02-13
+updated: 2026-05-07
+title: Kubernetes
+---
+
+# Kubernetes
+
+K8s — система оркестрации контейнеров. Кластер состоит из двух плоскостей:
+
+- **[[Control Plane - Плоскость управления]]** — master-узлы: etcd, kube-api-server, kube-scheduler, kube-controller-manager, cloud-controller-manager
+- **[[Data Plane - Плоскость данных]]** — worker-узлы: kubelet, kube-proxy, CRI/CNI/CSI
+
+![[Pasted image 20260429091836.png]]
+## Рабочие нагрузки
+
+- [[Deployment и ReplicaSet]] — развёртывание, rolling update, rollback, scaling
+
+## Хранение данных
+
+- [[PV, PVC]] — персистентное хранилище: Persistent Volume и Persistent Volume Claim
+
+
+
+## Альтернативные решения
+
+- [[Docker Swarm]]
+- [[Apache Mesos]]
+- [[HashiCorp Nomad]]
+
+## Источники
+
+[[Devops вводный 9 урок. Введение в Kubernetes. Компоненты control и Data plane.pdf]]
+
+## Связанные заметки
+- [[Шаблонизатор Helm]]
@@ -0,0 +1,37 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - kubernetes
+  - storage
+created: 2025-12-17
+updated: 2026-05-07
+title: PV, PVC
+---
+
+# PV, PVC
+
+Сущности k8s для персистентного хранения данных.
+
+## Persistent Volume (PV)
+
+**PV** — отражение реального раздела на диске в терминах k8s. Такой же ресурс кластера, как Master или Worker node.
+
+- Не зависит от namespace
+- Создаётся вручную (Manifest) или автоматически (Provisioning)
+
+## Persistent Volume Claim (PVC)
+
+**PVC** — запрос приложения на подключение к PV.
+
+- Зависит от namespace
+- Описывает требования к хранилищу (размер, класс, режим доступа)
+
+## Схема подключения
+
+```
+Pod → PVC → PV → физический диск
+```
+
+**Deployment** может содержать ссылку на PVC — тогда при развёртывании Pod автоматически получает доступ к нужному хранилищу.
@@ -0,0 +1,19 @@
+---
+status: stable
+type: concept
+tags:
+  - k8s
+  - devops
+  - kubernetes
+created: 2025-12-17
+updated: 2026-05-07
+title: Алгоритм выбора лидера Lease
+---
+
+# Алгоритм выбора лидера Lease
+
+ Алгоритм выбора лидирующего узла в распределнных системах, позволяющий сохранять консистентность данных
+ 
+**Суть проста**: узел, который первым запишет себя в хранилище конфигурации кластера, как лидер, тот и станет лидером
+
+Если лидер перестал выполнять свои функции, то борьба за место лидера по **такому же принципу**.
@@ -0,0 +1,28 @@
+---
+status: stable
+type: concept
+tags:
+  - devops
+  - kubernetes
+created: 2025-12-17
+updated: 2026-05-07
+title: Алгоритм консенсуса raft
+---
+
+# Алгоритм консенсуса raft
+
+**Raft** — алгоритм консенсуса, применяющийся в распределенных системах, и обеспечивающий безопасную и согласованную репликацию данных между всеми участниками.
+
+Состоит из двух фаз:
+1) Выбор лидера (**leader election**)
+2) Репликация данных (**log replication**)
+
+Каждый участник в любой момент времени находится только в одном состоянии:
+1) Лидер (**leader**) - только один;
+2) Кандидаты в лидеры (**candidate**);
+3) Ведомый (**follower**).
+
+*Raft* в фазе выбора лидера опирается на понятие кворума (**quorum**) - большинства. 
+Из-за этого, в частности, есть рекомендация: *количество master-node должно быть нечетным*.
+
+Визуализация алгоритма консенсуса Raft: http://thesecretlivesofdata.com/raft/
@@ -0,0 +1,92 @@
+---
+status: seed
+type: guide
+tags:
+  - devops
+  - kubernetes
+  - helm
+created: 2025-12-17
+updated: 2026-05-07
+title: Шаблонизатор Helm
+---
+
+# Шаблонизатор Helm
+
+**Helm** — менеджер пакетов и шаблонизатор для развёртывания приложений в [[Kubernetes]].
+
+Helm помогает описывать, устанавливать, обновлять и удалять приложения через готовые или собственные Helm charts.
+
+## Зачем нужен Helm
+
+Helm позволяет:
+
+- искать готовые charts;
+- устанавливать приложения в Kubernetes;
+- обновлять релизы;
+- удалять приложения;
+- переиспользовать шаблоны манифестов;
+- параметризовать установку через values.
+
+## Helm chart
+
+**Helm chart** — пакет с шаблонами Kubernetes-манифестов, значениями по умолчанию и метаданными приложения.
+
+Chart можно:
+
+- найти в публичном chart-репозитории;
+- создать самостоятельно под своё приложение.
+
+## Базовый workflow
+
+Добавить chart-репозиторий:
+
+```sh
+helm repo add bitnami https://charts.bitnami.com/bitnami
+```
+
+Обновить индекс репозиториев:
+
+```sh
+helm repo update
+```
+
+Найти chart:
+
+```sh
+helm search repo bitnami
+```
+
+Установить приложение:
+
+```sh
+helm install my-mysql bitnami/mysql
+```
+
+Посмотреть доступные параметры:
+
+```sh
+helm show values istio/base
+```
+
+Установить или обновить значения через `--set`:
+
+```sh
+helm install istiod istio/istiod --set requests.cpu=300m
+```
+
+Посмотреть установленные релизы:
+
+```sh
+helm list
+```
+
+Обновить релиз:
+
+```sh
+helm upgrade istiod istio/istiod --set requests.cpu=600m
+```
+
+## Связанные заметки
+
+- [[Kubernetes]]
+- [[DevOps - основы]]