Openshift: внутренняя балансировка нагрузки (через сервис) не работает должным образом - PullRequest
Новая
       15

Openshift: внутренняя балансировка нагрузки (через сервис) не работает должным образом

1 голос
/ 03 мая 2020

у нас есть следующая настройка в нашей openshift-среде:

Приложение A в пространстве имен B, которое отображается через маршрут, и следующая конфигурация в отношении балансировки нагрузки: 

haproxy.router.openshift.io/balance: roundrobin
haproxy.router.openshift.io/disable_cookies: 'True'

Приложение C в пространстве имен D (тот же кластер), который вызывается приложением A через (внутреннюю) службу.

В настоящее время мы наблюдаем хорошее распределение нагрузки для модулей приложения A, что означает, что модули имеют примерно то же самое использование процессора / памяти и запросов / секунду.

Однако приложение C, которое вызывается через службу, показывает (например, для двух пакетов) среднее количество запросов в секунду в пропорции 1: 2. Единственная информация в документации, которую я смог найти, заключается в том, что при нормальных обстоятельствах kubernetes должен балансировать нагрузку для такого рода внутренних вызовов службы. 

sessionAffinity: None

также установлен.

Мы используем Openshift v3.11.161 (Kubernetes v1.11). Есть что-то, о чем я не знаю?

РЕДАКТИРОВАТЬ: Служебный объект: 

apiVersion: v1
kind: Service
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"test","template":"test-template"},"name":"test-service","namespace":"namespace"},"spec":{"ports":[{"name":"8080-tcp","port":8080,"protocol":"TCP","targetPort":8080}],"selector":{"deploymentconfig":"test-dc"},"sessionAffinity":"None"}}
  creationTimestamp: 'timestamp'
  labels:
    app: test
    template: test-template
  name:test-service
  namespace: namespace
  resourceVersion: '73875211'
  selfLink: /test/test
  uid: uid
spec:
  clusterIP: x.y.z
  ports:
    - name: 8080-tcp
      port: 8080
      protocol: TCP
      targetPort: 8080
  selector:
    deploymentconfig: test
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

С уважением

1 Ответ

0 голосов
/ 04 мая 2020

Какую клиентскую библиотеку вы используете? Часто можно увидеть, что HTTP-соединение поддерживается библиотекой, используемой для выполнения запросов. Например, стандартная библиотека Go довольно активно использует keepalive, также как и для соединений HTTP2.

Можно ли воспроизвести такую ​​же несправедливую балансировку нагрузки, используя curl l oop из одного из модулей

...