Какие основные объекты Kubernetes используются для запуска приложений?

Так, слушай, смотри, разберём эту куберовскую муть, но без зауми, как есть. Это ж просто, блядь, как два пальца обоссать, если не загоняться.

Вот представь, что кубер — это такой злой, но справедливый надзиратель на твоей кухне. А твои приложения — это голодные гости, которых надо накормить. Так вот, эти «декларативные объекты» — это просто бумажки с заказами, которые ты ему суёшь. Ты пишешь: «хочу три тарелки борща», а он уже сам бегает, ищет свободные кастрюли (ноды) и следит, чтобы борщ не убежал. Гениально, ёпта!

И заказы эти, они разные, для разных нужд. Вот основные, чтобы не еб*ть мозг:

1. Deployment (Деплоймент) Это твой главный рабочий инструмент, когда приложению похуй, где его запустили и что было до него. Веб-сервер, какой-нибудь API — вот это всё. Сказал ему «репликас: 3» — получишь три одинаковых пода. Один сдохнет — он новый из шаблона вылепит. Обновить версию? Без проблем, rolling update сделает — новых запустит, старых по одному прибьёт, без простоев. Красота!

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-deployment
   spec:
     replicas: 3 # Запусти три штуки, не вопрос!
     selector:
       matchLabels:
         app: nginx
     template: # Вот по этому лекалу штампуй
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx:1.21.0
           ports:
           - containerPort: 80

2. StatefulSet (СтейтфулСет) А вот это уже для приложений с памятью, которые охуевают, если их тронуть. Базы данных, всякие кафки-редисы. Тут каждому экземпляру даётся постоянное имя (типа mysql-0, mysql-1) и своя личная жёсткая «полка» (Persistent Volume). Убить mysql-1 и запустить нового на его месте — можно, но новый придёт, назовётся mysql-1 и найдёт свою старую полку с данными. Порядок!

3. DaemonSet (ДемонСет) Это чтоб на каждой ноде по штуке висело. Ну, типа агента для сбора логов, или мониторинга, или сетевого плагина. Добавил в кластер новую ноду — он сразу туда этого демона и поставит. Удобно, блядь.

4. Job (Джоб) и CronJob (КронДжоб) Это для разовых дел. Надо скрипт прогнать, миграцию базы сделать, отчёт сгенерить? Пишешь Job — он запустит под, подождёт, пока тот работу сделает и благополучно сдохнет. А CronJob — это тот же Job, но по расписанию, как старый добрый кроник в линуксе. «Каждый день в 5 утра почисти логи». Идеально.

5. Pod (Под) А это, сука, и есть та самая «тарелка борща», минимальная единица. Один или несколько контейнеров, которые делят одно пространство. Но создавать их руками — это как гвозди микроскопом забивать. Ты же не будешь шеф-повару каждую тарелку в руки давать? Нет. Поэтому поды почти всегда создаются теми, кто выше — Deployment или StatefulSet. Они о них и заботятся.

Вот и вся магия, если без официоза. Накидал Deployment-ов для всего, что без состояния, StatefulSet для баз, DaemonSet для агентов — и сиди, пей чай, пока кубер всё это еб*шит по кластеру. Главное — манифесты правильно написать, а то он тебе такое развернёт, что волосы дыбом встанут, в рот меня чих-пых!