502 Bad Gateway на Angular Приложение развернуто в кластере K8 - PullRequest
0 голосов
/ 14 апреля 2020

Я развернул 3 службы в кластере k8, который использует входной контроллер Traffi c. Я получаю ошибку 502 Bad Gateway за доступ к моему Angular встроенному внешнему интерфейсу, но сервер внутреннего узла и mon go db работают нормально.

Я пробовал входной контроллер Nginx, настроенный с тем же вопрос. Я знаю, что производственная сборка приложения будет лучше для окончательной сборки, но, насколько я знаю, доступ к dev-прежнему должен быть возможен. Входные данные Traefik правильно маршрутизируются в соответствии с IP и портом, но где-то по пути происходит сбой. У меня есть exe c 'd в модуле' frontend ', и curl подтверждает, что страница размещена на localhost: 4200, как и ожидалось.

Мой docker -компонентный файл выглядит следующим образом:

version: '3.7'

services:
    frontend:
        image: [image location]
        ports:
            - "4200"
        volumes:
            - ./frontend:/app

    s3-server:
        image: [image location]
        ports:
            - "3000"
        links:
            - database

    database:
        image: mongo
        ports:
            - "27017"

Мой traefik yaml выглядит следующим образом:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: frontend
  annotations:
    kubernetes.io/ingress.class: traefik
spec:
  rules:
  - host: [domainname] 
    http:
      paths:
      - path: /
        backend:
          serviceName: frontend
          servicePort: 4200
      - path: /api
        backend:
          serviceName: s3-server
          servicePort: 3000
      - path: /db
        backend:
          serviceName: database
          servicePort: 27017

интерфейс внешнего интерфейса (создан с помощью compose) yaml:

apiVersion: v1
kind: Service
metadata:
  annotations:
    kompose.cmd: kompose convert
    kompose.version: 1.21.0 ()
  creationTimestamp: null
  labels:
    io.kompose.service: frontend
  name: frontend
spec:
  ports:
  - name: "4200"
    port: 4200
    targetPort: 4200
  selector:
    io.kompose.service: frontend
status:
  loadBalancer: {}

Показывает входные данные:

Host              Path  Backends
  ----              ----  --------
  api.cailean.tech  
                    /      frontend:4200 (192.168.1.27:4200)
                    /api   s3-server:3000 (192.168.2.20:3000)
                    /db    database:27017 (192.168.2.14:27017)

Стручки показывают:

pod/database-798b8df4bd-zzxpx    1/1     Running   0          17h   192.168.2.14   kube-node-ea4d   <none>           <none>
pod/s3-server-76dd6b6b57-pq9lp   1/1     Running   0          15h   192.168.2.20   kube-node-ea4d   <none>           <none>
pod/nginx-86c57db685-qbcd4       1/1     Running   0          47m   192.168.1.26   kube-node-f94c   <none>           <none>
pod/frontend-5b8c7979d8-fggr6    1/1     Running   0          18m   192.168.1.27   kube-node-f94c   <none>           <none>

k описывают sv c Фронтенд:

Name:              frontend
Namespace:         default
Labels:            io.kompose.service=frontend
Annotations:       kompose.cmd: kompose convert
                   kompose.version: 1.21.0 ()
                   kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"kompose.cmd":"kompose convert","kompose.version":"1.21.0 ()"},"creationTim...
Selector:          io.kompose.service=frontend
Type:              ClusterIP
IP:                192.168.141.36
Port:              4200  4200/TCP
TargetPort:        4200/TCP
Endpoints:         192.168.1.27:4200
Session Affinity:  None
Events:            <none>

При подключении к серверному модулю Nginx (настроен для тестирования), если я свернусь IP-адрес веб-интерфейса, к которому я получил соединение, отклонено.

* Expire in 0 ms for 6 (transfer 0x559ae5cb5f50)
*   Trying 192.168.1.27...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x559ae5cb5f50)
* connect to 192.168.1.27 port 4200 failed: Connection refused
* Failed to connect to 192.168.1.27 port 4200: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 192.168.1.27 port 4200: Connection refused

Завиток изнутри модуля внешнего интерфейса дает мне:

Rebuilt URL to: localhost:4200/
*   Trying ::1...
* TCP_NODELAY set
* connect to ::1 port 4200 failed: Connection refused
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 4200 (#0)
> GET / HTTP/1.1
> Host: localhost:4200
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
< Accept-Ranges: bytes
< Content-Type: text/html; charset=UTF-8
< Content-Length: 761
< ETag: W/"2f9-Ft4snhWFNqmPXU8vVB/M50CiWRU"
< Date: Tue, 14 Apr 2020 12:54:50 GMT
< Connection: keep-alive
< 
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>S3 Manoeuvre Selector</title>
  <base href="/">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="icon" type="image/x-icon" href="favicon.ico">
  <link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500&display=swap" rel="stylesheet">
  <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet">
</head>
<body class="mat-typography">
  <app-root></app-root>
<script src="runtime.js" type="module"></script><script src="polyfills.js" type="module"></script><script src="styles.js" type="module"></script><script src="vendor.js" type="module"></script><script src="main.js" type="module"></script></body>
</html>
* Curl_http_done: called premature == 0
* Connection #0 to host localhost left intact

Как вы видите, изначально он не работает, но разрешается правильно. Есть решение?

Есть идеи, почему Bad Gateway для angular интерфейса, но не mon go db или express api?

Обновление: внесение произвольных изменений 4- 6 раз для обслуживания yaml и использования 'kubectl apply -f' не приведет к ошибке плохого шлюза и будет работать должным образом, даже если yaml службы точно такой же, как первоначально использованный для запуска службы. Не могу найти причину, по которой это может быть ...

Ответы [ 2 ]

0 голосов
/ 14 апреля 2020

Кажется, вы определили свой сервис как тип LoadBalancer. Тип LoadBalancer - это тип, который вы используете в «самой внешней» области и доступны для внешней сети, в то время как служба ClusterIp больше подходит для самого кластера.

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

0 голосов
/ 14 апреля 2020

Кажется, вы смешиваете интерфейс с модулем сервера s3. Сервис выглядит хорошо, потому что он заполнен Endpoints. Отказ в соединении с IP-адресом модуля обычно означает, что в модуле отсутствует контейнер, прослушивающий порт (4200), с которым выполняется прокрутка.

...