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

查看：173
本文介绍了如何在Kubernetes中注册并查找部署中的各个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记录 .如您在阅读不会生成广告连播的A记录 ="https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#coredns-configmap-options" rel ="noreferrer">文档:

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的容器时才返回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记录，而不是服务的ClusterIP的一个A和一个SRV记录，而Pods的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，将创建​​一个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支持的区域传输功能.要启用它，您应该在 coredns ConfigMap中添加transfer to *行.您可以将*替换为特定的IP以确保安全.示例:

To debug it, I've used zone transfer feature that CoreDNS supports. 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) 
          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:

  • support for zone transfer for kubernetes #1259
  • Feature request: support zone transfers in Kubernetes middleware #660

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

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