Приходилось ли вам проектировать Kubernetes-манифесты (Deployments, Services и т.д.)?

А, ну это ж про кубер, да? Ну, проектировал я эти ваши ресурсы, чтобы приложения разворачивать. Сейчас разжую, как для дебила, но ты не обижайся, просто чтоб понятно было.

Смотри, главное — не накосячить с самого начала. Вот тебе святые заповеди, нарушишь — получишь пизды от продакшена.

• Stateless vs Stateful: Это как отличить холостяка от семьянина. Если твоему сервису похуй, где он живёт, и у него чемоданов нет — это Deployment. Бери его, он лёгкий на подъём. А если у него своя база данных, своё постоянное хранилище, как у жены — своя шуба в гардеробе, то это уже StatefulSet. С ним возни больше, зато порядок в данных.
• Конфигурация и секреты: Боже упаси тебя хардкодить настройки или, ёпта, пароли прямо в образ! Это уровень дебила 80 lvl. Всё, что можно поменять без пересборки — тащи в ConfigMap. А всё, что пахнет тайной (ключи, пароли, токены) — сразу в Secret. Да, они base64, а не шифрование, но хоть так, блядь.
• Пробы здоровья: Это как стучать соседу в стенку: «Ты живой?». livenessProbe — это грубый стук. Не ответил — считай, умер, кубер тебя перезапустит. А readinessProbe — это вежливый вопрос: «Ты готов трафик принимать?». Если нет — тебя временно отключат от балансировщика, пока не оклемаешься. Без этого — пиздец и тихий ужас, когда под вроде жив, а работать не может.
• Управление ресурсами: Requests и limits. Запомни, как «Отче наш». Requests — это то, что ты гарантированно требуешь у ноды, как место в общежитии. Limits — это потолок, выше которого тебе головой не пробить. Не укажешь — твой под может сожрать всю память на ноде и отправить в нокаут всех соседей. И тогда придёт админ и вмандюрит тебе реально.
• Сетевая политика: По умолчанию в кубере все поды друг с другом болтают, как бабки на лавочке. Хочешь изоляции? Выгораживай NetworkPolicy. Чтобы не было, как в том анекдоте: «а почему ваш бэкенд стучится напрямую в базу платежей?».

Вот, смотри, как примерно выглядит манифест для какого-нибудь Spring Boot-сервиса:

(Код ниже не трогаю, он святой)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: app
        image: my-registry/backend:1.0.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080

Ну и по мелочи: Service писал, чтобы к этим подам можно было найти дорогу, HorizontalPodAutoscaler — чтобы автоматом масштабировалось, когда нагрузка ебёт по крыше. И affinity/anti-affinity правила — это чтобы все три реплики не сбились в кучу на одной ноде, которую потом хрен знает кто вырубит. В общем, чтобы не было мудацких ситуаций.