5

Faced the following issue: I need to add a search domain on some pods to be able to communicate with headless service. Kubernetes documentation recommends to set a dnsConfig and set everything in it.That's what I did. Also there is a limitation that only 6 search domains can be set. Part of the manifest:

    spec:
  hostname: search
  dnsPolicy: ClusterFirst
  dnsConfig:
    searches:
      - indexer.splunk.svc.cluster.local
  containers:
  - name: search

Unfortunately it has no effect and resolv.conf file on targeted pod doesn't include this search domain:

search splunk.svc.cluster.local svc.cluster.local cluster.local us-east4-c.c.'project-id'.internal c.'project-id'.internal google.internal
nameserver 10.39.240.10
options ndots:5

After a quick look at this config I found that currently there are 6 search domens are specified and probably this is the reason why new search domain is not added. You can add manually and everything will work,but this isn't what I 'm trying to achieve.

Do you have any ideas how to bypass this limitation?

P.S Set dnsPolicy to None is not an option also as set prestart hooks to add my search zone.

---
# Search-head deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: search
  namespace: splunk
  labels:
    app: splunk
spec:
  replicas: 1
  selector:
    matchLabels:
      app: splunk
  template:
    metadata:
      labels:
        app: splunk
    spec:
      hostname: search
      dnsPolicy: ClusterFirst
      dnsConfig:
        searches:
          - indexer.splunk.svc.cluster.local
      containers:
      - name: search
        image: splunk/splunk
        env:
          - name: SPLUNK_START_ARGS
            value: "--accept-license"
          - name: SPLUNK_PASSWORD
            valueFrom:
              secretKeyRef:
                name: splunk-password
                key: password
          - name: SPLUNK_ROLE
            value: splunk_search_head
          - name: SPLUNK_SEARCH_HEAD_URL
            value: search
          - name: SPLUNK_INDEXER_URL # TODO: make this part dynamic.
            value: indexer-0,indexer-1
        ports:
          - name: web
            containerPort: 8000
          - name: mgmt
            containerPort: 8089
          - name: kv
            containerPort: 8191
        volumeMounts:
        - mountPath: /opt/splunk/var
          name: sh-volume
      volumes:
      - name: sh-volume
        persistentVolumeClaim:
          claimName: sh-volume
DavidGreen55
  • 173
  • 2
  • 13
  • Welcome to Stack! Can you post the entire yaml? your indentation seems to be wrong, redact any information you need, but I need to see the structure, also add your GKE version. – Will R.O.F. Mar 03 '20 at 15:30
  • Thanks @willrof! Manifest was added. GKE version is 1.14.10-gke.17 I think that structure is ok,the problem was how I paste it here. – DavidGreen55 Mar 03 '20 at 18:13
  • thanks for the info, this looks like a very unique issue, it probably is related to glibc versions. I have a partial answer, I'm posting it but as soon I finish researching I'll post an update. – Will R.O.F. Mar 03 '20 at 18:34
  • Let's continue in the [chat](https://chat.stackoverflow.com/rooms/208970/discussion-between-willrof-and-davidgreen55) whenever you are online. – Will R.O.F. Mar 04 '20 at 16:13

1 Answers1

2

According to Pods DnsConfig Documentation:

searches: a list of DNS search domains for hostname lookup in the Pod. This property is optional. When specified, the provided list will be merged into the base search domain names generated from the chosen DNS policy. Duplicate domain names are removed. Kubernetes allows for at most 6 search domains.

  • Even though resolv.conf docs mention it accepts more than 6 search domains on latest versions, it's not yet possible to surpass this number of search domains through kubernetes deployment.

  • I created a workaround on which an InitContainer creates and mount to the pod a new resolv.conf and after the container is up it replaces the automatically generated one. This way if the container crashes or gets rebooted the resolv.conf will always be reinforced.

nginx-emulating-your-splunk-deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: search
  namespace: default
  labels:
    app: splunk
spec:
  replicas: 1
  selector:
    matchLabels:
      app: splunk
  template:
    metadata:
      labels:
        app: splunk
    spec:
      hostname: search
      initContainers:
        - name: initdns
          image: nginx
          imagePullPolicy: IfNotPresent
          command: ["/bin/bash","-c"] 
          args: ["echo -e \"nameserver 10.39.240.10\nsearch indexer.splunk.svc.cluster.local splunk.svc.cluster.local svc.cluster.local cluster.local us-east4-c.c.'project-id'.internal c.'project-id'.internal google.internal\noptions ndots:5\n \" > /mnt/resolv.conf"]
          volumeMounts:
          - mountPath: /mnt
            name: volmnt      
      containers:
        - name: search
          image: nginx
          env:
          - name: SPLUNK_START_ARGS
            value: "--accept-license"
          - name: SPLUNK_PASSWORD
            value: password
          - name: SPLUNK_ROLE
            value: splunk_search_head
          - name: SPLUNK_SEARCH_HEAD_URL
            value: search
          ports:
          - name: web
            containerPort: 8000
          - name: mgmt
            containerPort: 8089
          - name: kv
            containerPort: 8191
          volumeMounts:
          - mountPath: /mnt
            name: volmnt
          command: ["/bin/bash","-c"] 
          args: ["cp /mnt/resolv.conf /etc/resolv.conf ; nginx -g \"daemon off;\""]
      volumes:
      - name: volmnt
        emptyDir: {}
  • Remember to check the following fields and set according to your environment:
    • namespace, nameserver, container.image, container.args

  • Reproduction:
