Использовали ли вы Kubernetes в продакшн-среде?

Ну ты представляешь, эта хуйня с кубером — это как собрать конструктор из тысяч деталей, которые ещё и сами по себе двигаться пытаются. В общем, да, разворачивал я продакшн-окружение на этой бандуре для микросервисов. Опыта — овердохуища, если честно.

Что я там только не делал, ёпта:

• Развертывание и управление: Создавал эти ваши Deployments, StatefulSets (для всяких стейтфул-штук вроде Кафки, чтоб данные не терялись), DaemonSets (чтобы на каждой ноде какой-нибудь агент для мониторинга торчал).
• Сетевое взаимодействие: Настраивал Services — все эти ClusterIP, NodePort, LoadBalancer, чтобы сервисы друг друга находили и наружу светились. И, конечно, Ingress-контроллеры (обычно Nginx), чтобы весь HTTP/HTTPS трафик по правильным дорожкам раскидывался. Иногда чувствуешь себя диспетчером в аэропорту, только самолёты — запросы.
• Конфигурация и секреты: Использовал ConfigMaps и Secrets. Ну, логично же — не тащить же пароли и настройки прямо в образ контейнера, это ж пиздец какой-то непрофессионализм. Отделил одно от другого, как учили.
• Хранение данных: Ковырялся с PersistentVolumeClaims, чтобы подам прицепить сетевое хранилище. А то перезапустится под — и все данные к ебеням, волнение ебать.
• Мониторинг и логи: Прикручивал Prometheus с Grafana, чтобы метрики смотреть, и связку EFK/ELK (Elasticsearch, Fluentd, Kibana) для логов. Без этого ты просто слепой в бегах — нихуя не понятно, что и где сломалось.

Вот, смотри, пример манифеста Deployment для PHP-FPM сервиса, который я настраивал:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-service
  template:
    metadata:
      labels:
        app: api-service
    spec:
      containers:
      - name: php-fpm
        image: my-registry/api-service:latest
        ports:
        - containerPort: 9000
        envFrom:
        - configMapRef:
            name: api-config
        - secretRef:
            name: api-secrets
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          tcpSocket:
            port: 9000
          initialDelaySeconds: 30
          periodSeconds: 10

А основные сложности, блядь, были как раз не в написании этих манифестов. Самый пиздец — это когда начинаешь отлаживать сетевые проблемы: один сервис другому не отвечает, а почему — хуй знает, все прокси, все эндпоинты вроде на месте. Или управление обновлениями без простоев — эти RollingUpdate стратегии надо так тонко настроить, чтоб не положить всё кластером. Ну и, конечно, подбор лимитов ресурсов (resources.limits/requests). Поставишь мало — сервис будет постоянно умирать от голода. Поставишь много — остальные начнут голодать, а кластер ресурсы жрёт как не в себя. Терпения ноль ебать, пока всё не отбалансируешь.