vault backup: 2026-04-29 09:18:27
This commit is contained in:
Dmitry
@@ -1,119 +0,0 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2025-12-17
|
||||
updated: 2026-04-29
|
||||
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]]
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
status: seed
|
||||
type: concept
|
||||
tags:
|
||||
- devops
|
||||
created: 2025-12-17
|
||||
updated: 2026-04-29
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user