web-dev-qa-db-ja.com

登録された展開で個々のPODホスト名を取得し、Kubernetesで検索するにはどうすればよいですか。

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. ホスト名を追加しない場合は、PODはDNSに登録されていません
  2. ホスト名の値を追加すると、DNSに1つのエントリが1つしかありません。

どのようにして展開されるべきすべてのポッドを登録することができます。 POD_NAME.SUBDOMIN.NAMESPACE.SVC.CLUSTER.LOCAL?

4
Nsen

Corednsは、サービスのためのAとSRVレコードだけを作成しますPod 'のレコードを生成しませんドキュメント

pods insecureオプションは、kube-dnsとの下位互換性のために提供されています。 pods verifiedオプションを使用することができます。これは、一致するIPを持つ同じ名前空間にPODが存在する場合にのみ、Aレコードを返すことができます。 PODレコードを使用しない場合は、pods disabledオプションを使用できます。

1つの例外を持つ: ヘッドレスサービス (サービス仕様にClusterIP: Noneを指定したとき)

だから、これがあなたのyamlに基づくヘッドレスサービスの例です:

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

これは、私のクラスター上の上記の展開によって作成されたポッドのリストです。

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>

この場合、サービスのClusterIPの1つのAと1つのSRVレコードの代わりに、同じ名前の2つのAと2つのSRVレコードと、ヘッドレスサービスのエンドポイントであるPODのIPアドレスがあります。

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レコードを解決するには、両方のヘッドレスサービスエンドポイントに対してレコードも作成されています。

指定しない場合は、podの場合はhostnamesubdomainを指定して、レコードがホスト名としてIPアドレスを使用して作成されます。

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

しかし、両方を指定した場合は、次のようにこれらのレコードを取得します。

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レコードは次のように見えます(はい、まだ2つはそれらのうちの2つあり、それらは同じです)。

_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サーバーは、そのようなレコードを "Random" Wayで解決します(IPアドレスは変わります)。

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 to *行をcorednsconfigmapに追加する必要があります。セキュリティの特定のIPに*を置き換えることができます。例:

$ 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レコードをリストすることができます。

Dig -t AXFR cluster.local any

詳細についてはここにあります。

3
VAS

そのようなポッドに行くことができるステートフルセットを代わりに使用することを検討したい場合:

podname-{replica-index}.{serviceName}.default.svc.cluster.local _

ここで例は https://kubernetes.io/docs/tutorials/stateful-Application/cassandra/ です

0
cperez08