Новые модули не используются после горизонтального масштабирования модуля в Google Kubernetes Engine

Question

У меня есть развертывание с веб-сервисом, которое я тестирую с использованием K6. Горизонтальное автоматическое масштабирование модуля включено с минимальной 1 и максимальной 4 репликами. Когда я запускаю нагрузочный тест, автоскалер масштабируется до 4 реплик, но только модуль, который уже был доступен до автоматического масштабирования, получает трафик c. Однако я вижу, что все 4 модуля работают и работают.

Службе ClusterIP, обслуживающей развертывание, для sessonAffinity задано значение None. Запрос процессора составляет 0,5, а ограничение процессора составляет 1,3. Среднее целевое использование hpa составляет 50. В тестах загрузка процессора, обслуживающего один модуль, c возрастает до или чуть выше предела, другие модули не показывают использование ЦП.

Однако, когда при запуске теста доступно несколько pdos, нагрузка распределяется между этими модулями (хотя и неравномерно). Как показано на рисунке 1, два теста были проведены подряд. Количество запросов, обслуживаемых каждым модулем в агрегатах 5s, иллюстрируется. В первом тесте автоматическое масштабирование масштабировалось до 4 модулей, но только один модуль получил запросы. Во втором тесте все 4 Блока все еще были там после апскейлинга в тесте 1 и во всех полученных запросах. figure 1

Я также заметил, что при увеличении traffi c в нагрузочном тесте некоторые из новых модулей получают некоторые запросы, как показано в traffi c 2, где две загрузки пики были добавлены к тесту. figure 2

Тем не менее, я хочу, чтобы запросы распределялись между всеми модулями равномерно, как только они будут созданы благодаря автоматическому масштабированию. Что может быть не так?

Вот конфигурация:

Развертывание:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: td-app
  namespace: crypto
spec:
  replicas: 1
  selector:
    matchLabels:
      app: td-app
  template:
    metadata:
      labels:
        app: td-app
    spec:
      containers:
      - env:
        - name: HTPASSWDFILE
        - name: KEYCATALOGUE
          value: /home/app/keys.json
        image: eu.gcr.io/td-cluster/td:2.3.0-2020457-a92b94
        imagePullPolicy: IfNotPresent
        name: td-app
        ports:
        - containerPort: 8080
          name: main
          protocol: TCP
        resources:
          limits:
            cpu: 1.3
            memory: 200Mi
          requests:
            cpu: 0.5
            memory: 50Mi
        securityContext:
          runAsNonRoot: true
          runAsUser: 1000
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /home/app/masterkeys
          name: masterkeys
      volumes:
      - name: masterkeys
        secret:
          defaultMode: 420
          secretName: masterkeys

Служба:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: td-app
  name: td-app-service
  namespace: crypto
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: td-app
  sessionAffinity: None
  type: ClusterIP

hpa:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: td-app
  namespace: crypto
  labels:
    app: td-app
spec:
  maxReplicas: 4
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: td-app
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 50

Для испытаний используется K6.io. В течение 6 минут до 12 виртуальных пользователей итеративно отправляют HTTP-запросы POST. Тест выполняется как задание в том же кластере с использованием имени службы для отправки запросов.