Как получить отдельные имена хостов pod в Deployment, зарегистрированном и найденном в Kubernetes? - PullRequest
Новая
       29

Как получить отдельные имена хостов pod в Deployment, зарегистрированном и найденном в Kubernetes?

0 голосов
/ 02 февраля 2019

Мне нужно знать все имена хостов для всех модулей в Deployment в Kubernetes.

На основе https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/, Я пытался: 

apiVersion: v1
kind: Service
metadata:
  name: default-subdomain
spec:
  selector:
    name: busybox
  clusterIP: None
  ports:
  - name: foo
    port: 1234
    targetPort: 1234
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox1
  labels:
    name: busybox
spec:
  replicas: 2
  selector:
    matchLabels:
      name: busybox
  template:
    metadata:
      labels:
        name: busybox
    spec:
      hostname: dummy <---- effect of this line 
      subdomain: default-subdomain
      containers:
      - image: busybox
        command:
          - sleep
          - "99999"
        name: busybox
        stdin: true
        tty: true
  1. Если я не добавлю имя хоста, ни один модуль не будет зарегистрирован в DNS
  2. Если я добавлю значение имени хоста, в DNS будет только одна запись

Как я могу зарегистрировать каждый модуль в развертывании, предпочтительно с использованием имени модуля, и просмотреть fqdn измодуль - например, имя_подтипа.subdomin.namespace.svc.cluster.local?

Ответы [ 2 ]

0 голосов
/ 26 июня 2019

CoreDNS создает записи A и SRV только для служб. не генерирует записи модулей A , как вы можете ожидать после прочтения документации :

Опция pods insecure предусмотрена для обратной совместимости сКубэ-СНД.Вы можете использовать опцию pods verified, которая возвращает запись A, только если в том же пространстве имен существует модуль с соответствующим IP-адресом.Опцию pods disabled можно использовать, если вы не используете записи pod.

с одним исключением: если вы создаете Безголовую службу (когда вы указываете ClusterIP: Noneв спецификации службы)

Итак, вот мой пример службы безголовой связи на основе вашего YAML: 

NAME                TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
default-subdomain   ClusterIP      None            <none>        1234/TCP       50s

Вот список модулей, созданных в результате вышеуказанного развертывания в моем кластере: 

NAMESPACE       NAME                                        READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES
default         busybox1-76745fcdbf-4ppsf                   1/1     Running   0          18s   10.244.1.22   kube-node2-1   <none>           <none>
default         busybox1-76745fcdbf-d76q5                   1/1     Running   0          18s   10.244.1.23   kube-node2-1   <none>           <none>

В этом случае вместо одной A и одной записи SRV для ClusterIP службы у нас есть две A и две записи SRV с одинаковым именем и IP-адреса модулей, которые являются конечными точками для службы без заголовка:

default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.22
_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 10-244-1-22.default-subdomain.default.svc.cluster.local.
default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.23
_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 10-244-1-23.default-subdomain.default.svc.cluster.local.

Для разрешения записей SRV также были созданы записи A для обеих конечных точек безголовой службы.

Если вы не укажете, укажите hostname и subdomain для модулей. Записи будут создаваться с IP-адресами в качестве имен хостов: 

10-244-1-22.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.22
10-244-1-23.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.23

Но если вы укажете оба из них, вы получите эти записи следующим образом: 

dummy.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.22
dummy.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.23

В этом случае записи SRV будут выглядеть следующим образом (да,их по-прежнему две, и они одинаковые): 

_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 dummy.default-subdomain.default.svc.cluster.local.
_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 dummy.default-subdomain.default.svc.cluster.local.

Сервер CoreDNS разрешает такие записи «случайным образом» (IP-адреса меняются): 

root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.26) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.26) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.26) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.

Для отладкиэто, я использовал функцию передачи зоны, которую поддерживает CoreDNS.Чтобы включить его, вы должны добавить transfer to * строку к coredns ConfigMap.Вы можете заменить * на конкретный IP для безопасности.Пример: 

$ kubectl get cm coredns -n kube-system -o yaml
apiVersion: v1
data:
 Corefile: |
   .:53 {
       errors
       health
       kubernetes cluster.local in-addr.arpa ip6.arpa {
          transfer to *   <---- enable zone transfer to anyone(don't use in production) 
          pods insecure
          upstream
          fallthrough in-addr.arpa ip6.arpa
       }
       prometheus :9153
       forward . /etc/resolv.conf
       cache 30
       loop
       reload
       loadbalance
   }
kind: ConfigMap
metadata:
 creationTimestamp: "2019-05-07T15:44:02Z"
 name: coredns
 namespace: kube-system
 resourceVersion: "9166"
 selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
 uid: f0646569-70de-11e9-9af0-42010a9c0015

После этого вы сможете просмотреть все записи DNS из зоны cluster.local, используя следующую команду: 

dig -t AXFR cluster.local any

Более подробную информацию можно найти здесь:

0 голосов
/ 02 февраля 2019

, если вы хотите сделать это, подумайте об использовании вместо этого Stateful Set, где вы можете перейти к модулю следующим образом:

podname-{replica-index}.{serviceName}.default.svc.cluster.local

вот пример https://kubernetes.io/docs/tutorials/stateful-application/cassandra/

...