vault backup: 2026-04-29 09:08:26

2026-04-29 09:08:26 +03:00
parent 2b98f15eba
commit 6e4ba2a9b9
4 changed files with 57 additions and 6 deletions
@@ -54,6 +54,57 @@ title: Control Plane - Плоскость управления
 ### Распространенные kube-controllers
 - **Node-controller** (поддерживает связь с узлами кластера Kubernetes, инициирует перенаправление рабочих нагрузок с вышедших из строя узлов.
 - **Replicaset-controller** (инициирует процедуру создания и функционирования сущности Replicaset).
- Endpoint-controller (выполняет создание endpoint - связи между Pod и его Service).
- Token-controller (обеспечивает создание и работу токенов для доступа к API кластера Kubernetes).
- Account-controller (обеспечивает функциональность учетных записей в Kubernetes).
+- **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]]