Kubernetes простыми словами и когда он не нужен

Kubernetes — оркестратор контейнеров: ему описывают желаемое состояние, а контроллеры перезапускают и обновляют копии, пока настоящее с ним не совпадёт.

Когда контейнеров много

Docker решил задачу «одна коробка везде». Но представьте, что ваш проект вырос: десять коробок (сайт, приёмник заявок, база, очередь, почтовый сервис…) на трёх машинах. Сразу появляются вопросы, на которые Docker один не отвечает.

• Ночью упала машина. Кто заметит это и запустит её контейнеры на другой?
• Пришло много людей. Кто добавит копий сайта, а когда они разойдутся, уберёт лишние?
• Вышла новая версия. Как заменить копии одну за другой так, чтобы сайт ни на секунду не пропал?
• Один контейнер должен найти другой. Но адреса контейнеров меняются при каждом запуске. Как?

Программа, которая отвечает на эти вопросы, называется оркестратором: как дирижёр, он сам не играет, но следит, чтобы каждый музыкант вступил вовремя. Самый известный оркестратор Kubernetes (пишут K8s: «К», восемь букв и «s»). Его в 2014 году открыл Google, построив по опыту своей внутренней системы, а сегодня им занимается независимый фонд CNCF.

Идея: желаемое и настоящее

Главная мысль Kubernetes проста. Вы не запускаете копии по одной, а описываете желаемое состояние: «нужны три копии этого образа». Дальше работают контроллеры: они постоянно сравнивают желаемое с настоящим и исправляют расхождение. Копия упала, и контроллер запустит новую. Узел пропал, и копии появятся на других. Вы изменили желаемую версию, и копии будут заменяться по одной.

Попробуйте сами. Это упрощённая модель: три узла как взлётные полосы, копии как самолёты, и диспетчер, который держит их число. Уроните узел, увеличьте поток посетителей, выкатите новую версию и смотрите, как меняется картина. Под схемой маленький опрос о вашем проекте: нужен ли вам такой диспетчер.

Нужно копий: 3

Уронить узел 1Уронить узел 2Уронить узел 3 Поток посетителей Выкатить новую версию Сначала

Узел 1

Узел 2

Узел 3

Работает копий: 0 из 3. Версии: нет.

1. Нужно 3 копии, версия 1.

А вам он нужен?

Сервисов в проекте: 2 Простой допустим: нельзя вообщеминутыдо часасутки терпимо

Нагрузка очень неровная (то пусто, то наплыв) Людей, которые могут вести кластер: 1

Для действия «Главное действие»: Оркестратор не нужен. Статический хостинг или один сервер дешевле и надёжнее, и дело не в лени: у вас нет задач, которые он решает.

Проверьте себя: что делает Kubernetes, когда упал узел с двумя копиями сайта?

Контроллер замечает, что копий меньше желаемого, и запускает недостающие на оставшихся узлах. Вам не нужно ничего делать.

Словарь

Пять слов, которых хватит, чтобы читать разговоры об этом.

• Кластер: всё хозяйство вместе. Узел (node): одна машина (или виртуальная машина) кластера.
• Pod: наименьшая единица, которую запускает Kubernetes: один контейнер, а иногда несколько тесно связанных. Копия сайта это pod.
• Deployment: описание желаемого: «держи три pod’а такой версии, обновляй по одному». Именно его вы пишете чаще всего.
• Service: постоянный адрес и имя перед группой pod’ов. Pod’ы приходят и уходят, а service остаётся тем же, поэтому другие программы обращаются к нему.
• Ingress: вход снаружи: правило «запросы к example.ru/api отправлять в такой-то service». Он же обычно занимается HTTPS.

Всё это описывают в файлах YAML. Вот Deployment и Service для приёмника заявок из прошлого урока. Не нужно запоминать строки, посмотрите на смысл: сколько копий, какой образ, какой порт и как их найти.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: receiver
spec:
  replicas: 2
  selector:
    matchLabels:
      app: receiver
  template:
    metadata:
      labels:
        app: receiver
    spec:
      containers:
        - name: receiver
          image: registry.example.ru/receiver:1.0
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: receiver
spec:
  selector:
    app: receiver
  ports:
    - port: 80
      targetPort: 8080

