Каков алгоритм балансировки нагрузки по умолчанию в GLBC L7 в GKE?

Question

У меня есть простой входной ресурс и две службы: ess-index и ess-query. Услуги были выставлены с типом NodePort с --session-afinity=None. Ресурс Ingress имеет следующую структуру:

apiVersion: extensions/v1beta1 
kind: Ingress 
metadata: 
name: ess-ingress 
spec: 
    backend: 
    serviceName: ess-query 
    servicePort: 2280 
    rules: 
    - http: 
     paths: 
     - path: /api/index 
     backend: 
      serviceName: ess-index 
      servicePort: 2280 

Созданные службы будут иметь прокси-режим iptables. Когда я выставляю эти службы в качестве NodePort, мастер kubernetes будет выделять порт из диапазона, настроенного на флагом, и каждый Node будет проксировать этот порт в службе ess-index или ess-query соответственно. Итак, когда я вхожу в POST с kubectl create -f ingress.yaml, это приведет к следующему поведению: будет автоматически создан контроллер GLBC, который управляет следующим графиком ресурсов GCE (глобальное правило пересылки -> TargetHttpProxy -> URL-карта -> служба бэкэнд -> группа экземпляров). Он должен отображаться в виде контейнера в соответствии с документацией, но я не вижу его в следующем командном выходе: kubectl get pods --namespace=kube-system. Вот sample output Мой вопрос: каков алгоритм балансировки нагрузки по умолчанию для этого loadbalancer? Что происходит, когда маршруты маршрутизации к соответствующему серверу? Я правильно понимаю, что алгоритм по умолчанию не является циклическим и, согласно документам Service, случайным образом распределен (возможно, на основе некоторого хэша IP-адреса источника/назначения и т. Д.)? Это важно, потому что в моем случае весь трафик идет от небольшого числа машин с фиксированным IP-адресом, поэтому я могу видеть неравномерное распределение трафика на моих внутренних серверах. Если да, то каков правильный способ получить циклическое поведение? Насколько я понимаю, я могу выбрать один из двух вариантов:

1. Пользовательский контроллер входа. Плюсы: он может автоматически обнаруживать перезагрузки pod/etc., Cons: не может поддерживать расширенные функции l7, которые могут мне понадобиться в будущем (например, постоянство сеанса)
2. Удалить вход и использование самостоятельно построить решение, как упомянуто здесь: https://www.nginx.com/blog/load-balancing-kubernetes-services-nginx-plus/ Плюсы: полностью настраиваемые, минусы: вы должны позаботиться о перезагрузке стручков и т. Д. Самостоятельно.

Answer 1

Включение алгоритмов kubeproxy и cloud lb, чтобы они сотрудничали в достижении общей цели, все еще продолжается. Прямо сейчас, это закончится распылением, со временем вы получите примерно равное распределение, но это будет не строго.

Если вы действительно хотите контролировать мелкий зерно по алгоритму, вы можете развернуть nginx ingress controller и разоблачить его как услугу Type = lb (или даже придерживаться GCE l7 перед ним). Это даст вам семантику Ingress, но позволяет исключить люк для областей, которые облачные провайдеры еще не полностью интегрированы с Kube, как и управление алгоритмом. Выходной люк выставлен как annotations или полный config map для шаблона.