Балансировка нагрузки сервисов Kubernetes с NGINX Plus

Kubernetes — это система с открытым исходным кодом, разработанная Google для запуска и управления контейнерными приложениями на основе микросервисов в кластере. Людям, которые используют Kubernetes, часто нужно, чтобы службы, которые они создают в Kubernetes, были доступны за пределами их кластера Kubernetes.

Хотя Kubernetes предоставляет встроенные решения для предоставления услуг, описанные ниже, эти решения ограничивают вас балансировкой нагрузки уровня 4 или циклическим распределением нагрузки HTTP.

В этом посте показано, как использовать NGINX Plus в качестве усовершенствованного решения для балансировки нагрузки уровня 7 для предоставления услуг Kubernetes Интернету, независимо от того, используете ли вы Kubernetes в облаке или в собственной инфраструктуре.

Мы предполагаем, что у вас есть базовые знания о Kubernetes (модули, службы, контроллеры репликации и метки) и работающий кластер Kubernetes. Чтобы узнать больше о Kubernetes, пожалуйста, посетите официальное руководство пользователя Kubernetes .

Предоставление услуг Kubernetes с помощью встроенных решений

Kubernetes предлагает несколько вариантов предоставления услуг . Два из них — NodePort и LoadBalancer — соответствуют определенному типу сервиса. Третий вариант, Ingress API, стал доступен как бета-версия в выпуске Kubernetes 1.1.

NodePort

Указание типа сервиса в качестве NodePort делает сервис доступным на том же порту на каждом узле Kubernetes. Чтобы предоставить службу Интернету, вы должны открыть один или несколько узлов на этом порту. Для обеспечения высокой доступности вы можете предоставить доступ к нескольким узлам и использовать балансировку нагрузки на основе DNS для распределения трафика между ними, либо вы можете разместить узлы за балансировщиком нагрузки по вашему выбору.

Когда входящий трафик попадает на узел в порту, он распределяется по нагрузке между модулями службы. Балансировка нагрузки, выполняемая прокси-сервером Kubernetes, работающим на каждом узле, ограничена балансировкой нагрузки TCP / UDP.

LoadBalancer

Указание типа службы в качестве LoadBalancer выделяет балансировщик нагрузки облака, который распределяет входящий трафик между модулями службы.

Решение LoadBalancer поддерживается только некоторыми облачными провайдерами и Google Container Engine и недоступно, если вы используете Kubernetes в собственной инфраструктуре. Кроме того, Kubernetes позволяет настроить циклическую балансировку нагрузки TCP, даже если облачный балансировщик нагрузки имеет расширенные функции, такие как сохранение сеанса или сопоставление запросов.

Входной API

Создание ресурса Ingress позволяет вам предоставлять сервисы Интернету по индивидуальным URL-адресам (например, сервис A по URL / foo и сервис B по URL / bar ) и нескольким именам виртуальных хостов (например, foo.example.com для одна группа услуг и bar.example.com для другой группы). Контроллер Ingress использует ресурс Ingress и устанавливает внешний балансировщик нагрузки.

Контроллер Ingress не является частью стандартного развертывания Kubernetes: вам нужно выбрать контроллер, который лучше всего соответствует вашим потребностям, или внедрить его самостоятельно и добавить его в свой кластер Kubernetes. Ожидается, что многие реализации контроллера появятся в ближайшее время, но на данный момент единственной доступной реализацией является контроллер для Google Compute Engine HTTP Balancer , который работает, только если вы используете Kubernetes в Google Compute Engine или Google Container Engine . Входной API поддерживает только циклическую балансировку нагрузки HTTP, даже если фактический балансировщик нагрузки поддерживает расширенные функции.

На момент написания статьи и Ingress API, и контроллер для Google Compute Engine HTTP Load Balancer находятся в стадии бета-тестирования.

Хотя упомянутые выше решения просты в настройке и работают «из коробки», они не предоставляют никаких дополнительных функций, особенно функций, связанных с балансировкой нагрузки на уровне 7.

Предоставление услуг Kubernetes с NGINX Plus

Чтобы интегрировать NGINX Plus с Kubernetes, нам нужно убедиться, что конфигурация NGINX Plus остается синхронизированной с Kubernetes, отражая изменения в службах Kubernetes, такие как добавление или удаление модулей. С помощью программного обеспечения NGINX с открытым исходным кодом вы вручную изменяете файл конфигурации NGINX и выполняете перезагрузку конфигурации. С NGINX Plus есть два способа динамического обновления конфигурации :

• С API. Этот метод использует API реконфигурации NGINX Plus « на лету» для добавления и удаления записей для модулей Kubernetes в конфигурации NGINX Plus, а также API Kubernetes для получения IP-адресов модулей. Этот метод требует от нас написания некоторого кода, и мы не будем подробно его обсуждать. Подробности смотрите на вебинаре Келси Хайтауэра « Вывод Kubernetes на грань с NGINX Plus» , на котором он исследует API и создает приложение, которое их использует.
• По именам DNS повторно разрешения  — Этот метод требует только правильной конфигурации одноразового Nginx Plus, как описан в следующем разделе.

Использование реконфигурации на основе DNS