Команда kubectl apply -f файл.yaml отдаёт это описание кластеру, а kubectl get pods показывает, что запущено.

Что оркестратор даёт

• Самовосстановление: упавшее перезапускается, потерянное с узла переезжает.
• Обновление без простоя (rolling update) и откат к предыдущей версии одной командой.
• Масштабирование: вручную (поменять число копий) или автоматически по нагрузке.
• Обнаружение сервисов и балансировка: pod’ы находят друг друга по имени, нагрузка делится между копиями.
• Настройки и секреты отдельно от образов.

Это огромная польза, когда у вас много сервисов, несколько команд и нагрузка, которая скачет. Теперь о цене.

Цена

Kubernetes сам по себе большая система. Кластер надо обновлять: новые версии выходят несколько раз в год, и каждая поддерживается ограниченное время, то есть обновления нужны регулярно. Надо настроить сеть, права доступа, хранилище данных, наблюдение (логи, метрики, оповещения), резервные копии. Ошибка в настройках легко открывает лишнее наружу. Кластер надо кому-то понимать: даже в управляемом варианте, когда провайдер (Яндекс Облако, VK Cloud, Selectel, Cloud.ru за рубежом Google, Amazon, Microsoft) ведёт «мозг» кластера за вас, остаются ваши приложения, их настройки и ответственность.

Поэтому правило, которое повторяют опытные инженеры: Kubernetes решает проблемы масштаба, и приносить его туда, где этого масштаба нет, значит купить грузовой поезд, чтобы съездить за хлебом.

Проверьте себя: почему управляемый Kubernetes провайдера не делает кластер «бесплатным» по труду?

Провайдер ведёт управляющую часть кластера, но ваши приложения, их настройки, права, обновления образов и наблюдение остаются на вас. Знать, что происходит, всё равно нужно.

Лестница, а не прыжок

Хорошая привычка: идти вверх, только когда упёрлись в реальный предел.

1. Статический хостинг. Страницы и форма-сервис. Для большинства проектов это и есть вся инфраструктура.
2. Платформа (PaaS), которая сама запускает приложение из репозитория или образа и перезапускает его, и вы не думаете о серверах.
3. Один сервер с Compose. Контейнеры сайта, приёмника и базы на одной машине, с restart: unless-stopped и копиями данных. Перезапуск после падения Docker сделает сам, а сервер у провайдера, как правило, стоит годами.
4. Управляемый запуск контейнеров у облака (без собственного кластера).
5. Kubernetes, управляемый провайдером, а для небольших установок есть и облегчённые варианты вроде k3s или Nomad. Это ступень для настоящей нагрузки: десятки сервисов, неровный трафик, жёсткие требования к простою и люди, которые поведут кластер.

В опросе под схемой те же вопросы. Покрутите: при двух сервисах и допустимом простое «до часа» оркестратор не нужен, и это правильный ответ.

Практика

Вы оцениваете свой проект так, как это делает инженер. Впишите число сервисов, допустимый простой и того, кто вёл бы кластер, затем напишите вывод («нужен» или «не нужен») с аргументами из этих цифр и главным действием проекта. Назовите дешёвый вариант без Kubernetes. И расшифруйте три слова (pod, service, deployment) на примере своего проекта: что в нём было бы чем. Это нужно и тем, кто решил «не нужен»: слова всё равно пригодятся, когда вы встретите их в чужих проектах.

Что было не так раньше

В 2010 году такой задачи почти не было: один сервер, и если он падал, админ ночью ехал в дата-центр. Когда сервисов стало много, появились свои «оркестраторы» из скриптов, у каждой команды разные, понятные только автору. Kubernetes стал общим языком, и вместе с ним в моду вошла мысль, что «настоящий» проект обязан жить в кластере. Это ошибка: большинству проектов он не нужен, и честный отказ от него не отставание, а экономия сил.