Только один модуль использует все вычислительные ресурсы, хотя в шаблоне модуля указаны ограничения и запрашивает ресурсы. - PullRequest
Новая
       7

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

1 голос
/ 06 июня 2019

Я масштабирую прогноз ML на основе использования процессора и памяти. Я использовал HPA для масштабирования на уровне pod, где мы указали показатели как процессора, так и памяти. При создании развертывания я также указал запрашиваемые вычислительные ресурсы и ограничения для одного и того же (я вставил конфигурацию HPA и конфигурацию шаблона pod для справки)

Я заметил, что хотя мы указали лимит ресурсов и запрос, когда я проверяю память и ЦП, потребляемые каждым модулем, он показывает, что только один модуль потребляет все ресурсы ЦП и памяти, а другие потребляют очень меньше вычислительных ресурсов. Насколько я понимаю, все модули должны потреблять примерно равные ресурсы, поэтому мы можем сказать, что они масштабируются, иначе это все равно, что запускать код без k8s на одной машине.

Примечание. Я использую клиент python k8s для создания развертывания и служб, а не yaml.

Я пытался настроить параметры с ограничениями и ресурсами и заметил, что из-за этого ML-конвейер в некоторый момент экспоненциально увеличивает потребление памяти и процессора.

Моя конфигурация HPA: - 

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  namespace: default
  name: #hpa_name
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: #deployment_name
  minReplicas: 1
  maxReplicas: 40
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 80
    - type: Resource
      resource:
        name: memory
        targetAverageValue: 5Gi

Код шаблона моего пакета- 

 container = client.V1Container(
        ports=[client.V1ContainerPort(container_port=8080)],
        env=[client.V1EnvVar(name="ABC", value=12345)],
        resources=client.V1ResourceRequirements(
            limits={"cpu": "2", "memory": "22Gi"},
            requests={"cpu": "1", "memory": "8Gi"},
        ),

Выход kubectl top pods

NAME                                                              CPU(cores)   MEMORY(bytes)   
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-77c6ds   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7d5n4l   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7dq6c9   14236m       16721Mi         
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7f6nmh   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7fzdc4   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7gvqtj   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7h6ld7   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7j7gv4   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7kxlvh   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7nnn8x   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7pmtnj   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7qflkh   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7s26cj   1m           176Mi           
deploy-24b32e5dc388456f8f2263be39ffb5f7-de19236511504877-7st5lt   1m           176Mi

Исходя из вышеприведенного вывода, очень ясно, что третий модуль использует большинство ресурсов, в то время как другие находятся при постоянном потреблении памяти и ЦП, что очень мало.

Я ожидаю, что каждый модуль должен использовать ресурсы, приблизительно равные на основе ограничений и ресурсов, указанных в запросах шаблона модуля. В этом случае оно должно составлять от 1 до 2 ЦП для потребления ЦП и от 8 Ги до 22 Ги для памяти / меньше, чем запрашиваемый ресурс, но не выходит за определенные пределы.

Заранее спасибо за любые пункты / помощь / подсказки.

1 Ответ

2 голосов
/ 04 июля 2019

В соответствии с RCA (анализ первопричин) этой проблемы мы проверили, запустив ipvsadm -ln во время обработки рабочей нагрузки в нашем кластере kubernetes, и обнаружили, что только одно TCP-соединение выполняется с помощью полезной нагрузки, и это приводит к концентрации всей рабочей нагрузки. в одном пакете, хотя доступны и другие.

Наше приложение основано на GRPC, а GRPC использует HTTP / 2. HTTP / 2 имеют функцию для создания одного долгоживущего TCP-соединения, и запрос мультиплексируется по одному и тому же TCP-соединению, чтобы минимизировать накладные расходы на управление TCP-соединением. Из-за этого к одному модулю было подключено одно долгоживущее TCP-соединение, и, поскольку HPA резко увеличивает объем памяти и ЦП, он масштабирует модули, но нагрузка не распределяется. Таким образом, нам нужен механизм для распределения нагрузки на один шаг рядом с балансировкой нагрузки на уровне соединения (это балансировка нагрузки по умолчанию в kubernetes) для запроса балансировки нагрузки на уровне.

К счастью, мы нашли решение ниже, мы следовали этому, и оно сработало для нас.

https://kubernetes.io/blog/2018/11/07/grpc-load-balancing-on-kubernetes-without-tears/

...