【问题标题】:kubernetes DNS pod name resolutionKubernetes DNS pod 名称解析
【发布时间】:2019-02-06 00:52:21
【问题描述】:

我正在尝试在我的 EKS Kubernetes 集群 v1.10.3 上进行 dns pod 名称解析。我的理解是,创建无头服务将创建我需要的必要 pod 名称记录,但我发现这不是真的。我错过了什么吗?

也对如何使其发挥作用的其他想法持开放态度。找不到替代解决方案。

添加更新

我还不够清楚。基本上我需要这样解决: 工人 767cd94c5c-c5bq7 -> 10.0.10.10 worker-98dcd94c5d-cabq6 -> 10.0.10.11 等等……

我真的不需要循环 DNS,只是在某个地方读到这可能是一种解决方法。谢谢!

# my service
apiVersion: v1
kind: Service
metadata:
  ...
  name: worker
  namespace: airflow-dev
  resourceVersion: "374341"
  selfLink: /api/v1/namespaces/airflow-dev/services/worker
  uid: 814251ac-acbe-11e8-995f-024f412c6390
spec:
  clusterIP: None
  ports:
  - name: worker
    port: 8793
    protocol: TCP
    targetPort: 8793
  selector:
    app: airflow
    tier: worker
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}





# my pod
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: 2018-08-31T01:39:37Z
  generateName: worker-69887d5d59-
  labels:
    app: airflow
    pod-template-hash: "2544381815"
    tier: worker
  name: worker-69887d5d59-6b6fc
  namespace: airflow-dev
  ownerReferences:
  - apiVersion: extensions/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: worker-69887d5d59
    uid: 16019507-ac6b-11e8-995f-024f412c6390
  resourceVersion: "372954"
  selfLink: /api/v1/namespaces/airflow-dev/pods/worker-69887d5d59-6b6fc
  uid: b8d82a6b-acbe-11e8-995f-024f412c6390
spec:
  containers:
  ...
  ...
    name: worker
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
      ...
      ...
  dnsPolicy: ClusterFirst
  nodeName: ip-10-0-1-226.us-west-2.compute.internal
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: airflow
  serviceAccountName: airflow
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
    ...
    ...
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2018-08-31T01:39:37Z
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: 2018-08-31T01:39:40Z
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: 2018-08-31T01:39:37Z
    status: "True"
    type: PodScheduled
  containerStatuses:
  ...
  ...
    lastState: {}
    name: worker
    ready: true
    restartCount: 0
    state:
      running:
        startedAt: 2018-08-31T01:39:39Z
  hostIP: 10.0.1.226
  phase: Running
  podIP: 10.0.1.234
  qosClass: BestEffort
  startTime: 2018-08-31T01:39:37Z





# querying the service dns record works!
airflow@worker-69887d5d59-6b6fc:~$ nslookup worker.airflow-dev.svc.cluster.local
Server:   172.20.0.10
Address:  172.20.0.10#53

Name: worker.airflow-dev.svc.cluster.local
Address: 10.0.1.234





# querying the pod name does not work :(
airflow@worker-69887d5d59-6b6fc:~$ nslookup worker-69887d5d59-6b6fc.airflow-dev.svc.cluster.local
Server:   172.20.0.10
Address:  172.20.0.10#53

** server can't find worker-69887d5d59-6b6fc.airflow-dev.svc.cluster.local: NXDOMAIN

airflow@worker-69887d5d59-6b6fc:~$ nslookup worker-69887d5d59-6b6fc.airflow-dev.pod.cluster.local
Server:   172.20.0.10
Address:  172.20.0.10#53

*** Can't find worker-69887d5d59-6b6fc.airflow-dev.pod.cluster.local: No answer

【问题讨论】:

  • 是否有特定原因导致服务 DNS 不适合您?
  • @yosefrow 抱歉,我还不够清楚。基本上我需要这样解决:worker-767cd94c5c-c5bq7 -> 10.0.10.10 worker-98dcd94c5d-cabq6 -> 10.0.10.11 等等....我真的不需要循环 DNS 只是在某处读取这可能是一种解决方法。谢谢!
  • 虽然服务确实支持轮询,但是否有理由为什么必须通过确切的 pod 名称而不是通过标签映射到特定 pod 的通用服务名称来引用 pod一对一的选择器?
  • @sebastian 你能让这个工作吗?即 pod 名称的 dns 解析?有一些 apache 项目试图解析 pod 名称并遇到同样的问题。
  • @sebastian 嗨,我的回答有帮助吗?我注意到你还没有接受答案。有什么方法可以改进我的答案以适应您的具体情况吗?

标签: kubernetes kube-dns


【解决方案1】:

在内部,我建议使用服务 DNS 记录指向您已经确认有效的 pod。这当然不需要你有 Headless 服务来使用服务 DNS。

kube-dns 自动记录的工作方式如下:

pod -> 同一命名空间中的服务:curl http://servicename

pod -> 不同命名空间中的服务:curl http://servicename.namespace

在此处阅读有关服务发现的更多信息:https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables

您可以在此处阅读有关服务的 DNS 记录的更多信息https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#services

如果您需要外部自定义名称解析,我建议使用 nginx-ingress:

https://github.com/helm/charts/tree/master/stable/nginx-ingresshttps://github.com/kubernetes/ingress-nginx

编辑:包括有关实际 pod DNS 的详细信息

v1.2 引入了 beta 功能,用户可以指定 Pod 注释 pod.beta.kubernetes.io/subdomain 来指定 Pod 的子域。最终域将是“...svc.”。例如,在命名空间“my-namespace”中,主机名注释设置为“foo”,子域注释设置为“bar”的 Pod 将具有 FQDN“foo.bar.my-namespace.svc.cluster”。本地”

基于 Pod 的主机名和子域字段的记录和主机名 当前创建 Pod 时,其主机名是 Pod 的 metadata.name 值。

在 v1.2 中,用户可以指定 Pod 注解, pod.beta.kubernetes.io/hostname,指定Pod的主机名 应该。 Pod 注解(如果指定)优先于 Pod 的名称,作为 pod 的主机名。例如,给定一个 Pod 带有注解 pod.beta.kubernetes.io/hostname: my-pod-name, Pod 将其主机名设置为“my-pod-name”。

在 v1.3 中,PodSpec 有一个主机名字段,可用于 指定 Pod 的主机名。此字段值优先于 pod.beta.kubernetes.io/hostname 注解值。

v1.2 引入了一个 beta 功能,用户可以指定一个 Pod 注解,pod.beta.kubernetes.io/subdomain,指定 Pod 的 子域。最终域将是“...svc.”。例如,一个 Pod 与 主机名注释设置为“foo”,子域注释设置 到“bar”,在命名空间“my-namespace”中,将具有 FQDN “foo.bar.my-namespace.svc.cluster.local”

在 v1.3 中,PodSpec 有一个 subdomain 字段,可用于 指定 Pod 的子域。此字段值优先于 pod.beta.kubernetes.io/subdomain 注解值。

https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/services-networking/dns-pod-service/

【讨论】:

    猜你喜欢
    • 2018-06-23
    • 1970-01-01
    • 2020-10-03
    • 2023-02-22
    • 1970-01-01
    • 1970-01-01
    • 2020-02-13
    • 2020-06-28
    • 2017-02-13
    相关资源
    最近更新 更多