Блог

Главная - Вопросы по программированию - Kubernetes: ядра и проблема с разрешением имен хостов

Kubernetes: ядра и проблема с разрешением имен хостов

#kubernetes #coredns

#kubernetes #ядра

Вопрос:

У меня есть два модуля kubernetes, работающих через Rancher:

#1 — busybox #2 — dnsutils

Из модуля # 1:

 / # cat /etc/resolv.conf 
nameserver 10.43.0.10
search testspace.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

и затем

 / # nslookup kubernetes.default
Server:    10.43.0.10
Address 1: 10.43.0.10 kube-dns.kube-system.svc.cluster.local

nslookup: can't resolve 'kubernetes.default'
/ # nslookup kubernetes.default
Server:    10.43.0.10
Address 1: 10.43.0.10 kube-dns.kube-system.svc.cluster.local

nslookup: can't resolve 'kubernetes.default'
/ # nslookup kubernetes.default
Server:    10.43.0.10
Address 1: 10.43.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes.default
Address 1: 10.43.0.1 kubernetes.default.svc.cluster.local

так что иногда это работает, но в основном нет.

затем из модуля # 2:

 nameserver 10.43.0.10
search testspace.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

и затем:

 / # nslookup kubernetes.default
;; connection timed out; no servers could be reached

/ # nslookup kubernetes.default
;; connection timed out; no servers could be reached

/ # nslookup kubernetes.default
Server:         10.43.0.10
Address:        10.43.0.10#53

Name:   kubernetes.default.svc.cluster.local
Address: 10.43.0.1
;; connection timed out; no servers could be reached

так что в основном это не работает.

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

Также пытался устранить неполадки на основе статьи из здесь

Карта конфигурации:

 kubectl -n kube-system edit configmap coredns

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  Corefile: |
    .:53 {
        log
        errors
        health {
          lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . "/etc/resolv.conf"
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"Corefile":".:53 {n    errorsn    health {n      lameduck 5sn    }n    readyn    kubernetes cluster.local in-addr.arpa ip6.arpa {n      pods insecuren      fallthrough in-addr.arpa ip6.arpan    }n    prometheus :9153n    forward . "/etc/resolv.conf"n    cache 30n    loopn    reloadn    loadbalancen}n"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"coredns","namespace":"kube-system"}}
  creationTimestamp: "2020-08-07T19:28:25Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:Corefile: {}
      f:metadata:
        f:annotations:
          .: {}
          f:kubectl.kubernetes.io/last-applied-configuration: {}
    manager: kubectl
    operation: Update
    time: "2020-08-24T19:22:17Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "4118524"
  selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
  uid: 1f3615b0-9349-4bc5-990b-7fed31879fa2
~

Есть мысли по этому поводу?

Комментарии:

1. Какую версию Kubernetes вы используете. Его локальная среда или облачная среда? Как насчет модулей в kube-system пространстве имен? Какие-либо проблемы, много перезапусков? Вы настроили брандмауэры?

2. Kubernetes — это 1.18.3, и он локальный. kube-system выглядит стабильно — всего несколько перезапусков для canal (8), но coredsn показывает 0. Брандмауэр на виртуальной машине, где был создан узел, был установлен системными операторами. Я могу пинговать внешний DNS, к которому, но время ожидания истекает, когда CoreDNS пытается связаться с ним.

Ответ №1:

Выяснилось, что kube-dns службе не удалось получить модули CoreDNS

 > kubectl get svc -o wide --namespace=kube-system

NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE   SELECTOR
kube-dns         ClusterIP   10.43.0.10     <none>        53/UDP,53/TCP,9153/TCP   24d   k8s-app=kube-dns

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

 / # nslookup google.com 10.42.1.18 
Server:         10.42.1.18
Address:        10.42.1.18#53

Non-authoritative answer:
Name:   google.com
Address: 172.217.10.110
Name:   google.com
Address: 2607:f8b0:4006:802::200e

и другого узла не было:

 / # nslookup google.com 10.42.2.37
;; connection timed out; no servers could be reached

что может создать проблему для kube-dns службы.

В этом случае я решил перестроить этот проблемный узел, и проблема исчезла.