Как сделать так, чтобы на железном сервере работал горизонтальный автоскейлер для подов

Развертывание горизонтального автоскейлера для подов на bare-metal сервере

Горизонтальный автоскейлер подов (Horizontal Pod Autoscaler, HPA) — ключевой инструмент для автоматического масштабирования рабочих нагрузок в Kubernetes. На bare-metal инфраструктуре его настройка требует дополнительных шагов по сравнению с облачными окружениями, где метрики ресурсов (CPU/memory) обычно предоставляются провайдером. Основная сложность — обеспечение HPA источником метрик, так как по умолчанию он использует Metrics Server, который зависит от cAdvisor и kubelet.

Предварительные требования и архитектура

1. Kubernetes кластер на bare-metal серверах (например, развернутый с помощью kubeadm, Rancher или вручную).
2. Сетевой плагин CNI (Calico, Flannel, Cilium) для корректной работы подов.
3. Система мониторинга, предоставляющая метрики ресурсов (альтернатива cloud-provider metrics).

Пошаговая реализация

1. Установка и настройка Metrics Server

Metrics Server агрегирует метрики ресурсов через kubelet. В bare-metal средах часто требуется дополнительная конфигурация из-за отсутствия сертификатов, подписанных публичным CA.

# metrics-server.yaml с параметрами для bare-metal
apiVersion: v1
kind: ServiceAccount
metadata:
  name: metrics-server
  namespace: kube-system
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      serviceAccountName: metrics-server
      containers:
      - name: metrics-server
        image: registry.k8s.io/metrics-server/metrics-server:v0.7.0
        args:
          - --kubelet-insecure-tls # Важно для self-signed сертификатов
          - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
        ports:
        - containerPort: 4443

Примените конфигурацию и проверьте работу:

kubectl apply -f metrics-server.yaml
kubectl top nodes  # Должна отобразить потребление ресурсов

2. Настройка HPA для приложения

Создайте деплоймент с ресурсными запросами (requests), так как HPA использует их для расчета утилизации.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
        ports:
        - containerPort: 80
---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80

3. Создание HPA ресурса

HPA будет масштабировать деплоймент на основе CPU (по умолчанию) или пользовательских метрик.

# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50  # Средняя утилизация CPU по всем подам

Примените и проверьте:

kubectl apply -f hpa.yaml
kubectl get hpa  # Увидите текущую утилизацию и количество реплик

Альтернативы и расширенные сценарии для bare-metal

Использование Prometheus и Custom Metrics

Для сложного скейлинга на основе бизнес-метрик (RPS, очередь сообщений) потребуется Prometheus Adapter.

1. Установите Prometheus:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/prometheus

1. Установите Prometheus Adapter и настройте правила для кастомных метрик.

2. Создайте HPA, использующий кастомные метрики:

metrics:
- type: Pods
  pods:
    metric:
      name: http_requests_per_second
    target:
      type: AverageValue
      averageValue: 100

Решения для масштабирования на нуле (scale-to-zero)

В bare-metal средах часто критична эффективность использования ресурсов. Для scale-to-zero рассмотрите:

• KEDA (Kubernetes Event-driven Autoscaling) — поддерживает широкий спектр триггеров (Kafka, RabbitMQ, HTTP).
• Knative Serving — для serverless-рабочих нагрузок.

Пример установки KEDA:

helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda

Ключевые аспекты для production-среды

• Мониторинг и алертинг — отслеживайте события автомасштабирования через Prometheus/Grafana.
• Лимиты ресурсов — устанавливайте limits для предотвращения исчерпания ресурсов нод.
• Антиаффинити — распределяйте поды по нодам для отказоустойчивости:

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - nginx
        topologyKey: kubernetes.io/hostname

• Бюджет disruption — настройте PodDisruptionBudget для контроля доступности при масштабировании.

Проблемы и их решение

1. HPA не получает метрики — проверьте логи Metrics Server (kubectl logs -n kube-system deployment/metrics-server) и доступность kubectl top.
2. Поды не масштабируются — убедитесь, что в деплойменте указаны resources.requests и что утилизация превышает порог.
3. Медленное масштабирование — настройте behavior в HPA (v2 API) для контроля скорости скейлинга.

В bare-metal окружениях HPA полностью функционален, но требует тщательной настройки метрик и мониторинга ресурсов. Для сложных сценариев комбинируйте ресурсные метрики с кастомными через Prometheus Adapter или KEDA.