Kubernete: спросите решение баланса нагрузки L4 для облачного кластера

Question

Я построил кластер Kubernete в локальном дата-центре. Есть 4 узла и 1 мастер. Ищете решение балансировки L4 для внутреннего обслуживания.

root@niubi01:/home/mesos# kubectl get nodes 
NAME  STATUS   AGE 
niubi01 Ready,master 7d 
niubi02 Ready   7d 
niubi03 Ready   7d 
niubi04 Ready   7d 
niubi05 Ready   7d 

Предположим, у нас есть три Pods с веб-сервисом «hello world». Служба с открытым внешним IP-адресом создается с помощью «NodePort». Внешний IP является «Вершиной» и порт 30145.

root@niubi01:/home/mesos# kubectl get service 
NAME    CLUSTER-IP  EXTERNAL-IP PORT(S)   AGE 
example-service 10.100.220.21 <nodes>  8080:30145/TCP 6d 

Как уже отмечался в документе, можно получить доступ к любому узлу IP для доступа к этой услуге «привет мира». Нравится:

curl http://niubi01:30145 
curl http://niubi02:30145 
curl http://niubi03:30145 
curl http://niubi04:30145 
curl http://niubi05:30145 

снаружи. Проблема в том, что мы не можем гарантировать, что любой узел активен навсегда, даже мастер. Какой URL следует использовать для использования? Как сделать LoadBalance как Haproxy для обеспечения высокой доступности для этой услуги? Должен ли у нас есть другой сервер, обеспечивающий распределение нагрузки между этими 5 адресами? Стремясь найти лучшее решение для этого случая.

Answer 1

Как вы уже заметили, вам нужно будет настроить пользовательский loadbalancer для выполнения этой работы. Этот loadbalancer должен быть внешним для вашего кластера и настроен самостоятельно.

Я предлагаю вам ознакомиться с концепциями Ingress и ingress-controller. Особенно полезен здесь nginx-ingress-controller.

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

Чтобы развернуть контроллер ингресс, оно должно быть достаточно, чтобы сделать следующее:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress/master/examples/deployment/nginx/default-backend.yaml 
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress/master/examples/deployment/nginx/nginx-ingress-controller.yaml 

Первая строка создает default-backend, который используется для всех несогласованных втекает. Он в основном просто возвращает 404

Вторая строка создает Deployment с 1 репликой по умолчанию. В среде prod вы можете изменить счетчик реплик либо путем масштабирования развертывания, либо с помощью локальной модифицированной копии файла nginx-ingress-controller.yaml. Кроме того, я бы посоветовал использовать выделенные узлы (используя DaemonSet + NodeAffinity + Taints + Tolerations) для входного контроллера, если вы ожидаете большого количества трафика.

Входящий контроллер теперь работает, не подвергаясь воздействию. Я полагаю, что демонстрация контроллера не является частью примеров, поскольку это слишком сильно зависит от используемой инфраструктуры. В вашем случае, вы должны создать Kubernetes Service, который выставляет ингресс-контроллер в качестве NodePort путем развертывания этого ресурса:

apiVersion: v1 
kind: Service 
metadata: 
    name: nginx-ingres-controller-svc 
    labels: 
    name: nginx-ingres-controller-svc 
    namespace: kube-system 
spec: 
    type: NodePort 
    ports: 
    - port: 80 
     nodePort: 30080 
     name: http 
    - port: 443 
     nodePort: 30443 
     name: https 
    selector: 
    k8s-app: nginx-ingress-controller 

Пожалуйста, обратите внимание, что nodePort явно указано здесь. Это облегчает жизнь при настройке внешнего балансировщика.

После этого вы можете создать ресурсы для прямого внешнего трафика в свои внутренние службы. Например:

apiVersion: extensions/v1beta1 
kind: Ingress 
metadata: 
    name: example-ingress 
spec: 
    rules: 
    - host: example.company.org 
    http: 
     paths: 
     - path:/
     backend: 
      serviceName: example-service 
      servicePort: 8080 

Если у вас есть настройка центров обработки данных DNS для разрешения example.company.org к внешней балансировки нагрузки, называя это приведет вас прямо к example-service

Все это, вероятно, звучит сложнее, чем просто с помощью NodePort и изменение конфигурации внешнего loadbalancer для новых сервисов. Но если он настроен один раз, конфигурация и автоматизация упрощаются. Он также дает массу новых функций, которые в противном случае должны быть реализованы вручную. Например, nginx-ingress-controller изначально поддерживает базовый auth, просто добавляя аннотацию к ресурсу Ingress. Он также поддерживает letencrypt при использовании в сочетании с kube-lego. Как сказано в начале, вы должны прочитать документацию о проникновении, чтобы выяснить, что она принесет бесплатно.

Answer 2

независимо от где ваш LoadBalancer расположен вы могли бы просто иметь виртуальный IP-адрес балансировка нагрузки между узлами и включить его в определении сервиса, как показано in the documentation:

--- 
kind: Service 
apiVersion: v1 
metadata: 
    name: my-service 
spec: 
    selector: 
    app: MyApp 
    ports: 
    - name: http 
    protocol: TCP 
    port: 80 
    targetPort: 9376 
    externalIPs: 
    - 80.11.12.10 

После того, как трафик для этого IP (80.11.12.10) удаляет любой из узлов, kube-proxy перенаправит его на ваш сервис.

Одним из вариантов реализации этого будет использование кардиостимулятора на узлах, как описано во многих blog posts. Но также наличие специального балансировщика нагрузки перед кластером будет работать нормально.

Преимущество использования виртуальных IP-адресов заключается в том, что вам не нужно связываться с NodePorts в брандмауэрах или соответствующей конфигурации. Другое преимущество заключается в том, что это не ограничивается HTTP-трафиком.

Недостатком является то, что конфигурация внешнего балансировщика нагрузки и назначение IP-адреса для службы не автоматизированы и должны выполняться вручную. Чтобы смягчить эту проблему, вы можете либо реализовать собственный провайдер (см. Другие provider implementations on Github), либо вы можете прочитать конфигурацию службы из etcd и использовать это как источник для настройки внешнего балансировщика нагрузки.