Служба K8s не проверяется

У меня есть служба / развертывание k8s в кластере minikube (имя amq в пространстве имен default:

D20181472:argo-k8s gms$ kubectl get svc --all-namespaces
NAMESPACE     NAME         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
argo          argo-ui      ClusterIP      10.97.242.57     <none>        80/TCP            5h19m
default       amq          LoadBalancer   10.102.205.126   <pending>     61616:32514/TCP   4m4s
default       kubernetes   ClusterIP      10.96.0.1        <none>        443/TCP           5h23m
kube-system   kube-dns     ClusterIP      10.96.0.10       <none>        53/UDP,53/TCP     5h23m

Я развернул infoblox / dnstools и попробовал nslookup, dig и ping из amq.default со следующими результатами:

dnstools# nslookup amq.default
Server:     10.96.0.10
Address:    10.96.0.10#53

Name:   amq.default.svc.cluster.local
Address: 10.102.205.126

dnstools# ping amq.default
PING amq.default (10.102.205.126): 56 data bytes
^C
--- amq.default ping statistics ---
28 packets transmitted, 0 packets received, 100% packet loss
dnstools# dig amq.default

; <<>> DiG 9.11.3 <<>> amq.default
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15104
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;amq.default.           IN  A

;; Query time: 32 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Sat Jan 26 01:58:13 UTC 2019
;; MSG SIZE  rcvd: 29

dnstools# ping amq.default
PING amq.default (10.102.205.126): 56 data bytes
^C
--- amq.default ping statistics ---
897 packets transmitted, 0 packets received, 100% packet loss

(NB: пинг IP-адреса напрямую дает тот же результат)

По общему признанию, я не очень осведомлен о глубокой работе DNS, поэтому я не уверен, почему я могу выполнять поиск и копать имя хоста, но не пинговать его.


kubernetes minikube nslookup coredns ping
person horcle_buzz    schedule 26.01.2019    source источник
comment
Для работы ping служба должна прослушивать ICMP-запрос   -  person horcle_buzz    schedule 26.01.2019

Ответы (2)


arrow_upward
10
arrow_downward

По общему признанию, я не очень осведомлен о глубокой работе DNS, поэтому я не уверен, почему я могу выполнять поиск и копать имя хоста, но не пинговать его.

Потому что Service IP-адреса являются плодом воображения вашего кластера, вызваны либо iptables, либо ipvs, и на самом деле не существуют. Вы можете увидеть их с iptables -t nat -L -n на любом узле, на котором запущен kube-proxy (или ipvsadm -ln), как описано в полезном Страница отладки [-ing] Services

Поскольку они не являются настоящими IP-адресами, привязанными к фактическим сетевым адаптерам, они не отвечают ни на какой трафик, кроме номеров портов, зарегистрированных в ресурсе Service. Правильный способ проверки возможности подключения к службе - это использовать что-то вроде curl или netcat и использовать номер порта, через который вы ожидаете, что трафик приложения будет перемещаться.

person mdaniel    schedule 26.01.2019
comment
Спасибо. Тестирование с портом - это именно то, что мне нужно. - person horcle_buzz; 26.01.2019

arrow_upward
1
arrow_downward

Это связано с тем, что IP-адрес кластера службы является виртуальным IP-адресом и имеет значение только в сочетании с портом службы.

Всякий раз, когда служба создается сервером API, ей немедленно назначается виртуальный IP-адрес, и после этого сервер API уведомляет все агенты kube-proxy, работающие на рабочих узлах, о создании новой службы. Затем задача kube-proxy - сделать эту службу адресуемой на узле, на котором она работает. kube-proxy делает это, устанавливая несколько правил iptables, которые обеспечивают перехват каждого пакета, предназначенного для пары IP / порт службы, и изменение адреса назначения, поэтому пакет перенаправляется на один из модулей, поддерживающих службу.

IP и VIP

person Vikram Jakhar    schedule 26.01.2019