在 nginx、K8s 入口和 istio 网关中反应安装答案

【问题标题】：react installation in nginx vs K8s ingress vs istio gateway在 nginx、K8s 入口和 istio 网关中反应安装
【发布时间】：2022-10-02 00:27:15
【问题描述】：

我在 nginx 中安装了一个 react 应用程序，然后是一个 express.js 服务器，用于连接到 mysql 的后端。当客户端向 x.com/ 请求时，来自 nginx 的 default.conf 指示从本地 /var/www/build 文件夹中选择文件，当路径为 x.com/api 时，nginx 会将调用重定向到express.js 服务器。

upstream client {
    server client:3000;
}

upstream api {
    server api:3001;
}

server {
    listen 80;

    #location / {
    #    proxy_pass http://client;
    #}
    location / {
        root /var/www/build;
        try_files $uri /index.html;
    }

    # location /sockjs-node {
    #     proxy_pass http://client;
    #     proxy_http_version 1.1;
    #     proxy_set_header Upgrade $http_upgrade;
    #     proxy_set_header Connection \"Upgrade\";
    # }

    location /sockjs-node {
        root /var/www/build;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection \"Upgrade\";
    }
    
    location /api {
        rewrite /api/(.*) /$1 break;
        proxy_pass http://api;
    }
}

我的问题是，现在我将所有内容都放入容器和 K8s 集群中，我使用了 Istio 网关。但在我的配置中，只是通过网关中的所有流量到 nginx 容器。

---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: rproxygw
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - \"*\"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: rproxy
spec:
  hosts:
  - \"*\"
  gateways:
  - rproxygw
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: rproxy
        port:
          number: 80

既然一切都在使用 Istio 的 K8s 集群上，那还有什么更好的呢？只是从网关重定向 x.com/api？

有没有办法将 react 静态文件安装到 Istio 网关并摆脱 nginx 代理？

如何摆脱 nginx 作为反向代理，只使用 Istio 网关并将 react 应用程序安装到另一个 express 服务器中，或者只是重用运行后端的 express 服务器来安装 react 静态文件？

哪个选项在延迟方面表现最好？

标签： reactjs nginx kubernetes istio

【解决方案1】：

有什么方法可以将 react 静态文件安装到 Istio 网关中

不，它只将请求转发到 Kubernetes 服务。

您描述的任何各种方法都可以正常工作。 Nginx 相当高效；在其他条件相同的情况下，跳数越少越好。如果事实证明您的应用程序更容易管理保留 Nginx 反向代理，那么保留它并没有错。如果您的前端和后端代码在同一个存储库中，并且很容易将它们构建到同一个容器映像中，那么同样地，让一个进程同时为这两个部分提供服务并没有什么问题。

【讨论】：