Мы предполагаем, что у вас уже есть работающий кластер Kubernetes и хост с kubectlутилитой, доступной для управления кластером; инструкции см. в руководстве по началу работы с Kubernetes для вашего типа кластера. Вам также необходимо создать образ NGINX Plus Docker, и инструкции доступны в этом блоге .

Вот схема того, что мы будем делать:

1. Сконфигурируйте модуль NGINX Plus для предоставления и балансировки нагрузки службы, которую мы создаем на шаге 2.
2. Создайте простой сервис, который обслуживает статические веб-страницы.
3. Масштабируйте сервис вверх и вниз и посмотрите, как NGINX Plus автоматически перенастраивается.

Примечания: Мы протестировали решение, описанное в этом блоге, с Kubernetes 1.0.6, работающим на Google Compute Engine, и локальной установкой Vagrant , которую мы используем ниже.

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

Настройка модуля NGINX Plus

Мы помещаем NGINX Plus в модуль Kubernetes на узле, который мы выставляем в Интернете. Наш модуль создан контроллером репликации, который мы также настраиваем. Наш специфический для Kubernetes файл конфигурации NGINX Plus находится в папке, совместно используемой модулем NGINX Plus и узлом, что упрощает обслуживание.

Выбор узла, в котором находится стручок NGINX Plus

Чтобы обозначить узел, где работает модуль NGINX Plus, мы добавляем метку для этого узла. Мы получаем список всех узлов, выполнив:

$ kubectl get nodes
NAME         LABELS                              STATUS
10.245.1.3   Kubernetes.io/hostname=10.245.1.3   Ready
10.245.1.4   Kubernetes.io/hostname=10.245.1.4   Ready
10.245.1.5   Kubernetes.io/hostname=10.245.1.5   Ready

$ kubectl label node 10.245.1.3 role=nginxplus

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginxplus-rc
spec:
  replicas: 1
  selector:
    app: nginxplus
  template:
    metadata:
      labels:
        app: nginxplus
    spec:
      nodeSelector:
        role: nginxplus
      containers:
      - name: nginxplus
        image: nginxplus
        ports:
          - name: http
            containerPort: 80
            hostPort: 80
          - name: http-alt
            containerPort: 8080
            hostPort: 8080
        volumeMounts:
          - mountPath: "/etc/nginx/conf.d"
            name: etc-nginx-confd
      volumes:
        - hostPath:
            path: "/etc/nginx/conf.d"
          name: etc-nginx-confd

$ docker save -o nginxplus.tar nginxplus

$ docker load -i nginxplus.tar

$ mkdir /etc/nginx/conf.d

resolver 10.0.0.10 valid=5s;

upstream backend {
    zone upstream-backend 64k;
    server nginx-service.default.svc.cluster.local resolve;
}

server {
    listen 80;

    status_zone backend-servers;

    location /nginx-service/ {
        proxy_pass http://backend/;
        health_check;
    }
}

server {
    listen 8080;

    root /usr/share/nginx/html;

    location = /status.html { }

    location /status {
        status;
    }
}

$ kubectl create -f nginxplus-rc.yaml

$ kubectl get pods
NAME                 READY     STATUS    RESTARTS   AGE
nginxplus-rc-0ts5t   1/1       Running   0          17s

$ kubectl get nodes node-name -o json | grep -i externalIP -A 1
                "type": "ExternalIP",
                "address": XXX.XXX.XXX.XXX

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-rc
spec:
  replicas: 2
  selector:
    app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

$ kubectl create -f nginx-rc.yaml

$ kubectl get pods -l app=nginx
NAME             READY     STATUS    RESTARTS   AGE
nginx-rc-544f1   1/1       Running   0          2m
nginx-rc-uk6pm   1/1       Running   0          2m

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  ClusterIP: None
  ports:
  - port: 80 
    targetPort: 80
    protocol: TCP
  selector:
    app: nginx

$ kubectl create -f nginx-service.yaml

$ kubectl scale rc nginx-rc --replicas=4
scaled

$ curl -s 10.245.1.3:8080/status/upstreams/backend | jq .
{
  "peers": [
    {
      "id": 1,
      "server": "10.0.0.1:80",
      "backup": false,
      "weight": 1,
      "state": "unhealthy",
      "active": 0,
      "requests": 1,
      "responses": {
        "1xx": 0,
        "2xx": 0,
        "3xx": 0,
        "4xx": 0,
        "5xx": 0,
        "total": 0
      },
      "sent": 0,
      "received": 0,
      "fails": 0,
      "unavail": 0,
      "health_checks": {
        "checks": 1,
        "fails": 1,
        "unhealthy": 1,
        "last_passed": false
      },
      "downtime": 33965,
      "downstart": 1445378182275,
      "selected": 1445378131000
    },
    {
      "id": 2,
      "server": "10.246.1.6:80",
      ...
    },
    {
      "id": 3,
      "server": "10.246.3.2:80",
       ...
    {
      "id": 4,
      "server": "10.0.0.2:80",
      ...
    }
  ],
  "keepalive": 0
}

$ kubectl scale rc nginx-rc --replicas=1
scaled

$ curl -s 10.245.1.3:8080/status/upstreams/backend | jq .