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-custom-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/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/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-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/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. 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.
