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

问题描述

我对kubernetes来说还很陌生，我已经在Google容器引擎上成功设置了一个集群. 在我的集群中，我有一个用dropwizard开发的后端api，一个用node js和mysql数据库开发的前端api. 所有这些都已部署到集群并且可以正常工作.但是，在为节点容器和后端设置外部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/login 净:: ERR_NAME_NOT_RESOLVED.有趣的是，当我curl缩时 它的前端吊舱有效.但是当我使用我的网络访问它时 浏览器没有

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屋！