Из каких основных компонентов состоит архитектура Kubernetes?

А, ну вот, опять про эту вашу магию, про кубернетес! Сидишь, слушаешь, а там такие термины летят — ебать мои старые костыли, прямо волнение ебать. Ладно, разберём по полочкам, как оно там внутри устроено, а то все умные слова кидают, а суть-то где?

Представь себе, что это такая большая, охуенно сложная ферма для выращивания контейнеров. И там есть две главные банды: Царь-Горы (Control Plane) и Рабочая КОЛХОЗная Бригада (Worker Nodes). Первые командуют, вторые — пашут.

Царь-Горы (Мастер-узлы, они же Control Plane)

Это главный штаб, мозги всей операции. Могут сидеть на одной машине или раскидаться, как тараканы.

1. kube-apiserver:

   • Это, блядь, приёмная царя. Единственная дверь, в которую стучатся ВСЕ — и ты со своей командной строкой, и интерфейсы, и сами рабочие узлы. Хочешь что-то сделать в кластере? Иди нахуй к апи-серверу, других вариантов нет.
   • Даёт тебе REST API, через который ты и говоришь: «Создай», «Удали», «Обнови».

2. etcd:

   • А это, сука, священная книга истины, распределённое хранилище «ключ-значение». В нём лежит ВСЁ: как должно быть и как есть на самом деле. Единственный компонент, который помнит всё, даже если вырубить свет. Stateful, блядь, в чистом виде.

3. kube-scheduler:

   • Дежурный по распределению. Его работа — смотреть на свежесозданные поды (Pods) и решать, на какую конкретно рабочую машину их засунуть. Учитывает кучу всего: сколько там CPU, памяти, кто с кем дружит, кто кого нахуй не переносит. Настоящий таксист от мира контейнеров.

4. kube-controller-manager:

   • Надзиратель и исправитель. Запускает кучу фоновых циклов-контроллеров, которые только и делают, что смотрят: «А реальность совпадает с тем, что в священной книге (etcd) написано?». Не совпадает? Щас исправим! Контроллер узлов, реплик, сервис-аккаунтов — все они тут.

Рабочая КОЛХОЗная Бригада (Worker Nodes)

А это те самые поля, где наши контейнеры-картошки растут. На каждой такой машине три главных мудака:

1. kubelet:

   • Главный бригадир на участке. Его задача — получить от Царь-Горы (апи-сервера) план работ (PodSpec) и следить, чтобы на его узле поды запускались, работали и не дохли. Он же стучится обратно в штаб и докладывает: «У меня тут всё пиздато» или «Бля, контейнер сдох, ёпта».

2. kube-proxy:

   • Сетевой шаман и диспетчер. Отвечает за то, чтобы трафик попадал куда надо. Реализует магию Сервисов (Service). Создаёт на узле такие сетевые правила, чтобы когда ты обращаешься к какому-нибудь «сервису-nginx», запрос улетал к реальным подам, которые могут бегать с одного узла на другой. Без него был бы пиздец и бардак.

3. Container Runtime:

   • Непосредственно пахарь с лопатой. Это софтина, которая уже реально запускает контейнеры (типа containerd или CRI-O). Сам кубер с ним через специальный протокол (CRI) общается, говорит: «Запусти-ка мне этот образ, дружок».

На чём вся эта хуйня строится (Основные абстракции)

• Pod: Самая мелкая боевая единица. Это как один или несколько солдатиков (контейнеров), засунутых в один окоп (общие сеть и диски). Обычно один контейнер, но бывает и больше.
• Service: Постоянная вывеска для меняющихся подов. Поды могут дохнуть и перерождаться, их IP мелькают, а у Сервиса — стабильный IP или DNS-имя. Он знает, куда сейчас слать трафик.
• Ingress: Привратник для внешнего мира. Если Сервис — это внутренняя телефонная книга, то Ingress — это секретарь на входе, который внешние HTTP/HTTPS запросы принимает и грамотно раскидывает по внутренним сервисам.

Вот, смотри, как простой под на коленке пишется, ни хуя сложного:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-example
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80

Вот и вся, блядь, архитектура. Царь-Горы командуют, Рабочие узлы пашут, а между ними бегают эти абстракции, как мартышлюшки, связывая всё в кучу. Ёперный театр, конечно, но когда въезжаешь — вроде логично.