如何在 Kubernetes 中注册和查找 Deployment 中的单个 pod 主机名? [英] How do I get individual pod hostnames in a Deployment registered and looked up in Kubernetes?

查看：34
本文介绍了如何在 Kubernetes 中注册和查找 Deployment 中的单个 pod 主机名?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我需要知道 Kubernetes 中部署中所有 pod 的所有主机名.

I need to know all the hostnames for all the pods in a Deployment in 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 注册任何 Pod
  2. 如果我确实添加了主机名值，则 DNS 中只有一个条目

我怎样才能注册部署中的每个 pod，最好使用 pod 名称，并通过 pod 的 fqdn 查找 - 例如pod_name.subdomin.namespace.svc.cluster.local?

How can I get every pod in a deployment to be registered, preferably using the pod name, and looked up by fqdn of the pod - e.g. pod_name.subdomin.namespace.svc.cluster.local?

推荐答案

CoreDNS 仅为服务创建 A 和 SRV 记录.它不会像阅读文档:

CoreDNS creates A and SRV records only for Services. It doesn't generate pods' A records as you may expect after reading the documentation:

pods insecure 选项用于向后兼容 kube-dns.您可以使用 pods Verified 选项，该选项仅在同一命名空间中存在具有匹配 IP 的 pod 时才返回 A 记录.如果您不使用 pod 记录，则可以使用 pods disabled 选项.

The pods insecure option is provided for backward compatibility with kube-dns. You can use the pods verified option, which returns an A record only if there exists a pod in same namespace with matching IP. The pods disabled option can be used if you don’t use pod records.

有一个例外:如果您创建了一个无头服务(当您在服务规范中指定 ClusterIP: None 时)

with the one exception: if you create a Headless service (when you specify ClusterIP: None in the Service spec)

所以，这是我基于您的 YAML 的无头服务示例:

So, here is my example of Headless Service based on your YAML:

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

以下是在我的集群上通过上述部署创建的 pod 列表:

Here is the list of pods created by the above deployment on my cluster:

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 记录，而不是 Service 的 ClusterIP 的一条 A 和一条 SRV 记录，它们具有相同的名称，以及作为 Headless Service 端点的 Pod 的 IP 地址:

In this case, instead of one A and one SRV record for Service's ClusterIP, we have two A and two SRV records with the same name, and IP addresses of Pods which are Endpoints for the Headless Service:

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 记录，还为两个 Headless Service 端点创建了 A 记录.

To resolve SRV records, A records also has been created for both Headless Service endpoints.

如果您没有为 pod 指定指定 hostname 和 subdomain，则将创建 A 记录，其中 IP 地址作为主机名:

If you don't specify specify hostname and subdomain for pods, A records will be created with IP addresses as a hostnames:

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

但是如果你同时指定了它们，你会得到如下的记录:

But if you are specify both of them you will get these record as follows:

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 记录将如下所示(是的，仍然有两个并且它们是相同的):

SRV records will look as follows in this case (yes, there are still two of them and they are the same):

_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地址正在改变):

CoreDNS server resolve such records in "random" way (IP addresses is changing):

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 plugin.要启用它，您应该将 transfer to * 行添加到 coredns ConfigMap.为了安全，您可以将 * 替换为特定的 IP.示例:

To debug it, I've used zone transfer plugin of CoreDNS. To enable it you should add transfer to * line to coredns ConfigMap. You can replace * with specific IP for security. Example:

$ 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) (older coredns versions)
          transfer {      <----- ( new syntax for recent coredns versions)
              to *        <----- ( don't use older and newer transfer options in the same config! )
          }               <----- ( and check coredns pods' logs to ensure it applied correctly )
          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

之后，您将能够使用以下命令列出 cluster.local 区域中的所有 DNS 记录:

After that you'll be able to list all DNS records from cluster.local zone using the following command:

dig -t AXFR cluster.local any

可以在此处找到更多信息:

More information can be found here:

这篇关于如何在 Kubernetes 中注册和查找 Deployment 中的单个 pod 主机名?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