Kubernetes
Зачем миру нужен Kubernetes?
Представьте, что вы строите небоскреб. У вас есть тысячи кирпичей (контейнеров), краны (серверы), рабочие (процессы). Без грамотного архитектора и прораба всё превратится в хаос: кирпичи будут лежать криво, краны простаивать, а рабочие — спорить, кто за что отвечает.
Kubernetes (сокр. K8s) — это и есть тот самый «цифровой прораб», который автоматизирует развертывание, масштабирование и управление контейнеризированными приложениями. Но это не просто инструмент — это стандарт де-факто для оркестрации контейнеров в мире cloud-native разработки.
Почему это важно?
Когда приложения разбиваются на микросервисы (десятки или сотни независимых компонентов), ручное управление ими становится невозможным. Kubernetes решает эту проблему, превращая инфраструктуру в «самонастраивающуюся» систему, которая:
- Автоматически восстанавливает упавшие сервисы
- Масштабирует нагрузку «на лету»
- Обеспечивает непрерывную доставку кода без простоя
История: от внутренних систем Google к мировому стандарту
2014: Рождение в недрах Google
Kubernetes не появился на пустом месте. Его корни уходят в Borg — секретную систему оркестрации, которую Google использовал с 2003 года для управления своими сервисами (Поиск, Gmail, YouTube). Borg обрабатывал миллионы контейнеров ежедневно, но был закрыт для внешнего мира.
В 2014 году Google, совместно с Red Hat и Other, открыли исходный код Kubernetes (название происходит от греческого слова «κυβερνήτης» — «капитан, рулевой»). Это был не «облегченный Borg», а переработанная система с учетом опыта Google, но адаптированная для открытого использования.
2015: Передача в CNCF
Google передал Kubernetes Cloud Native Computing Foundation (CNCF) — некоммерческой организации, поддерживающей cloud-native технологии. Это был стратегический ход: чтобы система стала стандартом, она должна быть нейтральной и развиваться сообществом. Сегодня Kubernetes — самый успешный проект CNCF, с участием AWS, Microsoft, IBM и тысяч разработчиков.
Почему именно Kubernetes победил?
На момент появления существовали конкуренты (Docker Swarm, Mesos), но K8s выделялся:
- Глубокая проработка edge cases (опыт Google с миллиардами запросов)
- Декларативная модель (описывайте «что нужно», а не «как сделать»)
- Экосистема расширений (API можно расширять без изменения ядра)
Архитектура: как устроен «цифровой прораб»
Kubernetes работает по принципу control plane + data plane. Это как центр управления полетами (control plane) и самолеты (data plane).
Control Plane: «мозг» кластера
Располагается на master-нодах (хотя термин «master» устарел — теперь используется control plane node).
Состоит из:
1. API Server
Что это: Единственная точка входа для всех операций (развертывание, мониторинг).
Как работает: Принимает REST-запросы, проверяет права (через RBAC), записывает изменения в etcd.
Нюанс: Все компоненты взаимодействуют через API Server, даже сам Kubernetes. Это обеспечивает единую точку контроля и аудита.
2. etcd
Что это: Распределенное хранилище «состояния кластера» (какая нода работает, какие поды запущены).
Как работает: Хранит данные в виде ключ-значение. При изменении состояния (например, запуске нового пода) etcd рассылает события.
Нюанс: Требует нечетного числа нод (3, 5, 7) для кворума. Потеря большинства нод — катастрофа (split-brain).
3. Scheduler
Что это: «Распределитель задач». Решает, на какой ноде запустить новый под.
Как работает: Анализирует ресурсы нод (CPU, память), правила (taints/tolerations, affinity), выбирает оптимальный вариант.
Нюанс: Можно написать кастомный scheduler через API, если стандартный не подходит (например, для HPC-задач).
#Java #middle #on_request #Kubernetes
Зачем миру нужен Kubernetes?
Представьте, что вы строите небоскреб. У вас есть тысячи кирпичей (контейнеров), краны (серверы), рабочие (процессы). Без грамотного архитектора и прораба всё превратится в хаос: кирпичи будут лежать криво, краны простаивать, а рабочие — спорить, кто за что отвечает.
Kubernetes (сокр. K8s) — это и есть тот самый «цифровой прораб», который автоматизирует развертывание, масштабирование и управление контейнеризированными приложениями. Но это не просто инструмент — это стандарт де-факто для оркестрации контейнеров в мире cloud-native разработки.
Почему это важно?
Когда приложения разбиваются на микросервисы (десятки или сотни независимых компонентов), ручное управление ими становится невозможным. Kubernetes решает эту проблему, превращая инфраструктуру в «самонастраивающуюся» систему, которая:
- Автоматически восстанавливает упавшие сервисы
- Масштабирует нагрузку «на лету»
- Обеспечивает непрерывную доставку кода без простоя
История: от внутренних систем Google к мировому стандарту
2014: Рождение в недрах Google
Kubernetes не появился на пустом месте. Его корни уходят в Borg — секретную систему оркестрации, которую Google использовал с 2003 года для управления своими сервисами (Поиск, Gmail, YouTube). Borg обрабатывал миллионы контейнеров ежедневно, но был закрыт для внешнего мира.
В 2014 году Google, совместно с Red Hat и Other, открыли исходный код Kubernetes (название происходит от греческого слова «κυβερνήτης» — «капитан, рулевой»). Это был не «облегченный Borg», а переработанная система с учетом опыта Google, но адаптированная для открытого использования.
2015: Передача в CNCF
Google передал Kubernetes Cloud Native Computing Foundation (CNCF) — некоммерческой организации, поддерживающей cloud-native технологии. Это был стратегический ход: чтобы система стала стандартом, она должна быть нейтральной и развиваться сообществом. Сегодня Kubernetes — самый успешный проект CNCF, с участием AWS, Microsoft, IBM и тысяч разработчиков.
Почему именно Kubernetes победил?
На момент появления существовали конкуренты (Docker Swarm, Mesos), но K8s выделялся:
- Глубокая проработка edge cases (опыт Google с миллиардами запросов)
- Декларативная модель (описывайте «что нужно», а не «как сделать»)
- Экосистема расширений (API можно расширять без изменения ядра)
Архитектура: как устроен «цифровой прораб»
Kubernetes работает по принципу control plane + data plane. Это как центр управления полетами (control plane) и самолеты (data plane).
Control Plane: «мозг» кластера
Располагается на master-нодах (хотя термин «master» устарел — теперь используется control plane node).
Состоит из:
1. API Server
Что это: Единственная точка входа для всех операций (развертывание, мониторинг).
Как работает: Принимает REST-запросы, проверяет права (через RBAC), записывает изменения в etcd.
Нюанс: Все компоненты взаимодействуют через API Server, даже сам Kubernetes. Это обеспечивает единую точку контроля и аудита.
2. etcd
Что это: Распределенное хранилище «состояния кластера» (какая нода работает, какие поды запущены).
Как работает: Хранит данные в виде ключ-значение. При изменении состояния (например, запуске нового пода) etcd рассылает события.
Нюанс: Требует нечетного числа нод (3, 5, 7) для кворума. Потеря большинства нод — катастрофа (split-brain).
3. Scheduler
Что это: «Распределитель задач». Решает, на какой ноде запустить новый под.
Как работает: Анализирует ресурсы нод (CPU, память), правила (taints/tolerations, affinity), выбирает оптимальный вариант.
Нюанс: Можно написать кастомный scheduler через API, если стандартный не подходит (например, для HPC-задач).
#Java #middle #on_request #Kubernetes
👍5
Архитектура Kubernetes
Kubernetes работает по принципу control plane + data plane. Это как центр управления полетами (control plane) и самолеты (data plane).
Control Plane: "мозг" кластера
Располагается на master-нодах (хотя термин «master» устарел — теперь используется control plane node).
Состоит из:
1. API Server
Что это: Единственная точка входа для всех операций (развертывание, мониторинг).
Как работает: Принимает REST-запросы, проверяет права (через RBAC), записывает изменения в etcd.
Нюанс: Все компоненты взаимодействуют через API Server, даже сам Kubernetes. Это обеспечивает единую точку контроля и аудита.
2. etcd
Что это: Распределенное хранилище «состояния кластера» (какая нода работает, какие поды запущены).
Как работает: Хранит данные в виде ключ-значение. При изменении состояния (например, запуске нового пода) etcd рассылает события.
Нюанс: Требует нечетного числа нод (3, 5, 7) для кворума. Потеря большинства нод — катастрофа (split-brain).
3. Scheduler
Что это: «Распределитель задач». Решает, на какой ноде запустить новый под.
Как работает: Анализирует ресурсы нод (CPU, память), правила (taints/tolerations, affinity), выбирает оптимальный вариант.
Нюанс: Можно написать кастомный scheduler через API, если стандартный не подходит (например, для HPC-задач).
4. Controller Manager
Что это: Набор «контроллеров», следящих за состоянием кластера.
Как работает: Например, Deployment Controller следит, чтобы количество запущенных подов соответствовало желаемому. Если под падает — пересоздает его.
Нюанс: Контроллеры работают по принципу reconciliation loop: постоянно сравнивают текущее состояние с желаемым.
5. Cloud Controller Manager (опционально)
Что это: Интеграция с облачными провайдерами (AWS, GCP).
Как работает: Управляет балансировщиками нагрузки, томами, сетями через API облака.
Data Plane: "рабочие руки"
Состоит из worker nodes (рабочих нод), где запускаются приложения:
1. Kubelet
Что это: Агент на каждой ноде.
Как работает: Получает задания от API Server, запускает/останавливает контейнеры через container runtime (Docker, containerd).
Нюанс: Kubelet не перезапускает контейнеры сам — это делают контроллеры (например, через Deployment).
2. Kube-proxy
Что это: Сетевой прокси.
Как работает: Обеспечивает доступ к сервисам через iptables/IPVS. Например, при обращении к my-service перенаправляет трафик на поды.
Нюанс: В режиме IPVS используется хэширование для балансировки, что эффективнее iptables при 10k+ сервисов.
3. Container Runtime
Что это: Движок для запуска контейнеров (Docker, containerd, CRI-O).
Нюанс: Kubernetes использует CRI (Container Runtime Interface) — абстрактный API, поэтому можно менять runtime без пересборки K8s.
#Java #middle #on_request #Kubernetes
Kubernetes работает по принципу control plane + data plane. Это как центр управления полетами (control plane) и самолеты (data plane).
Control Plane: "мозг" кластера
Располагается на master-нодах (хотя термин «master» устарел — теперь используется control plane node).
Состоит из:
1. API Server
Что это: Единственная точка входа для всех операций (развертывание, мониторинг).
Как работает: Принимает REST-запросы, проверяет права (через RBAC), записывает изменения в etcd.
Нюанс: Все компоненты взаимодействуют через API Server, даже сам Kubernetes. Это обеспечивает единую точку контроля и аудита.
2. etcd
Что это: Распределенное хранилище «состояния кластера» (какая нода работает, какие поды запущены).
Как работает: Хранит данные в виде ключ-значение. При изменении состояния (например, запуске нового пода) etcd рассылает события.
Нюанс: Требует нечетного числа нод (3, 5, 7) для кворума. Потеря большинства нод — катастрофа (split-brain).
3. Scheduler
Что это: «Распределитель задач». Решает, на какой ноде запустить новый под.
Как работает: Анализирует ресурсы нод (CPU, память), правила (taints/tolerations, affinity), выбирает оптимальный вариант.
Нюанс: Можно написать кастомный scheduler через API, если стандартный не подходит (например, для HPC-задач).
4. Controller Manager
Что это: Набор «контроллеров», следящих за состоянием кластера.
Как работает: Например, Deployment Controller следит, чтобы количество запущенных подов соответствовало желаемому. Если под падает — пересоздает его.
Нюанс: Контроллеры работают по принципу reconciliation loop: постоянно сравнивают текущее состояние с желаемым.
5. Cloud Controller Manager (опционально)
Что это: Интеграция с облачными провайдерами (AWS, GCP).
Как работает: Управляет балансировщиками нагрузки, томами, сетями через API облака.
Data Plane: "рабочие руки"
Состоит из worker nodes (рабочих нод), где запускаются приложения:
1. Kubelet
Что это: Агент на каждой ноде.
Как работает: Получает задания от API Server, запускает/останавливает контейнеры через container runtime (Docker, containerd).
Нюанс: Kubelet не перезапускает контейнеры сам — это делают контроллеры (например, через Deployment).
2. Kube-proxy
Что это: Сетевой прокси.
Как работает: Обеспечивает доступ к сервисам через iptables/IPVS. Например, при обращении к my-service перенаправляет трафик на поды.
Нюанс: В режиме IPVS используется хэширование для балансировки, что эффективнее iptables при 10k+ сервисов.
3. Container Runtime
Что это: Движок для запуска контейнеров (Docker, containerd, CRI-O).
Нюанс: Kubernetes использует CRI (Container Runtime Interface) — абстрактный API, поэтому можно менять runtime без пересборки K8s.
#Java #middle #on_request #Kubernetes
👍5
Основные понятия Kubernetes
Cluster (кластер)
Что это: Группа нод (физических/виртуальных машин), управляющих приложениями.
Зачем: Объединяет ресурсы в единый «суперкомпьютер».
Нюанс: В production используют multi-zone кластеры для отказоустойчивости (ноды в разных зонах AZ).
Node (нода)
Что это: Отдельный сервер в кластере (worker или control plane).
Нюанс: Ноды могут иметь taints («отметки»), чтобы блокировать запуск подов (например, dedicated=gpu:NoSchedule).
Pod
Что это: Минимальная единица развертывания. Группа контейнеров, разделяющих сеть и томы.
Почему не один контейнер?
- Сторонние контейнеры (sidecar) для логирования, мониторинга
- Общая файловая система (например, веб-сервер + статика)
Нюанс: Pod не переживает перезагрузку ноды — его пересоздает контроллер.
Service
Что это: Абстракция для доступа к подам через стабильный IP/DNS.
Типы:
- ClusterIP (внутри кластера)
- NodePort (порт на каждой ноде)
- LoadBalancer (облачный балансировщик)
Нюанс: Service использует kube-proxy и EndpointSlice для балансировки. При 1000+ подах лучше включить EndpointSlice (уменьшает нагрузку на etcd).
Deployment
Что это: Управляет состоянием подов через ReplicaSet.
Как работает:
- Описывает желаемое состояние (например, 3 реплики)
- Обеспечивает rolling update (постепенное обновление без простоя)
- Поддерживает откат к предыдущей версии
Нюанс: Можно настроить readinessProbe (проверка готовности) и livenessProbe (проверка жизни) для корректного обновления.
ConfigMap и Secret
Что это: Хранение конфигурации и секретов.
Разница: Secret шифруется base64 (но не защищен по умолчанию — используйте etcd encryption или external secrets manager).
Нюанс: Избегайте монтирования ConfigMap как volume — при обновлении значения попадут в под с задержкой (до 1 минуты).
Как это работает: от команды до работающего приложения
1. Вы описываете желаемое состояние
Например, в YAML-манифесте Deployment указываете: replicas: 3, image: my-app:v2.
2. API Server сохраняет состояние в etcd
Все компоненты получают уведомление через watch API.
3. Scheduler назначает поды на ноды
Выбирает ноды с достаточными ресурсами, учитывая правила (например, nodeSelector: disk=ssd).
4. Kubelet запускает контейнеры
Через container runtime создает Pod с вашим приложением и sidecar-контейнерами (если есть).
5. Service направляет трафик
При обращении к my-service kube-proxy балансирует запросы между подами.
6. Контроллеры поддерживают стабильность
Если нода упала — Deployment Controller создаст новые поды на других нодах.
Ключевые особенности: почему это enterprise-ready
Декларативная модель
Вы говорите «каким должно быть приложение», а не «как его развернуть».
Например:
Kubernetes сам решает, как достичь этого состояния (запустить новые поды, убить старые).
Self-healing
- Автоматический перезапуск упавших контейнеров
- Перемещение подов с нерабочих нод
- Проверка здоровья через liveness/readiness probes
Горизонтальное масштабирование
- HPA (Horizontal Pod Autoscaler): Масштабирует поды по CPU/memory или кастомным метрикам (например, RPS)
- Cluster Autoscaler: Добавляет/удаляет ноды в облаке при нехватке ресурсов
Организация конфигурации
- Namespaces: Изоляция сред (dev, prod)
- Resource Quotas: Ограничение ресурсов на namespace
- Network Policies: Контроль трафика между подами (как firewall)
Экосистема: Kubernetes как платформа
Kubernetes — не монолит, а ядро для построения платформы.
Расширения через:
- Operators: Управление stateful-приложениями (PostgreSQL, Kafka) как нативными объектами
- CRD (Custom Resource Definitions): Добавление своих типов объектов (например, CronTab)
- Helm: Управление версиями манифестов («пакетный менеджер для K8s»)
- Istio: Сервис-меш для продвинутой маршрутизации, мониторинга
#Java #middle #on_request #Kubernetes
Cluster (кластер)
Что это: Группа нод (физических/виртуальных машин), управляющих приложениями.
Зачем: Объединяет ресурсы в единый «суперкомпьютер».
Нюанс: В production используют multi-zone кластеры для отказоустойчивости (ноды в разных зонах AZ).
Node (нода)
Что это: Отдельный сервер в кластере (worker или control plane).
Нюанс: Ноды могут иметь taints («отметки»), чтобы блокировать запуск подов (например, dedicated=gpu:NoSchedule).
Pod
Что это: Минимальная единица развертывания. Группа контейнеров, разделяющих сеть и томы.
Почему не один контейнер?
- Сторонние контейнеры (sidecar) для логирования, мониторинга
- Общая файловая система (например, веб-сервер + статика)
Нюанс: Pod не переживает перезагрузку ноды — его пересоздает контроллер.
Service
Что это: Абстракция для доступа к подам через стабильный IP/DNS.
Типы:
- ClusterIP (внутри кластера)
- NodePort (порт на каждой ноде)
- LoadBalancer (облачный балансировщик)
Нюанс: Service использует kube-proxy и EndpointSlice для балансировки. При 1000+ подах лучше включить EndpointSlice (уменьшает нагрузку на etcd).
Deployment
Что это: Управляет состоянием подов через ReplicaSet.
Как работает:
- Описывает желаемое состояние (например, 3 реплики)
- Обеспечивает rolling update (постепенное обновление без простоя)
- Поддерживает откат к предыдущей версии
Нюанс: Можно настроить readinessProbe (проверка готовности) и livenessProbe (проверка жизни) для корректного обновления.
ConfigMap и Secret
Что это: Хранение конфигурации и секретов.
Разница: Secret шифруется base64 (но не защищен по умолчанию — используйте etcd encryption или external secrets manager).
Нюанс: Избегайте монтирования ConfigMap как volume — при обновлении значения попадут в под с задержкой (до 1 минуты).
Как это работает: от команды до работающего приложения
1. Вы описываете желаемое состояние
Например, в YAML-манифесте Deployment указываете: replicas: 3, image: my-app:v2.
2. API Server сохраняет состояние в etcd
Все компоненты получают уведомление через watch API.
3. Scheduler назначает поды на ноды
Выбирает ноды с достаточными ресурсами, учитывая правила (например, nodeSelector: disk=ssd).
4. Kubelet запускает контейнеры
Через container runtime создает Pod с вашим приложением и sidecar-контейнерами (если есть).
5. Service направляет трафик
При обращении к my-service kube-proxy балансирует запросы между подами.
6. Контроллеры поддерживают стабильность
Если нода упала — Deployment Controller создаст новые поды на других нодах.
Ключевые особенности: почему это enterprise-ready
Декларативная модель
Вы говорите «каким должно быть приложение», а не «как его развернуть».
Например:
replicas: 5 # Не "запусти 5 экземпляров", а "должно быть 5 реплик"
Kubernetes сам решает, как достичь этого состояния (запустить новые поды, убить старые).
Self-healing
- Автоматический перезапуск упавших контейнеров
- Перемещение подов с нерабочих нод
- Проверка здоровья через liveness/readiness probes
Горизонтальное масштабирование
- HPA (Horizontal Pod Autoscaler): Масштабирует поды по CPU/memory или кастомным метрикам (например, RPS)
- Cluster Autoscaler: Добавляет/удаляет ноды в облаке при нехватке ресурсов
Организация конфигурации
- Namespaces: Изоляция сред (dev, prod)
- Resource Quotas: Ограничение ресурсов на namespace
- Network Policies: Контроль трафика между подами (как firewall)
Экосистема: Kubernetes как платформа
Kubernetes — не монолит, а ядро для построения платформы.
Расширения через:
- Operators: Управление stateful-приложениями (PostgreSQL, Kafka) как нативными объектами
- CRD (Custom Resource Definitions): Добавление своих типов объектов (например, CronTab)
- Helm: Управление версиями манифестов («пакетный менеджер для K8s»)
- Istio: Сервис-меш для продвинутой маршрутизации, мониторинга
#Java #middle #on_request #Kubernetes
👍6