Kubernetes不解析节点服务

Question

我在Kubernetes内部的DNS/服务解决方案上有问题，我似乎无法追踪这个问题。我有一个api-网关荚运行空，它调用其他服务的内部服务名称，即srv-name.staging.svc.cluster.local。直到最近工作还很顺利。我试图将另外3个服务部署到两个命名空间，即暂存和生产。

第一个服务在调用booking-service.staging.svc.cluster.local时按预期工作，但是相同的代码在生产服务中似乎不起作用。另外两个服务在任何名称空间中都不值得使用。

我得到的行为就是暂停。如果我将这些服务从我的网关荚中压缩，那么除了部署的第一个服务(booking-service.staging.svc.cluster.local)之外，它们都会超时。当我从同一个吊舱内的另一个容器调用这些服务时，它们确实按预期工作。

我为希望向客户端公开的每个服务设置了Node服务。

下面是一个Kubernetes部署示例：

---

# API

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: {{SRV_NAME}}
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: {{SRV_NAME}}
    spec:
        containers:
        - name: booking-api
          image: microhq/micro:kubernetes
          args:
            - "api"
            - "--handler=rpc"
          env:
          - name: PORT
            value: "8080"
          - name: ENV
            value: {{ENV}}
          - name: MICRO_REGISTRY
            value: "kubernetes"
          ports:
          - containerPort: 8080
        - name: {{SRV_NAME}}
          image: eu.gcr.io/{{PROJECT_NAME}}/{{SRV_NAME}}:latest
          imagePullPolicy: Always
          command: [
            "./service",
            "--selector=static"
          ]
          env:
          - name: MICRO_REGISTRY
            value: "kubernetes"
          - name: ENV
            value: {{ENV}}
          - name: DB_HOST
            value: {{DB_HOST}}
          - name: VERSION
            value: "{{VERSION}}"
          - name: MICRO_SERVER_ADDRESS
            value: ":50051"
          ports:
          - containerPort: 50051
            name: srv-port
---

apiVersion: v1
kind: Service
metadata:
  name: booking-service
spec:
  ports:
  - name: api-http
    port: 80
    targetPort: 8080
    protocol: TCP
  selector:
    app: booking-api

我使用Go-microhttps://github.com/micro/go-micro和Kubernetes的预配置。在一种情况下同样有效，但不是所有的。这让我相信这与代码无关。它在当地也很好。

当我从另一个pod执行nslookup时，它解析名称并为内部节点服务找到预期的集群IP。当我尝试cURL那个IP地址时，我会得到相同的超时行为。

我在Google上使用Kubernetes 1.8。

Answer 1

我不明白为什么您认为这是Kubernetes内部DNS /服务解析中的一个问题，因为当您执行DNS查找时，它是有效的，但是如果您查询该IP，则会得到连接超时。

• 如果您将这些服务从荚外卷曲，那么除了部署的第一个服务之外，所有这些服务都会超时，无论您使用的是IP还是域名。
• 当您从同一个吊舱内的另一个容器调用这些服务时，它们确实按预期工作。

这似乎是一个问题与连接之间的豆荚，而不是一个DNS问题，因此，我会集中你的疑难解答朝这个方向，但纠正我，如果我是错的。

您能否执行传统的网络故障诊断(ping、telnet、traceroute)，从一个吊舱到DNS查找所提供的IP，并从一个容器中将超时时间分配给其他一个豆荚，并根据结果更新问题？