Kubernetes 前后端通信 [英] Kubernetes Communication between Frontend and Backend

问题描述

对于本地开发，我有一个可以工作的 minikube.我们在那里部署了不同的服务.现在我想连接前端和后端.

For local development I have a working minikube. There we have different services deployed. Now I want to connect the Frontend with the Backend.

前端是一个 Angular 应用程序，存在于它自己的服务中.后端是一个 node.js 应用程序，也使用单独的服务，并使用 DNS 连接到其他内部服务，如 mongodb.

The Frontend is a angular application and lives in its own service. The Backend is a node.js application also using a separate service and uses DNS to connect to other internal services like mongodb.

现在我想从前端与后端通信.DNS 不工作，因为前端不知道如何解析命名路由.问题是告诉前端应该使用哪个后端 URL 和端口来发送请求?

Now I want to communicate from the Frontend with the Backend. DNS is not working because the Frontend does not know how to resolve the named route. The problem is to tell the frontend which backend URL and port it should use to send requests to?

当我第一次启动类型为 NodePort 的后端服务并将 URL 和端口复制到前端目标 URL 时，接近了唯一的工作状态.我觉得这对我来说很不干净.是否有另一种方法可以将后端请求的 url 获取到前端?

The only working state was approached when I first started the Backend service with type NodePort and copied the url and port to the Frontends target URL. I think this is very unclean to me. Is there another approach to get the url for backend requests into the Frontend?

我知道，当我们在 type="LoadBalancer" 的生产系统上部署服务时，该服务由外部 IP 公开，然后我可以从那里访问该服务.并且外部 IP 在 pod 更新等时将是永久的.我还看到的问题是需要通过额外的提交将后端 IP 注入到 docker 容器中.

I know when we deploy a service on a production system with type="LoadBalancer" that the service is exposed by an external IP and I can access the service then from there. And that the external IP will be permanent at pod updates and so on. The problem I also see is that the backend IP needs to be injected into the docker container by an additional commit.

Edit(1):后端服务

Edit(1): The backend service

apiVersion: v1
kind: Service
metadata:
  name: backend
  labels:
    app: some-app
    tier: backend
spec:
  type: NodePort
  ports:
  - port: 3000
  selector:
    app: some-app
    tier: backend

Edit(2): 当我用 fqn 从客户端请求时，我也得到这个响应:

Edit(2): I also get this response when I request from the client with a fqn:

OPTIONS http://backend.default.svc.cluster.local:3000/signup/ net::ERR_NAME_NOT_RESOLVED

推荐答案

首先我会尝试解决您的具体问题

First I will try to address your specific questions

当我第一次启动后端时接近了唯一的工作状态类型为 NodePort 的服务并将 url 和端口复制到前端目标 URL.我觉得这对我来说很不干净.在那儿另一种将后端请求的 url 放入前端?

The only working state was approached when I first started the Backend service with type NodePort and copied the url and port to the Frontends target URL. I think this is very unclean to me. Is there another approach to get the url for backend requests into the Frontend?

您在这里有几个选择 1) 正如您所说，使用 type="LoadBalancer".或 2) 通过前端服务器代理所有后端调用

You have couple of options here 1) As you said, use type="LoadBalancer". OR 2) Proxy all your backend calls through your front end server

我知道当我们在生产系统上部署服务时type="LoadBalancer" 表明该服务是由外部 IP 公开的，并且我可以从那里访问该服务.还有那个外部IP将在 pod 更新等中永久存在.我也看到的问题是需要通过以下方式将后端 IP 注入到 docker 容器中额外的提交.

I know when we deploy a service on a production system with type="LoadBalancer" that the service is exposed by an external IP and I can access the service then from there. And that the external IP will be permanent at pod updates and so on. The problem I also see is that the backend IP needs to be injected into the docker container by an additional commit.

1. 通过将配置从代码移到平台(比如 k8s configmap 或 consul/eureka 等外部 KV 注册表)，使其成为 12 因素应用程序(或更接近 12 因素应用程序 :))
2. 即使它留在代码中，如您所说，外部 IP 将是可引用的，除非您这样做，否则它不会更改.我不明白你为什么需要另一个部署

通过前端服务器代理所有后端调用

如果您通过前端的服务器端路由(或愿意路由)所有微服务/后端调用，并且将前端和后端部署在同一个命名空间的同一个 k8s 集群中，那么您可以使用 KubeDNS 附加组件(如果它在您的 k8s 集群中尚不可用，您可以与 k8s 管理员核对)将后端服务名称解析为其 IP.从您的前端服务器，您的后端服务将始终可以通过其名称解析.

Proxy all your backend calls through your front end server

If you are routing (or willing to route) all your microservices/backend call thru the server side of your front end and if are deploying both your front end and backend in the same k8s cluster in the same namespace, then you can use KubeDNS add-on (If it is not available in your k8s cluster yet, you can check with the k8s admin) to resolve the backend service name to it's IP. From your front end server, Your backend service will always be resolvable by it's name.

由于您的 k8s 集群中有 kubeDNS，并且前端和后端服务都驻留在同一个 k8s 集群和同一个命名空间中，我们可以利用 k8s 的内置服务发现机制.后端服务和前端服务可以通过名称相互发现.这意味着，您可以简单地使用 DNS 名称后端"从前端 pods 访问后端服务.因此，只需将通过前端 nginx 的所有后端请求代理到上游后端服务即可.在前端 nginx pods 中，后端服务的 IP 将解析为域名后端".这也将为您省去 CORS 的麻烦.此设置是可移植的，这意味着无论您是在开发、阶段还是生产中部署，名称后端"将始终解析为相应的后端.

Since you have kubeDNS in your k8s cluster, and both frontend and backend services resides in same k8s cluster and same namespace, we can make use of k8s' inbuilt service discovery mechanism. Backend service and frontend service will be discoverable each other by it's name. That means, you can simply use the DNS name "backend" to reach your backend service from your frontend pods. So, just proxy all the backend request through your front end nginx to your upstream backend service. In the frontend nginx pods, backend service's IP will resolvable for the domain name "backend". This will save you the CORS headache too. This setup is portable, meaning, it doesn't matter whether you are deploying in dev or stage or prod, name "backend" will always resolve to the corresponding backend.

这种方法的一个潜在缺陷是，您的后端可能无法独立于前端进行扩展；在我看来，这没什么大不了的；在 k8s 环境中，只需根据需要启动更多 pod.

A potential pitfall of this approach is, your backend may not be able to scale independent of frontend; Which is not a big deal in my humble opinion; In a k8s environment, it is just a matter of spinning up more pods if needed.

只是好奇 - 什么服务于您的前端(哪种服务器技术将您的 index.html 传送到用户的浏览器)?它是像 nginx 或 apache httpd 这样的静态服务器还是你在这里使用 nodejs?

Just curious- What is serving your front end (which server technology is delivering your index.html to user's browser)? is it static servers like nginx or apache httpd or are you using nodejs here?

这篇关于Kubernetes 前后端通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！