Can you ping the IP? There might not be any route to that subnet? Have you tried/checked that?
And as far as I know, there is no way. Im not 100% sure what problem you are trying to solve, exactly, though. You can have a service type external, configure kube dns stub domains, but having **the same stub domains** resolve to different NS servers according to the kubernetes namespace the query is executed doesn't seem supported. Not sure it's something useful besides your setup, either :-/ You can probably patch kubedns or something, but not sure it's worth the effort. On Wednesday, September 27, 2017, Simone D'Andreta < simone.dandr...@gmail.com> wrote: > Ah yeah that's a typo.. it's setup as consul.service.domain.io but I > don't know why I cannot ping it - are the service and the endpoint properly > declared? > As per the link you provided - I used the stubDomain and gave the > domain.io name a list of Consul IPs - all good, but this will overwrite > the kube-dns configmap in the kube-system namespace so the new dns > resolution will be per node. I need that per namespace or pod. > Is there anyway I can do that? > Hope it's clear and thanks a lot for your help. > Simone > > Il giorno martedì 26 settembre 2017 22:30:12 UTC+2, Rodrigo Campos ha > scritto: >> >> What I tried to say is using this: http://blog.kubernetes.i >> o/2017/04/configuring-private-dns-zones-upstream-nameservers >> -kubernetes.html?m=1 >> >> in kube-dns configuration. Not sure how your consul name is and, with all >> you said in the previous mail, a service type external will help. >> >> As not even able to ping, not sure what you mean. The service has nothing >> to do with the domain you want to ping, right? Or is that a typo? >> >> On Tuesday, September 26, 2017, Simone D'Andreta <simone....@gmail.com> >> wrote: >> >>> It creates records such as myservice.service.domain.io, so your >>> application must be able to contact a dns forwarder which has the zone for >>> that domain.io. >>> What I am using at the moment are stubdomains to include the domain.io >>> but it's at cluster level. What I need to do is to solve different consul >>> names per namespace or pod. >>> I tried to use a service definition as follows: >>> >>> kind: Service >>> apiVersion: v1 >>> metadata: >>> name: consul-resolution >>> namespace: default >>> spec: >>> type: ExternalName >>> externalName: consul.service.domain.io >>> >>> And an endpoint: >>> kind: Endpoints >>> apiVersion: v1 >>> metadata: >>> name: consulresolution >>> subsets: >>> - addresses: >>> - ip: 10.24.7.26 >>> ports: >>> - port: 8300 >>> >>> But I am not even able to ping consul.service.cnqr.io.. any idea? >>> Thanks >>> >>> Il giorno martedì 26 settembre 2017 16:03:16 UTC+2, Rodrigo Campos ha >>> scritto: >>>> >>>> Sorry, never used consul and I don't follow what you said. >>>> >>>> Does it create records like <service name>.k8s-service that won't work >>>> with just a k8s external type service? >>>> >>>> Then it might be possible to say to kube dns to use some upstream to >>>> some domains, probably? I've not played with it, as I don't need it. But >>>> I'd guess something like that might be possible to do. And use different >>>> domains on apps that need to query different consul clusters? >>>> >>>> On Tuesday, September 26, 2017, Simone D'Andreta <simone....@gmail.com> >>>> wrote: >>>> >>>>> I am afraid it won't work. I will be able to solve >>>>> consul.service.domain but I won't be able to solve external services >>>>> registered within consul, such as mydatabase.service.domain because I need >>>>> a NS record.. unless I can use that CNAME as a NS record, but I don't >>>>> think >>>>> it's the right approach.. >>>>> >>>>> >>>>> Il giorno martedì 26 settembre 2017 10:21:13 UTC+2, Simone D'Andreta >>>>> ha scritto: >>>>>> >>>>>> Hi Rodrigo, >>>>>> ideally we would need this per pod, but I can give it a try with >>>>>> creating a service per namespace. >>>>>> Thanks for the hint, I will let you know how it goes. >>>>>> Simone >>>>>> >>>>>> Il giorno lunedì 25 settembre 2017 18:34:07 UTC+2, Rodrigo Campos ha >>>>>> scritto: >>>>>>> >>>>>>> Sorry, I must be missing something. But if you want to resolve to >>>>>>> different consul clusters in different kubernetes namespaces, can't you >>>>>>> just use a service type external on each? >>>>>>> >>>>>>> You create a service, named as you want them to contact, and is per >>>>>>> ns and returns a CNAME. >>>>>>> >>>>>>> Wouldn't that do the trick? >>>>>>> >>>>>>> On Monday, September 25, 2017, Simone D'Andreta < >>>>>>> simone....@gmail.com> wrote: >>>>>>> >>>>>>>> I need to be able to overwrite the resolv.conf per pods. If I tweak >>>>>>>> the kube-dns configmap, I will have additional nameservers per node, >>>>>>>> not >>>>>>>> per pods. >>>>>>>> The scenario is: I have a kubernetes cluster which is shared >>>>>>>> between different teams, and each team has his own namespace to deploy >>>>>>>> pods. Anyway these pods must be able to communicate with different >>>>>>>> consul >>>>>>>> clusters which are in different environments. Since they are in >>>>>>>> different >>>>>>>> envs, we need to point to different DNS. Since pods get dns resolutions >>>>>>>> from the nodes, but the nodes are shared, we need a way to overwrite >>>>>>>> the >>>>>>>> dns settings per pods. >>>>>>>> I know this is a bad practice - I get what Tim said above in this >>>>>>>> thread - but this is just a proof of concept and we'd like to know >>>>>>>> whether >>>>>>>> there is a way to do this (the cleaner the better :D) >>>>>>>> Thanks >>>>>>>> Simone >>>>>>>> >>>>>>>> Il giorno lunedì 25 settembre 2017 15:15:43 UTC+2, Rodrigo Campos >>>>>>>> ha scritto: >>>>>>>>> >>>>>>>>> Can you explain what do you what to achieve? >>>>>>>>> >>>>>>>>> Maybe changing the configmap kube-dns uses it's enough (and is >>>>>>>>> prepared to be changed easily, now). >>>>>>>>> >>>>>>>>> On Monday, September 25, 2017, Simone D'Andreta < >>>>>>>>> simone....@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Tim, >>>>>>>>>> I know what you mean and that's definitely a big issue on our >>>>>>>>>> side. This is for us more a proof of concept to understand if we can >>>>>>>>>> go >>>>>>>>>> this way. Since I am not a big expert with Kubernetes, I wanted to >>>>>>>>>> know if >>>>>>>>>> there are solutions I haven't considered that might solve my problem. >>>>>>>>>> That said, I thank you a lot for your explanations here. I found >>>>>>>>>> something that can help me, though it sets dns names at node level - >>>>>>>>>> not >>>>>>>>>> per pod: >>>>>>>>>> https://kubernetes.io/docs/tasks/administer-cluster/dns-cust >>>>>>>>>> om-nameservers/ >>>>>>>>>> If I include the different IPs in the stub domains I definitely >>>>>>>>>> should get an answer for the service discovery part. Not ideal, but >>>>>>>>>> I think >>>>>>>>>> better than mounting and overriding the resolv.conf. >>>>>>>>>> Cheers >>>>>>>>>> Simone >>>>>>>>>> >>>>>>>>>> Il giorno venerdì 22 settembre 2017 19:10:01 UTC+2, Tim Hockin ha >>>>>>>>>> scritto: >>>>>>>>>>> >>>>>>>>>>> you're trying to mount a directory (emptyDir) onto a file >>>>>>>>>>> (/etc/resolv.conf). Without seeing the error that is a wild >>>>>>>>>>> guess. I >>>>>>>>>>> can't stop you from doing this, but I strongly encourage you to >>>>>>>>>>> re-read and internalize what I wrote about multiple nameserver >>>>>>>>>>> records. >>>>>>>>>>> >>>>>>>>>>> On Fri, Sep 22, 2017 at 6:19 AM, Simone D'Andreta >>>>>>>>>>> <simone....@gmail.com> wrote: >>>>>>>>>>> > I am trying to mount that volume but my container won't start. >>>>>>>>>>> I guess I am >>>>>>>>>>> > doing something wrong. This is the yaml >>>>>>>>>>> > apiVersion: extensions/v1beta1 >>>>>>>>>>> > kind: Deployment >>>>>>>>>>> > metadata: >>>>>>>>>>> > name: {{ template "fullname" . }} >>>>>>>>>>> > namespace: code >>>>>>>>>>> > labels: >>>>>>>>>>> > chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" >>>>>>>>>>> "_" }}" >>>>>>>>>>> > annotations: >>>>>>>>>>> > commitSHA: {{ .Chart.AppVersion }} >>>>>>>>>>> > isNotifiable : "true" >>>>>>>>>>> > spec: >>>>>>>>>>> > replicas: {{ .Values.replicaCount }} >>>>>>>>>>> > template: >>>>>>>>>>> > metadata: >>>>>>>>>>> > labels: >>>>>>>>>>> > app: {{ template "fullname" . }} >>>>>>>>>>> > >>>>>>>>>>> > spec: >>>>>>>>>>> > >>>>>>>>>>> > containers: >>>>>>>>>>> > - name: {{ .Chart.Name }} >>>>>>>>>>> > image: "{{ .Values.image.repository }}:{{ >>>>>>>>>>> .Values.image.tag }}" >>>>>>>>>>> > imagePullPolicy: {{ .Values.image.pullPolicy }} >>>>>>>>>>> > volumeMounts: >>>>>>>>>>> > - name: new-resolv >>>>>>>>>>> > mountPath: /etc/resolv.conf >>>>>>>>>>> > command: ["/bin/sh"] >>>>>>>>>>> > args: ["-c", "echo nameserver 10.24.26.102 > >>>>>>>>>>> /etc/resolv.conf"] >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > ports: >>>>>>>>>>> > - name: frontend >>>>>>>>>>> > containerPort: {{ .Values.port}} >>>>>>>>>>> > readinessProbe: >>>>>>>>>>> > httpGet: >>>>>>>>>>> > path: {{ .Values.lifecheck }} >>>>>>>>>>> > port: {{ .Values.port}} >>>>>>>>>>> > >>>>>>>>>>> > volumes: >>>>>>>>>>> > - name: new-resolv >>>>>>>>>>> > emptyDir: {} >>>>>>>>>>> > >>>>>>>>>>> > I am using helm to deploy so the variables get expanded via >>>>>>>>>>> Values.yaml or >>>>>>>>>>> > other template files. >>>>>>>>>>> > I think I am just not able to mount that volume properly.. >>>>>>>>>>> > Thanks >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > Il giorno giovedì 21 settembre 2017 19:21:39 UTC+2, Tim Hockin >>>>>>>>>>> ha scritto: >>>>>>>>>>> >> >>>>>>>>>>> >> You'd have to craft a new file and mount it onto your >>>>>>>>>>> resolv.conf, >>>>>>>>>>> >> which makes it harder to "just add another line" because you >>>>>>>>>>> don't >>>>>>>>>>> >> have the base. >>>>>>>>>>> >> >>>>>>>>>>> >> But more than that, what you're asking for is really >>>>>>>>>>> non-standard >>>>>>>>>>> >> behavior. You can't safely add a nameserver record to >>>>>>>>>>> resolv.conf >>>>>>>>>>> >> that produces different results. The behavior of DNS >>>>>>>>>>> resolvers varies >>>>>>>>>>> >> widely, and this will cause you pain eventually (kubernetes >>>>>>>>>>> used to do >>>>>>>>>>> >> this, it was bad). >>>>>>>>>>> >> >>>>>>>>>>> >> Consider this - some resolvers ask all DNS servers in >>>>>>>>>>> parallel, and >>>>>>>>>>> >> take the first response. If one resolver can answer a query >>>>>>>>>>> and >>>>>>>>>>> >> another can't (NXDOMAIN), your app will sometimes get an >>>>>>>>>>> address and >>>>>>>>>>> >> will sometimes fail. This actually happens. >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> On Thu, Sep 21, 2017 at 6:33 AM, Simone D'Andreta >>>>>>>>>>> >> <simone....@gmail.com> wrote: >>>>>>>>>>> >> > Bad news, my idea doesn't work. Could you explain me more >>>>>>>>>>> about the >>>>>>>>>>> >> > volumeMount? I know how to mount but I don't know how I can >>>>>>>>>>> effectively >>>>>>>>>>> >> > add >>>>>>>>>>> >> > a nameserver on that file. >>>>>>>>>>> >> > >>>>>>>>>>> >> > Thanks >>>>>>>>>>> >> > Simone >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> >> > Il giorno giovedì 21 settembre 2017 10:26:48 UTC+2, Simone >>>>>>>>>>> D'Andreta ha >>>>>>>>>>> >> > scritto: >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> Hi Tim, >>>>>>>>>>> >> >> thanks for your answer. I don't actually need to override >>>>>>>>>>> all the >>>>>>>>>>> >> >> settings >>>>>>>>>>> >> >> in the resolv.conf, I just need to add another nameserver >>>>>>>>>>> at the top of >>>>>>>>>>> >> >> the >>>>>>>>>>> >> >> file. How about if I run a command in the pod such as: >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> command: ['/bin/sh', '-c', 'echo 'nameserver x.y.z.w' | >>>>>>>>>>> cat - >>>>>>>>>>> >> >> /etc/resolv.conf > temp && mv temp /etc/resolv.conf'] >>>>>>>>>>> >> >> would it work? >>>>>>>>>>> >> >> Thanks >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> Il giorno mercoledì 20 settembre 2017 17:29:16 UTC+2, Tim >>>>>>>>>>> Hockin ha >>>>>>>>>>> >> >> scritto: >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> There's no supported way to do that, in part because it >>>>>>>>>>> would give up >>>>>>>>>>> >> >>> all of the Service names that kubernetes provides. I >>>>>>>>>>> don't know what >>>>>>>>>>> >> >>> would happen if you tried to volumeMount a file over >>>>>>>>>>> /etc/resolv.conf >>>>>>>>>>> >> >>> - might be worth a shot. >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> On Wed, Sep 20, 2017 at 3:15 AM, Simone D'Andreta >>>>>>>>>>> >> >>> <simone....@gmail.com> wrote: >>>>>>>>>>> >> >>> > Hello, >>>>>>>>>>> >> >>> > I wanted to know if there is a way to override DNS >>>>>>>>>>> settings for pods >>>>>>>>>>> >> >>> > (not >>>>>>>>>>> >> >>> > per cluster). I tried to use HostAliases but it only >>>>>>>>>>> creates an A >>>>>>>>>>> >> >>> > record for >>>>>>>>>>> >> >>> > that entry. I basically need a NS record cause I need >>>>>>>>>>> to point to >>>>>>>>>>> >> >>> > different >>>>>>>>>>> >> >>> > Consul clusters and then Consul must be able to do >>>>>>>>>>> service >>>>>>>>>>> >> >>> > discovery. >>>>>>>>>>> >> >>> > So I >>>>>>>>>>> >> >>> > was thinking to change the resolv.conf for the pod to >>>>>>>>>>> use Consul for >>>>>>>>>>> >> >>> > specific requests. Any idea? >>>>>>>>>>> >> >>> > Thank you, >>>>>>>>>>> >> >>> > Simone >>>>>>>>>>> >> >>> > >>>>>>>>>>> >> >>> > -- >>>>>>>>>>> >> >>> > You received this message because you are subscribed to >>>>>>>>>>> the Google >>>>>>>>>>> >> >>> > Groups >>>>>>>>>>> >> >>> > "Kubernetes user discussion and Q&A" group. >>>>>>>>>>> >> >>> > To unsubscribe from this group and stop receiving >>>>>>>>>>> emails from it, >>>>>>>>>>> >> >>> > send >>>>>>>>>>> >> >>> > an >>>>>>>>>>> >> >>> > email to kubernetes-use...@googlegroups.com. >>>>>>>>>>> >> >>> > To post to this group, send email to >>>>>>>>>>> kubernet...@googlegroups.com. >>>>>>>>>>> >> >>> > Visit this group at >>>>>>>>>>> >> >>> > https://groups.google.com/group/kubernetes-users. >>>>>>>>>>> >> >>> > For more options, visit https://groups.google.com/d/op >>>>>>>>>>> tout. >>>>>>>>>>> >> > >>>>>>>>>>> >> > -- >>>>>>>>>>> >> > You received this message because you are subscribed to the >>>>>>>>>>> Google >>>>>>>>>>> >> > Groups >>>>>>>>>>> >> > "Kubernetes user discussion and Q&A" group. >>>>>>>>>>> >> > To unsubscribe from this group and stop receiving emails >>>>>>>>>>> from it, send >>>>>>>>>>> >> > an >>>>>>>>>>> >> > email to kubernetes-use...@googlegroups.com. >>>>>>>>>>> >> > To post to this group, send email to >>>>>>>>>>> kubernet...@googlegroups.com. >>>>>>>>>>> >> > Visit this group at https://groups.google.com/grou >>>>>>>>>>> p/kubernetes-users. >>>>>>>>>>> >> > For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> > -- >>>>>>>>>>> > You received this message because you are subscribed to the >>>>>>>>>>> Google Groups >>>>>>>>>>> > "Kubernetes user discussion and Q&A" group. >>>>>>>>>>> > To unsubscribe from this group and stop receiving emails from >>>>>>>>>>> it, send an >>>>>>>>>>> > email to kubernetes-use...@googlegroups.com. >>>>>>>>>>> > To post to this group, send email to >>>>>>>>>>> kubernet...@googlegroups.com. >>>>>>>>>>> > Visit this group at https://groups.google.com/grou >>>>>>>>>>> p/kubernetes-users. >>>>>>>>>>> > For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "Kubernetes user discussion and Q&A" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to kubernetes-users+unsubscr...@googlegroups.com. >>>>>>>>>> To post to this group, send email to >>>>>>>>>> kubernetes-users@googlegroups.com. >>>>>>>>>> Visit this group at https://groups.google.com/grou >>>>>>>>>> p/kubernetes-users. >>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>> >>>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Kubernetes user discussion and Q&A" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to kubernetes-users+unsubscr...@googlegroups.com. >>>>>>>> To post to this group, send email to kubernetes-users@googlegroups. >>>>>>>> com. >>>>>>>> Visit this group at https://groups.google.com/grou >>>>>>>> p/kubernetes-users. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Kubernetes user discussion and Q&A" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to kubernetes-users+unsubscr...@googlegroups.com. >>>>> To post to this group, send email to kubernetes-users@googlegroups.com >>>>> . >>>>> Visit this group at https://groups.google.com/group/kubernetes-users. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Kubernetes user discussion and Q&A" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to kubernetes-users+unsubscr...@googlegroups.com. >>> To post to this group, send email to kubernetes-users@googlegroups.com. >>> Visit this group at https://groups.google.com/group/kubernetes-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "Kubernetes user discussion and Q&A" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-users+unsubscr...@googlegroups.com > <javascript:_e(%7B%7D,'cvml','kubernetes-users%2bunsubscr...@googlegroups.com');> > . > To post to this group, send email to kubernetes-users@googlegroups.com > <javascript:_e(%7B%7D,'cvml','kubernetes-users@googlegroups.com');>. > Visit this group at https://groups.google.com/group/kubernetes-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
