Dns Kubernetes未解析节点服务

我在Kubernetes内部的DNS/服务解析方面遇到了问题，我似乎无法跟踪该问题。我有一个运行Kong的api网关pod，它通过内部服务名称调用其他服务，即

srv name.staging.svc.cluster.local

。直到最近，它一直运转良好。我尝试将另外3个服务部署到两个名称空间中，即暂存和生产

第一个服务在调用

booking service.staging.svc.cluster.local

时按预期工作，但是在生产服务中似乎没有相同的代码。另外两个服务在这两个命名空间中都不值得

我的行为是超时。如果我将这些服务从网关pod中卷曲，它们都会超时，除了部署的第一个服务（

booking service.staging.svc.cluster.local

）。当我从同一个pod中的另一个容器调用这些服务时，它们会按预期工作

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

下面是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 micro和Kubernetes的预配置。这同样适用于一种情况，绝对不错，但并非所有其他情况。这让我相信它与代码无关。它在本地也能正常工作

当我从另一个pod执行

nslookup

时，它会解析名称并按预期查找内部节点服务的集群IP。当我尝试卷曲该IP地址时，我会得到相同的超时行为

---

我正在谷歌云上使用Kubernetes 1.8

我不明白为什么您认为这是Kubernetes内部DNS/服务解决方案的问题，因为当您执行DNS查找时，它可以工作，但如果您查询该IP，则会出现连接超时

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

这似乎是POD之间的连接问题，而不是DNS问题，所以我会将您的故障排除重点放在这个方向上，但如果我错了，请纠正我

您是否可以从一个pod向DNS查找提供的IP执行经典的网络故障排除（ping、telnet、traceroute），以及从一个容器向另一个pod提供超时，并用结果更新问题