K8s - 不同命名空间中 pod 之间的 DNS 解析

Question

我在名为 "a" 的命名空间中有一个简单的 pod， 以及命名空间中的另一个 pod "b"...

我还有一个测试脚本，可以从"a" 向"b" 进行grpc 调用。

1. 此脚本在使用 FQDN（例如“some-service.b.cluster.local”）时不起作用
2. 如果使用“b”命名空间中 pod 的确切 IP 地址，此脚本确实有效

我想是 DNS 解析中的一些错误， 但我无法真正前进。

有什么帮助吗？

kubectl exec -n a somepod-f647b7d95-mrvfr cat /etc/resolv.conf

nameserver 10.12.0.10
search chimera.svc.cluster.local svc.cluster.local cluster.local c.<company-name>-staging.internal <provider>.internal
options ndots:5

kubectl get pods -n kube-system

event-exporter-v0.2.4-6d4c69fbfb-f4xpf                           1/1     Running   0          24d
fluentd-gcp-scaler-6965bb45c9-mzvw6                              1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-2m2bf                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-2v6bq                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-4xpbc                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-7g5hm                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-8mqvc                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-f9hrs                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-fr58c                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-hzrsb                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-kq8hc                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-kt6p5                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-nsztm                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-qcl4r                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-qggv9                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-qkkp5                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-rm9hn                                         1/1     Running   0          5d5h
fluentd-gcp-v3.2.0-sv52h                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-t75fp                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-v49fv                                         1/1     Running   0          7d6h
kube-dns-6cd7bbdf65-jnntn                                        4/4     Running   0          24d
kube-dns-6cd7bbdf65-txmlj                                        4/4     Running   0          24d
kube-dns-autoscaler-8687c64fc-29jgq                              1/1     Running   0          7d6h
kube-proxy-gke-iceberg-api-v2-201908101259587443-01f0b55b-q0k3   1/1     Running   0          217d
kube-proxy-gke-iceberg-api-v2-201908101259587443-0d661dfb-3zhx   1/1     Running   0          217d
kube-proxy-gke-iceberg-api-v2-201908101259587443-92bbd393-w96w   1/1     Running   1          115d
kube-proxy-gke-iceberg-es-single-202003021919386-1b520a2e-sn9m   1/1     Running   0          5d6h
kube-proxy-gke-iceberg-es-single-202003021919386-bf6046bf-7wsp   1/1     Running   0          5d5h
kube-proxy-gke-iceberg-es-single-202003021919386-d64daa4e-1jqz   1/1     Running   0          5d5h
kube-proxy-gke-iceberg-general-20190810125958886-21ed2623-4m0p   1/1     Running   0          217d
kube-proxy-gke-iceberg-general-20190810125958886-8b185cf9-x1j2   1/1     Running   0          217d
kube-proxy-gke-iceberg-general-20190810125958886-eaf63d3c-k338   1/1     Running   0          217d
kube-proxy-gke-iceberg-kafka-2019081012595876540-429586da-m2qf   1/1     Running   0          217d
kube-proxy-gke-iceberg-kafka-2019081012595876540-76ebb654-z7xx   1/1     Running   0          217d
kube-proxy-gke-iceberg-kafka-2019081012595876540-c3abee6e-4q76   1/1     Running   0          217d
kube-proxy-gke-iceberg-rabbitmq-2019081012595876-552d6676-8z2k   1/1     Running   0          217d
kube-proxy-gke-iceberg-rabbitmq-2019081012595876-662980f7-76jc   1/1     Running   0          217d
kube-proxy-gke-iceberg-rabbitmq-2019081012595876-b269df22-6zqj   1/1     Running   0          217d
kube-proxy-gke-iceberg-redis-2019081012595877180-38264a5e-c0ch   1/1     Running   0          217d
kube-proxy-gke-iceberg-redis-2019081012595877180-9412d5f5-pt3w   1/1     Running   0          217d
kube-proxy-gke-iceberg-redis-2019081012595877180-947dc20b-c002   1/1     Running   0          217d
kube-state-metrics-67b67d8fdd-nkpt4                              2/2     Running   0          24d
l7-default-backend-fd59995cd-cvqwb                               1/1     Running   0          24d
metrics-server-v0.3.1-5c8f664b95-sthjz

Answer 1

根据您的描述，您似乎正在运行 KubeDNS。我给您的第一条建议是向 CoreDNS 发送 migrate，因为 KubeDNS 在 deprecation path 上。

其次，我突然想到了两件事。

1. 您说的是在 pod 之间而不是 services 之间进行调用。虽然 Kubernetes 确实在您的应用程序之间提供服务发现，但正如您所知，它是通过 DNS 来实现的。然而，仅仅因为 pod 可以相互解析doesn't mean，一个容器的端口就会暴露在它的 pod 之外。要做到这一点，即使对于集群中无法解析它的应用程序，您也必须为每个 Pod 或 Controller 声明一个服务资源。

2. 当您谈到进行引用 B pod/服务的 FQDN 的调用时，您没有指定默认的 FQDN 架构，也没有提及对此进行了自定义。

首先，您能否请kubectl get svc -n NAMESPACE 为您的 A 和 B pod 正在运行的两个命名空间，并确认已创建 ClusterIP 类型的服务并且 IP 地址已与该服务相关联？

其次，您可以尝试通过specifying the following FQDN format 尝试从应用程序A 到应用程序B 的服务的连接尝试吗？

some-service.b.svc.cluster.local

注意 svc 部分。您在 OP 中提到了some-service.b.cluster.local。

最后，如果一切恢复正常，我们可以开始故障排除kube-dns。似乎所有三个 pod 都在运行。但是，您是否尝试过describe 他们和/或grab their logs？如果有任何有趣的内容，您可以尝试以下方法并分享摘要吗？

kubectl describe pod -n kube-system kube-dns-6cd7bbdf65-jnntn
kubectl describe pod -n kube-system kube-dns-6cd7bbdf65-txmlj
kubectl describe pod -n kube-system kube-dns-autoscaler-8687c64fc-29jgq

kubectl logs -n kube-system kube-dns-6cd7bbdf65-jnntn
kubectl logs -n kube-system kube-dns-6cd7bbdf65-txmlj
kubectl logs -n kube-system kube-dns-autoscaler-8687c64fc-29jgq

我想logs 命令将为您提供您正在寻找的答案。如果您在此问题上需要任何进一步的说明或帮助，请告诉我。我很乐意提供帮助。