如何使用服务名称访问 Kubernetes 集群中的服务. [英] How to access a service in a kubernetes cluster using the service name .

问题描述

我对 kubernetes 还很陌生，我已经成功地在 google 容器引擎上设置了一个集群.在我的集群中，我有一个用 dropwizard 开发的后端 api，用 node js 和一个 mysql 数据库开发的前端.所有都已部署到集群并且正在工作.但是我的挑战是在为我的节点容器和后端设置外部 ip 之后我可以远程访问它们但我无法使用服务名称从我的前端访问我的支持，例如我的后端在集群中称为 backendapi.我不能这样做 http://backendapi:8080 在部署到集群时调用我的休息服务.对我来说，问题是当我部署到集群时，我不希望前端使用外部 ip 访问后端，我希望它们在不通过外部 ip 地址的情况下连接到集群内.当我连接到一个 pod 并 ping backendapi 它返回一个结果但是当我部署我的前端并使用标签名称时它不起作用.我可能做错了什么?.

I am pretty new to kubernetes and I have successfully setup a cluster on google container engine . In my cluster I have a backend api developed with dropwizard, front end developed with node js and a mysql database. All have been deployed to the cluster and are working .However my challenge is this after setting up an external ip for my node containers and backend I can access them remotely but I can't access my backed from my front end using the service name e.g my backend is called backendapi within the cluster. I can't do this http://backendapi:8080 to call my rest services when deployed to the cluster . The catch for me is when I deploy to the cluster I don't want my front end to hit my back end using the external ip, I want them to connect within the cluster without going via the external ip address. When I connect to a pod and ping backendapi it returns a result but when I deploy my front end and use the label name it doesn't work .What could I be doing wrong ?.

推荐答案

但是问题当我改为这个时仍然存在backendapi.default.svc.cluster.local:8080.我什至尝试使用另一个它内部映射到的端口，我的前端网页保留说 backendapi.default.svc.cluster.local:32208/api/v1/auth/loginnet::ERR_NAME_NOT_RESOLVED.有趣的是当我从我的前端吊舱它的工作原理.但是当我使用我的网络访问它时浏览器没有

But the problem still persists when I change to this backendapi.default.svc.cluster.local:8080. I even tried using the other port that it is mapped to internally and my front end web page keeps saying backendapi.default.svc.cluster.local:32208/api/v1/auth/login net::ERR_NAME_NOT_RESOLVED. The funny thing is when I curl from my front end pod it works . But when I'm accessing it using my web browser it doesnt

因为它只能在集群内解析.(因为只有带kube-dns插件的K8s集群才能将域名backendapi.default.svc.cluster.local:8080翻译成对应的IP地址)

Because it is resolvable only within the cluster. (Because only the K8s cluster with kube-dns add-on can translate the domain name backendapi.default.svc.cluster.local:8080 to it's corresponding IP address)

这可能是因为我也暴露了该服务的外部 IP.外部ip虽然有效

Could this be because i exposed an external ip for the service as well . The external ip works though

不，这是因为域名 backendapi.default.svc.cluster.local 只能在集群内解析，不能从随机机器中的随机浏览器解析.

No, It is because domain name backendapi.default.svc.cluster.local is resolvable only within the cluster, not from a random browser in a random machine.

你所做的是解决方案之一，为服务公开一个外部IP.如果您不想使用该 IP，您可以创建一个入口(并在您的集群中使用一个入口控制器)并公开您的微服务.由于您使用的是 GCP，您可以使用他们的 API 网关，而不是暴露一个神秘的 IP 地址.

What you did is one of the solutions, exposing an external ip for the service. If you don't want the IP to be used, you can Create an ingress (and use an ingress controller in your cluster) and expose your Microservice. Since you are on GCP, you can make use of their API gateway rather than exposing a cryptic IP address.

注意:记住添加身份验证/授权以锁定您的微服务，因为它会暴露给用户.

Note: Remember to add the authentication/Authorization to lock down your microservice as it's getting exposed to the user.

通过为您的 Web 应用程序(nginx/nodejs 等)提供服务的服务器代理所有后端调用

Proxy all the backend calls through the server which serves your web app (nginx/nodejs etc)

优势 这种方法是，您将避免所有同源策略/CORS 问题，您的微服务(快速)身份验证详细信息将从用户的浏览器中抽象出来.(这不一定是优势).

Advantage of this approach is, you will avoid all the Same Origin Policy/CORS headaches, your microservice (express) authentication details will be abstracted out from user's browser. (This is not necessarily an advantage).

缺点 这种方法的缺点是，您的后端微服务将与前端紧密耦合(反之亦然，取决于您如何看待它)，这将使后端依赖在前端.您的后端未公开.因此，如果您有另一个消费者(假设是一个 Android 应用)，它将无法访问您的服务.

Disadvantage of this approach is, your backend microservice will have a tight coupling with front end (or vice-versa depending on how you look at it), This will make the scaling of backend dependent on front end. Your Backend is not exposed. So, if you have another consumer (let's just say an android app) it will not be able to access your service.

通过为您的 web 应用程序(nginx/nodejs 等)提供服务的服务器代理所有后端调用，以便您的 API 将继承您的 webapps 域.并且仍然公开后端服务(在需要时)，以便其他消费者(如果有的话，将来)可以使用它.

Proxy all the backend calls through the server which serves your web app (nginx/nodejs etc) so that your APIs will inherit your webapps domain. And still expose the backend service (as and when required) so that other consumers (if any, in future) can make use of it.

类似的问题:https://stackoverflow.com/a/47043871/6785908

这篇关于如何使用服务名称访问 Kubernetes 集群中的服务.的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！