vault backup: 2026-05-24 15:03:28
This commit is contained in:
Dmitry
@@ -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 - основы]]
|
||||
Reference in New Issue
Block a user