前端与后端之间的Kubernetes通信

问题描述

对于本地开发，我有一个工作的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.

Frontend是一个有角度的应用程序，并存在于它自己的服务中.后端是一个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类型启动Backend服务并将URL和端口复制到Frontends目标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?

我知道，当我们在类型为"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

您在这里有几个选择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

1. 通过将配置从您的代码移到平台上(使其成为k8s configmap或像consul/eureka这样的外部KV注册表)，使它成为12因子应用程序(或比12因子应用程序靠近1步:).
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名称后端"即可从前端 pod 访问后端服务.因此，只需将所有后端请求通过您的前端nginx代理到您的上游后端服务即可.在前端nginx pod 中，域名"backend"的域名可以解析为后端服务的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通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！