我对kubernetes很新，我已经在谷歌容器引擎上成功设置了一个集群。 在我的集群中，我有一个用dropwizard开发的后端api，前端用节点js和一个mysql数据库开发。 所有这些都已经部署到集群并且正在工作。但是我的挑战是在为我的节点容器和后端设置外部ip之后我可以远程访问它们但是我无法使用服务名称从我的前端访问我的支持，例如我的后端在集群中称为backendapi。在部署到群集时，我无法执行此操作http://backendapi:8080来调用我的其他服务。 对我来说，当我部署到集群时，我不希望我的前端使用外部IP命中我的后端，我希望它们在集群内连接，而无需通过外部IP地址。当我连接到一个pod并ping backendapi时它会返回一个结果但是当我部署我的前端并使用标签名称时它不起作用。我可能做错了什么？。
答案 0 :(得分：5)
只要kube-dns正在运行（我相信“除非您禁用它”），所有服务对象都有 in cluster DNS名称service_name +"."+ service_namespace + ".svc.cluster.local"所以所有其他内容都会将backendapi命名空间中的default作为（使用您的端口编号示例）http://backendapi.default.svc.cluster.local:8080。这个事实是Kubernetes迫使所有标识符成为“dns兼容”名称（没有下划线或其他愚蠢字符）的原因。
即使您不运行kube-dns，所有服务名称和端口也会像Docker一样注入Pod的环境中，因此环境变量${BACKENDAPI_SERVICE_HOST}:${BACKENDAPI_SERVICE_PORT}将包含服务的集群内IP（即使env-var命名为“host”）和“默认”服务端口（在您的示例中为8080），如果只有一个。
您是否选择使用DNS名称或环境变量IP是您是否希望在日志输出或错误消息中具有“可读”名称，而不是您是否希望跳过DNS查找和使用服务IP地址获得速度但易读性较差。他们的行为相同。
答案 1 :(得分：3)
但问题 当我改变这一点时仍然存在 backendapi.default.svc.cluster.local：8080。我甚至尝试过使用另一个 它在内部映射到的端口，我的前端网页保持不变 说backendapi.default.svc.cluster.local：32208 / api / v1 / auth / login 净:: ERR_NAME_NOT_RESOLVED。有趣的是，当我从我的身上卷曲时 前端吊舱它的工作原理。但是当我使用我的网络访问它时 浏览器它没有
因为它只能在群集中解析。 （因为只有带有kube-dns附加组件的K8s群集才能将域名backendapi.default.svc.cluster.local：8080转换为相应的IP地址）
这可能是因为我也为该服务公开了外部IP 。外部IP工作正常
不，这是因为域名backendapi.default.svc.cluster.local只能在群集中解析，而不能从随机机器中的随机浏览器解析。
您所做的是解决方案之一，为服务公开外部IP。如果您不想使用IP，可以创建入口（并在群集中使用入口控制器）并公开您的微服务。由于您使用的是GCP，因此您可以使用其API网关，而不是暴露出神秘的IP地址。
注意：请记住添加身份验证/授权以锁定您的微服务，因为它会向用户公开。
通过服务器为您的网络应用程序（nginx / nodejs等）代理所有后端调用
优点这种方法是，您将避免所有同源策略/ CORS头痛，您的微服务（快速）身份验证详细信息将从用户的浏览器中抽象出来。 （这不一定是优势）。
缺点这种方法是，你的后端微服务将与前端紧密耦合（反之亦然，具体取决于你如何看待它），这将使后端的扩展依赖在前端。您的后端未暴露。所以，如果你有另一个消费者（让我们说一个Android应用程序）它将无法访问你的服务。
代理所有后端调用，通过服务器为您的Web应用程序（nginx / nodejs等）提供服务，以便您的API继承您的webapps域。并且仍然暴露后端服务（在需要时），以便其他消费者（如果有的话，将来）可以使用它。