Опиши архитектуру кластера Kubernetes.

Ну что, дружище, давай разберём эту вашу магию куберов, а то смотрю, у некоторых от одного слова «кластер» уже глаза на лоб лезут, как будто им про квантовую физику рассказывают.

Представь себе, что кубер — это такой большой, налаженный завод. Не тот, где дым из труб идёт, а современный, цифровой. И в нём есть два типа персонала: управленцы в белых воротничках (Control Plane) и рабочие в касках (Worker Nodes). Если управленцы отключатся — завод встанет, потому что никто не будет отдавать приказы. Если сломается один рабочий — его нагрузку подхватят другие, завод продолжит работать. Всё просто, ёпта.

1. Управленцы (Control Plane, они же мастер-узлы): Это мозги и нервная система всего этого цирка. Их обычно несколько, чтобы если один накрылся медным тазом, остальные подхватили.

• kube-apiserver: Это главная проходная завода. Все, кто хоть что-то хочет сделать — от админа с командой kubectl до других систем — должны пройти через этого охранника. Он проверяет пропуска (валидирует запросы) и вносит все изменения в главный журнал.
• etcd: А это и есть тот самый священный главный журнал, где записано ВСЁ: кто, где работает, в каком он состоянии, какая у него зарплата (конфигурация). Потерять его — это пиздец, полный, поэтому его копий делают овердохуища.
• kube-scheduler: Отдел кадров и логистики в одном лице. Когда приходит заявка «нужна одна единица nginx», этот чувак смотрит: а на каком цехе (ноде) есть свободные станки (CPU) и место (память), чтобы этого работника поселить. Выбирает оптимальный вариант и говорит: «Вася, беги на третий узел!».
• kube-controller-manager: Это уже надзиратели, которые ходят по заводу и следят, чтобы всё было как надо. Их тут целая банда:
  • Контроллер узлов: смотрит, не отключился ли какой рабочий цех. Если да — начинает панику и перераспределяет задачи.
  • Контроллер реплик: его девиз — «сколько попросили, столько и будет». Если сказано держать 5 копий приложения, а одна упала — он немедленно создаст новую, бля буду.
  • Контроллер эндпоинтов: он как диспетчер такси. Знает, какие поды (таксисты) сейчас работают на конкретный сервис (номер вызова), и соединяет звонки (трафик) с ними.

2. Рабочие узлы (Worker Nodes): Ну а это те самые цеха, где кипит реальная работа — крутятся наши контейнеры.

• kubelet: Старший по цеху, местный царь и бог. Он получает приказы с проходной (от apiserver) и следит, чтобы в его цехе все контейнеры, которые должны работать, — работали. Не дай бог что-то упало — он сразу же стучит наверх.
• kube-proxy: Сетевой сантехник узла. Его задача — сделать так, чтобы к нашим подам-работягам можно было достучаться по сети. Он настраивает все эти правила iptables или IPVS, чтобы когда ты звонишь на внутренний номер «сервис nginx», звонок уходил на любой из живых подов, который его предоставляет. Без него была бы полная мартышлюшка с сетью.
• Container Runtime: А это уже сам станок, на котором собираются детали. Docker, containerd, CRI-O — не важно. Kubelet (старший по цеху) просто кричит ему через унифицированный интерфейс (CRI): «Запусти-ка мне этот образ nginx!», а рантайм уже делает всю грязную работу.

Вот, смотри, как выглядит простейшая заявка на одного работника (под):

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    ports:
    - containerPort: 80

Переводя на человеческий: «Друзья, нужен один под по имени nginx-pod. Внутри него пусть живёт контейнер из образа nginx:1.21. Дайте ему минимум 64 мегабайта памяти и четверть ядра CPU, но не давайте больше 128 мегов и половины ядра, а то обнаглеет. И пусть он слушает на 80-м порту, ядрёна вошь».

Ну и куда же без довесков (Addons): Сам по себе завод голый и беспомощный. Чтобы он стал полноценным, надо добавить:

• Службу DNS (CoreDNS): Чтобы поды могли находить друг друга не по IP-адресам (которые меняются), а по нормальным именам, типа my-service.default.svc.cluster.local.
• Сетевой плагин (Calico, Flannel): Чтобы все эти цеха-ноды увидели друг друга в одной сети и могли общаться. Без него каждый цех — отдельное государство, волнение ебать.
• Ingress-контроллер: Чтобы внешний трафик с интернета аккуратно заезжал на наш завод к нужным сервисам. Как швейцар на роскошной вечеринке.
• Dashboard: Ну это просто красивая web-морда, чтобы тыкать кнопочки, а не всё через консоль делать. Для тех, у кого терпения ноль ебать учить kubectl.

Вот и вся магия, чувак. Ничего сверхъестественного, просто много движущихся частей, которые нужно правильно настроить, иначе получится не завод, а пиздопроебибна.