$ kubectl apply -f search-head-splunk.yaml 
deployment.apps/search created

$ kubectl get pods
NAME                      READY   STATUS    RESTARTS   AGE
search-64b6fb5854-shm2x   1/1     Running   0          5m14sa

$ kubectl exec -it search-64b6fb5854-shm2x -- cat /etc/resolv.conf 
nameserver 10.39.240.10
search indexer.splunk.svc.cluster.local splunk.svc.cluster.local svc.cluster.local cluster.local us-east4-c.c.'project-id'.internal c.'project-id'.internal google.internal
options ndots:5

You can see that the resolv.conf stays as configured, please reproduce in your environment and let me know if you find any problem.


EDIT 1:

  • The above scenario is designed for an environment where you need more than 6 search domains.
  • We have to Hardcode the DNS server, but kube-dns service sticks with the same IP during Cluster lifespan and sometimes even after Cluster recreation, it depends on network configuration.

  • If you need 6 or less domains you can just change dnsPolicy to None and skip the InitContainer:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: search
  namespace: splunk
  labels:
    app: splunk
spec:
  replicas: 1
  selector:
    matchLabels:
      app: splunk
  template:
    metadata:
      labels:
        app: splunk
    spec:
      hostname: search
      dnsPolicy: "None"
      dnsConfig:
        nameservers:
          - 10.39.240.10
        searches:
          - indexer.splunk.svc.cluster.local
          - splunk.svc.cluster.local
          - us-east4-c.c.'project-id'.internal
          - c.'project-id'.internal
          - svc.cluster.local
          - cluster.local
        options:
          - name: ndots
          - value: "5"
      containers:
      - name: search
        image: splunk/splunk
...
{{{the rest of your config}}}
Will R.O.F.
  • 3,814
  • 1
  • 9
  • 19
  • Hmm @willrof looks like the appropriate version of glibc is already installed: `$ /lib64/libc.so.6 --version GNU C Library (GNU libc) stable release version 2.28` – DavidGreen55 Mar 03 '20 at 19:41
  • This was output from splunk container – DavidGreen55 Mar 03 '20 at 19:48
  • Thank you for the confirmation. That's what I'm researching now. You mentioned you can't set to none the dnsPolicy, it would be a quick way to bypass this. Looks like the problem is during the processing of the yaml into a pod, something is not creating the resolv.conf correctly inside the pod, I'm looking up to which component is the responsible for this because even when I set the policy to none, I can't set manually 7 search domains, I'm looking into it too. – Will R.O.F. Mar 03 '20 at 19:48
  • Yep I saw that you can set dnsPolicy to none and after it's posible to adjust resolv.conf according to your requirements, but as I understand you need to hardcode ip address of the nameserver therefore I'm not happy with this solution. – DavidGreen55 Mar 03 '20 at 19:57
  • Going to check how to set a debug mode in dns server. Probably it'll give some information. – DavidGreen55 Mar 03 '20 at 19:59
  • I added my search domain directly in the container /etc/resolv.conf and after it I could ping targeted hosts. – DavidGreen55 Mar 03 '20 at 20:07
  • I'll still reach for the official information about dnsConf, but inserting the search domain in your container creation process is a solid workaround. I believe that "more than 6 search domains" have not been yet implemented in kubernetes. – Will R.O.F. Mar 03 '20 at 20:09
  • If you do changes manually to resolv.conf container will restart,don't understand why but saw it every time after restart. PostStart hooks/dnsPolicy: None are the only ways I see now to resolve the issue. – DavidGreen55 Mar 03 '20 at 20:23
  • Thanks a lot for your help @willrof ! – DavidGreen55 Mar 03 '20 at 20:24
  • Small updates: 1. Upgrading to 1.15.9 didn't help 2. postStart script has an issue with modifying resolv.conf – DavidGreen55 Mar 03 '20 at 21:51
  • @DavidGreen55 Thank you for these updates. It's really valuable for troubleshooting. – Will R.O.F. Mar 03 '20 at 22:09
  • @DavidGreen55 One thing that is not very clear to me yet is that your resolv.conf is showing only 5 servers, hence it could accept the sixth item. Could you check it? – Will R.O.F. Mar 04 '20 at 00:07
  • thanks for your attention. Pasted not all search domains,latest was google.interrnal – DavidGreen55 Mar 04 '20 at 05:06
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/208970/discussion-between-willrof-and-davidgreen55). – Will R.O.F. Mar 04 '20 at 09:30