Опишите методы деплоя приложений в Kubernetes.

О, так, слушай, вот сидишь ты такой, и думаешь: "Как бы мне эту свою кривую микросервисную хуйню в кубер запихнуть?" Вариантов, оказывается, дохуя, и все они с подвохом, как обычно.

Ну, самый тупой и честный способ — это YAML-манифесты. Просто пишешь файлик, где объявляешь: "Хочу три пода, вот с этим образом, и чтобы порт торчал". Как будто пишешь письмо Деду Морозу, только адресовано это всё API кубера. Потом тыкаешь kubectl apply -f file.yaml и молишься, чтобы не вылезла какая-нибудь "ёперный театр" ошибка про лимиты памяти.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
  labels:
    app: my-web-app
spec:
  replicas: 3 # Хочу три штуки, блядь!
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      containers:
      - name: web
        image: my-registry/my-web-app:1.0.0 # Образ, который я вчера до пяти утра собирал
        ports:
        - containerPort: 8080 # Пусть слушает тут
        env:
        - name: DATABASE_URL
          value: "postgres://user:pass@db:5432/app" # А это, надеюсь, не продакшен пароль

Но когда приложений становится больше, чем мозгов, начинается пиздец. Тысяча этих YAML-файлов, и в каждом надо поменять версию образа. Руки отвалятся. Тут на сцену выходит Helm.

Helm — это такой менеджер пакетов, который обещает сделать из твоего бардака конфетку. Всё упаковывается в "чарты". Внутри — шаблоны, которые могут подставлять значения. Это как конструктор "Лего", только если криво собрать, всё развалится с ошибкой template: mychart/templates/deployment.yaml:15: unexpected "}" in operand. Основная магия — файл values.yaml, где ты задаёшь параметры. Хочешь для прода поменять реплик? Пожалуйста: replicaCount: 5. Для теста? replicaCount: 1. Выглядит красиво, но иногда шаблоны такие закрученные, что проще написать свой веб-сервер, чем в них разобраться.

А есть ещё Kustomize. Его философия — "ребята, давайте не будем шаблонить, а просто накладывать одни YAML на другие". Делаешь базовую конфигурацию, а потом для каждого окружения (dev, stage, prod) создаёшь "оверлей" — патч, который меняет только нужное: количество реплик, адрес базы, лимиты CPU. Никакой шаблонизации, чистая декларативность. Гениально и просто, но когда начинаешь делать оверлей на оверлей, тоже можно еб@шиться, ища, где же этот еб@ный ConfigMap переопределился.

И, конечно, вершина эволюции — CI/CD. Всё это безобразие подключается к пайплайнам в GitHub Actions, GitLab CI или, прости господи, Jenkins. Ты пушишь код в git, а дальше начинается магия: собирается образ, прогоняются тесты, и если всё ок — автоматически применяются манифесты или обновляется Helm-релиз. А если хочешь совсем шикануть, то ставишь ArgoCD или Flux по принципу GitOps. Они сидят и постоянно сравнивают, что задеплоено в кластере, с тем, что лежит в твоём git-репозитории. Если ты в репе поменял версию образа, они это видят и сами всё обновляют. Красота! Пока, конечно, он не решит, что какой-нибудь твой Job — это мусор, и не попытается его пересоздать в самый неподходящий момент. Волнение ебать каждый раз.

Короче, выбор инструмента — это как выбор оружия в апокалипсисе. Можно идти с рогаткой (чистые YAML), можно взять автомат (Helm), а можно настроить автономную систему лазерного наведения (GitOps). Главное — не прострелить себе ногу, когда начнёшь во всём этом ковыряться.