Только 1 модуль обрабатывает все запросы в кластере Kubernetes

Question

Вот файл манифеста для мини-куба Kubernetes, для развертывания и службы:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deployment
spec:
  selector:
    matchLabels:
      app: hello
  replicas: 3
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: hello_hello
        imagePullPolicy: Never
        ports:
        - containerPort: 4001
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
  ports:
  - port: 4001
    nodePort: 30036
    protocol: TCP
  type: NodePort

И простой HTTP-сервер, написанный на Golang

package main
import (
    http "net/http"

    "github.com/gin-gonic/gin"
)

func main() {
    r := gin.Default()
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "message": "pong",
        })
    })

    server := &http.Server{
        Addr:    ":4001",
        Handler: r,
    }

    server.ListenAndServe()
}

Когда я делаю несколькозапросы на IP: 30036 / ping и затем откройте логи модуля, я вижу, что только 1 из 3 модулей обрабатывает все запросы. Как сделать ответ на запросы других модулей?

Answer 1

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

То, что вы видите, это то, что только один Pod обрабатывает ваши запросы. Вы ожидаете, что каждый запрос будет сбалансирован по нагрузке для другого модуля. И ваше предположение верно, но балансировка нагрузки происходит не на уровне HTTP-запросов, а на уровне TCP.

Таким образом, когда у вас есть постоянное TCP-соединение и вы его повторно используете, вы не будете испытывать нагрузкубалансировка, которую вы ожидаете. Поскольку установление TCP-соединения является довольно дорогостоящим с точки зрения задержек, обычно проводится оптимизация, чтобы избежать повторного открытия новых TCP-соединений: HTTP keep-alive.

В большинстве сред и клиентов поддержка активности по умолчанию включена по умолчанию, это действительно такиди тоже. Попробуйте s.SetKeepAlivesEnabled(false) и посмотрите, решит ли это вашу проблему. (Рекомендуется только для тестирования!)

Вы также можете использовать несколько разных клиентов, например, из командной строки с curl или отключить keep-alive в Postman.

Answer 2

В кластере Kubernetes запросы, отправляемые сервисам k8s, направляются kube-proxy .

Режим kube-proxy по умолчанию - Iptalbles, начиная с Kubernetes v1.2, и обеспечивает более быстрое разрешение пакетов между Сервисами и внутренними модулями. Балансировка нагрузки между внутренними модулями выполняется напрямую через iptables rules.

. Возможно, вы не генерируете достаточную нагрузку, которую не может обрабатывать один модуль, поэтому вы перенаправлены на тот же модуль из kube-proxy.

Вы также можете увидеть ответ на этот вопрос для реализации пользовательских iptalbes-rule:

• Реализация правил iptables на узлах Kubernetes