vault backup: 2026-04-29 09:18:27
This commit is contained in:
@@ -0,0 +1,119 @@
|
||||
---
|
||||
status: processing
|
||||
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]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
status: processing
|
||||
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.
|
||||
|
||||
@@ -1,53 +1,29 @@
|
||||
---
|
||||
status: stable
|
||||
type: concept
|
||||
type: moc
|
||||
tags:
|
||||
- devops
|
||||
- container
|
||||
created: 2026-02-13
|
||||
updated: 2026-04-28
|
||||
updated: 2026-04-29
|
||||
title: Kubernetes
|
||||
---
|
||||
|
||||
# Kubernetes
|
||||
K8s состоит из двух основных компонент:
|
||||
1) **Control Plane** - плоскость управления
|
||||
2) **Data Plane** - плоскость данных
|
||||
|
||||
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 20251220211253.png|600]]
|
||||
|
||||
## Компоненты Control Plane
|
||||
1) etcd - open-source key-value хранилище, использующее алгоритм консенсуса raft для обеспечения надежного способа хранения данных.
|
||||
В k8s используется для хранения конфигурации всего кластера.
|
||||
|
||||
2) kube-api-server - основной компонент для взаимодействия с кластером и обязательный посредник между всем компонентами k8s в data и control plane
|
||||
- используется REST API
|
||||
- является точкой входа в кластер
|
||||
- обязательный участник любого взаимодействия с компонентами кластера
|
||||
- обеспечение разграничивания прав доступа к содержимому кластера (авторизация и аутентификация)
|
||||
- stateless-компонент
|
||||
- установка на каждую master-ноду
|
||||
- выбор лидера происходит по алгоритму **[[Алгоритм выбора лидера Lease|lease]]**
|
||||
## Альтернативные решения
|
||||
|
||||
3) kube-controller-manager - компонент, ответственный за работу контроллеров.
|
||||
- связывает kube-controller и отвечает за их работу
|
||||
- сборка мусора
|
||||
- stateless
|
||||
- на каждой master-ноде
|
||||
- выбор лидера аналогично по алгоритму [[Алгоритм выбора лидера Lease|lease]]
|
||||
- [[Docker Swarm]]
|
||||
- [[Apache Mesos]]
|
||||
- [[HashiCorp Nomad]]
|
||||
|
||||
Существующие kube-controllers:
|
||||
- node-controller - поддержка связи с узлами кластера, инициализация перенаправления рабочих нагрузок с вышедший из строя узлов.
|
||||
- replicaset-c. - инициализация процедуры создания и функционирования сущности [[ReplicaSet]]
|
||||
- endpoint-c.
|
||||
- token-c.
|
||||
- account-c.
|
||||
## Источники
|
||||
|
||||
|
||||
|
||||
Конспект от MA: [[Devops вводный 9 урок. Введение в Kubernetes. Компоненты control и Data plane.pdf]]
|
||||
|
||||
Другие решения:
|
||||
[[Docker Swarm]]
|
||||
[[Apache Mesos]]
|
||||
[[HashiCorp Nomad]]
|
||||
[[Devops вводный 9 урок. Введение в Kubernetes. Компоненты control и Data plane.pdf]]
|
||||
|
||||
Reference in New Issue
Block a user