相关疑难解决方法(0)

我在 kubernete 和 docker 中使用微服务，UnknownHostException当 Zuul（网关）将请求数据转发到服务时，我无法通过 pod 名称 ping 到服务容器（但是当我使用 docker swarm 而不是 Kubernetes 时，我可以正常通过主机名 ping )

这是我的服务 yaml 文件

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: merchantservice
  labels:
    run: merchantservice
spec:
  template:
    metadata:
      labels:
        name: merchantservice
    spec:
      containers:
      - name: merchantservice
        image: merchantservice:latest
        ports:
        - containerPort: 8001
        env:
          - name: EUREKA_SERVER
            value: "eureka1"
          - name: EUREKA_SERVER2
            value: "eureka2"
          - name: CONFIG_SERVER
            value: "configserver"
---
apiVersion: v1
kind: Service
metadata:
  name: merchantservice
spec:
  selector:
    name: merchantservice
  ports:
    - port: …

我们在 kubernetes 集群上启动并运行了 Zuul 和 Eureka。Zuul 在 Eureka 注册。

我启动了一个名为“Resource-Service”的新服务，它可以正确启动并在 Eureka 注册，所有服务都已启动。

当我尝试点击 Zuul 端点以访问“资源服务”时，出现以下错误。即使资源服务已在 eureka 注册，似乎 Zuul 也无法映射到 Resource-service。

那么如果不是通过 eureka 中的注册服务，zuul 如何知道将“资源服务”的请求路由到哪里？

注意：我已经用 Docker-compose 尝试过这个并且能够开始工作，所以一定是 kubernetes 与 zuul 和 eureka 交互。

Zuul 堆栈跟踪（更新）

2018-08-29 14:23:15.820  INFO 7 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_ZUUL-API-GATEWAY/zuul-api-gateway-79bd7d4c5-jgqxc:zuul-api-gateway:7100: registering service...
2018-08-29 14:23:15.916  INFO 7 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_ZUUL-API-GATEWAY/zuul-api-gateway-79bd7d4c5-jgqxc:zuul-api-gateway:7100 - registration status: 204
2018-08-29 14:23:15.928  INFO 7 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 7100 (http) with context path ''
2018-08-29 14:23:15.929 …

我们使用Spring Cloud Netflix提供了一系列使用Spring Boot构建的微服务。到目前为止，它们已打包为RPM并已部署到VM。显然，使用Eureka可以进行服务注册/发现，并且我们的跨微服务交互可以使用带有虚拟IP（VIP）的Spring RestTemplate完成，如下所示：

http://foo-service/<PATH_TO_RESOURCE>

客户端负载平衡是另一个好处。

现在，我们希望使用Docker并在Rancher中运行。我想知道在这种环境下使用Eureka还是有意义的。

在Rancher中，如果该服务名为“ foo-service”，则该名称将用作Rancher内部网络中的VIP，因此，上面显示的相同URL也可以使用，Eureka除外。

此外，如果有多个容器支持服务，则Rancher将在其中循环负载均衡流量。

另外，似乎Rancher会比Eureka更早地了解Containers的来来往往。

我正在努力寻找保留尤里卡的坚实理由。