kubernetes DNS pod name resolution

Я пытаюсь получить разрешение имен подов dns, работающее на моем кластере EKS Kubernetes v1.10.3. Я понимаю, что создание автономной службы создаст необходимые мне записи имен модулей, но я считаю, что это не так. Я что-то упускаю?

Также открыты для других идей о том, как заставить это работать. Не удалось найти альтернативного решения.

Добавление обновления

Я не был достаточно ясным. По сути, мне нужно решить как таковое: worker-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

person sebastian    schedule 31.08.2018    source источник
comment
Есть ли конкретная причина, по которой служба DNS не работает для вас?   -  person yosefrow    schedule 31.08.2018
comment
@yosefrow Извините, я не совсем понял. По сути, мне нужно разрешить как таковое: worker-767cd94c5c-c5bq7 - ›10.0.10.10 worker-98dcd94c5d-cabq6 -› 10.0.10.11 и так далее .... Мне действительно не нужен циклический DNS, просто прочтите где-нибудь что это может быть работа. Спасибо!   -  person sebastian    schedule 31.08.2018
comment
Хотя верно, что службы поддерживают циклический перебор, есть ли причина, по которой вы должны ссылаться на модуль по точному имени модуля, а не по общему имени службы, которое сопоставляется с конкретным модулем с помощью селекторов меток на основе 1 к 1?   -  person yosefrow    schedule 02.09.2018
comment
@sebastian, тебе удалось заставить это работать? то есть разрешение DNS имени пода? Есть несколько проектов apache, которые пытаются разрешить имена модулей и сталкиваются с той же проблемой.   -  person victtim    schedule 29.01.2019
comment
@sebastian Привет, мне помог мой ответ? Я заметил, что вы еще не приняли ответ. Есть ли способ улучшить свой ответ, чтобы он соответствовал вашему конкретному сценарию?   -  person yosefrow    schedule 02.06.2020


Ответы (1)


Внутри я предлагаю использовать записи DNS службы, чтобы указать на модуль, который, как вы уже подтвердили, работает. Это, конечно, не требует наличия службы Headless для использования службы DNS.

Автоматические записи kube-dns работают следующим образом:

pod -> service в том же пространстве имен: curl http://servicename

pod -> service в другом пространстве имен: 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-ingress https://github.com/kubernetes/ingress-nginx

РЕДАКТИРОВАТЬ: включить подробную информацию о фактическом DNS модуля

v1.2 представляет бета-функцию, в которой пользователь может указать аннотацию Pod, pod.beta.kubernetes.io/subdomain, чтобы указать поддомен Pod. Последний домен будет «... svc.». Например, Pod с аннотацией имени хоста, установленной на «foo», и аннотацией поддомена, установленной на «bar», в пространстве имен «my-namespace» будет иметь полное доменное имя «foo.bar.my-namespace.svc.cluster». местный"

A Записи и имя хоста на основе полей имени хоста и поддомена модуля. В настоящее время, когда модуль создается, его имя хоста является значением metadata.name модуля.

В версии 1.2 пользователи могут указать аннотацию Pod, pod.beta.kubernetes.io/hostname, чтобы указать, каким должно быть имя хоста Pod. Аннотация модуля, если она указана, имеет приоритет над именем модуля и является именем хоста модуля. Например, для модуля Pod с аннотацией pod.beta.kubernetes.io/hostname: my-pod-name для Pod будет установлено имя хоста «my-pod-name».

В версии 1.3 PodSpec имеет поле имени хоста, которое можно использовать для указания имени хоста Pod. Значение этого поля имеет приоритет над значением аннотации pod.beta.kubernetes.io/hostname.

v1.2 представляет бета-функцию, в которой пользователь может указать аннотацию Pod, pod.beta.kubernetes.io/subdomain, чтобы указать поддомен Pod. Последний домен будет «... svc.». Например, Pod с аннотацией имени хоста, установленной на «foo», и аннотацией поддомена, установленной на «bar», в пространстве имен «my-namespace» будет иметь полное доменное имя «foo.bar.my-namespace.svc.cluster». местный"

В версии 1.3 в PodSpec есть поле поддомена, которое можно использовать для указания поддомена пода. Значение этого поля имеет приоритет над значением аннотации pod.beta.kubernetes.io/subdomain.

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

person yosefrow    schedule 31.08.2018