Правило входа K8s для нескольких путей в одной бэкэнд-службе - PullRequest
Новая
       3

Правило входа K8s для нескольких путей в одной бэкэнд-службе

0 голосов
/ 20 января 2019

Я пытаюсь настроить входной балансировщик нагрузки. По сути, у меня есть один бэкэнд-сервис с несколькими путями.

Допустим, имя моей внутренней службы NodePort - hello-app. Модуль, связанный с этим сервисом, предоставляет несколько путей, таких как / foo и / bar. Ниже приведен пример

Служба NodePort и соответствующее развертывание 

apiVersion: v1
kind: Service
metadata:
  name: hello-app
spec:
  selector:
    app: hello-app
  type: NodePort
  ports:
    - protocol: "TCP"
      port: 7799
      targetPort: 7799
---
apiVersion: apps/v1 
kind: Deployment
metadata:
  name: hello-app
  labels:
    app: hello-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-app
        image: us.gcr.io/hello-app:latest

Теперь при выполнении запроса, как показано ниже, я сталкиваюсь с ошибкой 404. 

http://{ingress-address:port}/foo
http://{ingress-address:port}/bar

В качестве альтернативы я попробовал следующие конфигурации входа, но в обоих случаях это не помогло.

Входная конфигурация 1 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: hello-app
          servicePort: 7799

Входная конфигурация 2 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  backend:
    serviceName: hello-app
    servicePort: 7799

Сообщение об ошибке

10.88.16.10 - - [20 / Jan / 2019 08:50:55] "GET / HTTP / 1.1" 404 - [2019-01-20 08:50:55] [INFO] [_internal] [_log] 10.88.16.10 - - [20 / Jan / 2019 08:50:55] "GET / HTTP / 1.1" 404 -

Я рассмотрел пример упоминания в этой ссылке, но предполагается, что разные пути относятся к разным внутренним сервисам. В моем случае несколько путей принадлежат одному и тому же внутреннему сервису.

Похоже, что полный путь не пересылается нисходящему бэкэнд-сервису от входа, что приводит к неверному запросу. Может кто-нибудь подсказать, как правильно настроить вход для вышеуказанного требования?

Ответы [ 2 ]

0 голосов
/ 23 января 2019

Отвечая на мой вопрос после получения дополнительной информации о входе.

Это не было проблемой неправильного пути пересылки вниз по течению. В основном входной контроллер gke ожидает, что в бэкэнде будет присутствовать датчик готовности. Мне не хватало этого в моем развертывании, и из-за этого вход отмечал бэкэнд как «неизвестный»

В конечном итоге чтение других вопросов об стеке потока, приведенных ниже, помогло мне решить проблему

GCP-балансировки нагрузки-бэкенд-статус-неизвестно

kubernetes-вход-GCE-держит возвращающих-502 ошибок

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

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: hello-app
  labels:
    app: hello-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-app
        image: us.gcr.io/hello-app:latest
        readinessProbe:
          httpGet:
            path: /healthz
            port: 7799
          periodSeconds: 1
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 10
0 голосов
/ 22 января 2019

Чтобы использовать многолучевое распространение с входом glbc, вам нужно иметь разные имена сервисов, например, в приведенном ниже примере, и каждый сервис (бэкэнд) имеет свой путь, и можно настроить один вход (не два).

Итак, вам не нужно два входа, если только вы не хотите иметь два loadbalancer 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: fanout-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: web
          servicePort: 8080
      - path: /v2/*
        backend:
          serviceName: web2
          servicePort: 8080

Существует Multi-Port Services, Kubernetes поддерживает несколько определений портов для объекта Service. При использовании нескольких портов вы должны указать все имена портов. см. пример ниже

Вот ответ, используя вход kubernetes с nginx . 

kind: Service
apiVersion: v1

    metadata:
      name: my-service
    spec:
      selector:
        app: MyApp
      ports:
      - name: http
        protocol: TCP
        port: 80
        targetPort: 9376
      - name: https
        protocol: TCP
        port: 443
        targetPort: 9377
...