We sort of want to move away from pre-populating env vars for services - it has come up as a name-conflict problem for people, it is rather noisy, and it doesn't get updated when a Service changes. Env vars are a really sub-standard API for this.
On Wed, Aug 24, 2016 at 11:42 PM, Mayank <krmaya...@gmail.com> wrote: > Thanks Tim, i am asking for something simpler. We are already exposing a > service host and port to a pod as environment variables for all services in > that namespace. How about we also include exposing the nodeport information > as environment variable to the pod. Not necessarily the service that point > to the pod , but just all the services in that namespace. > > > On Wednesday, August 24, 2016 at 9:58:17 PM UTC-7, Tim Hockin wrote: >> >> I don't think we want a mechanism for pods to know what service >> NodePorts point to them. It would be too noisy (every node) and >> that's just not a common pattern. If you need to register nodePorts, >> I think you should do it as a controller pod that runs in the cluster, >> reads the kube API and syncs that to your F5. >> >> On Wed, Aug 24, 2016 at 9:13 PM, Mayank <krma...@gmail.com> wrote: >> > Hi Rodrigo/Tim >> > Does this seem like a use case where pods would like to know their >> > NodePorts >> > assigned to them so that they could register it with an external service >> > discovery system specially when loadbalancers are not available ? I dont >> > want to hardcode the nodeports as well. >> > >> > -Mayank >> > >> > >> > On Tuesday, August 16, 2016 at 9:42:17 PM UTC-7, Mayank wrote: >> >> >> >> Hi Rodrigo >> >> This is within the companies infrastructure, the load balancer requires >> >> integration with a cloud provider in our case probably that would be >> >> f5. Yes >> >> that is one option but it requires lot more work in imo >> >> >> >> On Tuesday, August 16, 2016 at 5:17:07 PM UTC-7, Rodrigo Campos wrote: >> >>> >> >>> Why node port? Why not load balancer, know the balancer by >> >>> configuration >> >>> or something, and be done? >> >>> >> >>> On Tuesday, August 16, 2016, Mayank <krma...@gmail.com> wrote: >> >>>> >> >>>> actually you are right the example i gave was basically registering >> >>>> hostports. But we could also potentially do a service of type >> >>>> NodePort per >> >>>> pod per node and try to register that NodePort as well. HostsPorts >> >>>> require >> >>>> managing and NodePorts are managed by k8s itself, so it would be nice >> >>>> to use >> >>>> NodePort and discover it from the pod itself >> >>>> >> >>>> >> >>>> On Thursday, August 11, 2016 at 10:15:49 PM UTC-7, Tim Hockin wrote: >> >>>>> >> >>>>> That didn't explain why you are registering NODE PORTS. Do you mean >> >>>>> HostPorts instead? >> >>>>> >> >>>>> On Thu, Aug 11, 2016 at 10:13 PM, Mayank <krma...@gmail.com> wrote: >> >>>>> > It might be just our internal infra, but the way we are slowly >> >>>>> > introducing >> >>>>> > k8s and containers , requires in the first cut for the clients >> >>>>> > living >> >>>>> > outside k8s cluster to be able to access these redis nodes in k8s >> >>>>> > cluster. >> >>>>> > The redis nodes will register their nodeports to the etcd/consul >> >>>>> > and >> >>>>> > then >> >>>>> > the clients living outside the cluster will use those nodeports. >> >>>>> > >> >>>>> > On Tuesday, August 9, 2016 at 8:34:40 PM UTC-7, Tim Hockin wrote: >> >>>>> >> >> >>>>> >> NodePort is part of a Service. A Pod can be created before the >> >>>>> >> Service that points to it, or that Service can change. >> >>>>> >> >> >>>>> >> why are you registering a nodeport rather than a ClusterIP or >> >>>>> >> PodIPs >> >>>>> >> ? >> >>>>> >> >> >>>>> >> On Tue, Aug 9, 2016 at 8:27 PM, Mayank <krma...@gmail.com> wrote: >> >>>>> >> > Thanks Rodrigo. >> >>>>> >> > Basically we were evaluating a use case where a distributed >> >>>>> >> > application >> >>>>> >> > (redis based) reports its ip and ports to etcd for discovery by >> >>>>> >> > a >> >>>>> >> > client. >> >>>>> >> > Since this application is running as a container in k8s, i want >> >>>>> >> > this to >> >>>>> >> > discover its nodeport and report it correctly to etcd. Yes i >> >>>>> >> > agree >> >>>>> >> > that >> >>>>> >> > if >> >>>>> >> > we specify the nodeport, we know it, but then we have to manage >> >>>>> >> > the >> >>>>> >> > nodeport >> >>>>> >> > allocation on our own. It would be nice for the application to >> >>>>> >> > know/discover >> >>>>> >> > the nodeport of the application using downward api and pass >> >>>>> >> > then >> >>>>> >> > on to >> >>>>> >> > etcd >> >>>>> >> > for discovery. >> >>>>> >> > >> >>>>> >> > Thoughts ? >> >>>>> >> > -Mayank >> >>>>> >> > >> >>>>> >> > On Thursday, August 4, 2016 at 7:47:13 PM UTC-7, Rodrigo Campos >> >>>>> >> > wrote: >> >>>>> >> >> >> >>>>> >> >> On Thu, Aug 04, 2016 at 05:28:35PM -0700, Mayank wrote: >> >>>>> >> >> > What are the solutions people are using for discovering >> >>>>> >> >> > nodeports for >> >>>>> >> >> > a >> >>>>> >> >> > given Service. >> >>>>> >> >> >> >>>>> >> >> I just use kubectl with "-o yaml" >> >>>>> >> >> >> >>>>> >> >> > I see its not supported in the downward api? Is there any >> >>>>> >> >> > plan >> >>>>> >> >> > to >> >>>>> >> >> > support >> >>>>> >> >> > it , does it makes sense if we submit a PR to do that? Are >> >>>>> >> >> > there >> >>>>> >> >> > other >> >>>>> >> >> > options available to expose the nodeport to the >> >>>>> >> >> > containers/pods >> >>>>> >> >> > running >> >>>>> >> >> > on >> >>>>> >> >> > it ? >> >>>>> >> >> >> >>>>> >> >> Can you please elaborate why do you want to do that? I mean, >> >>>>> >> >> you >> >>>>> >> >> don't >> >>>>> >> >> need the >> >>>>> >> >> node-port to use the service discovery, etc. and connect that >> >>>>> >> >> is >> >>>>> >> >> the >> >>>>> >> >> most >> >>>>> >> >> common >> >>>>> >> >> thing, I guess. But what do you want to achieve? >> >>>>> >> >> >> >>>>> >> >> In any case, for sure there are two options: use the API >> >>>>> >> >> directly >> >>>>> >> >> or >> >>>>> >> >> use >> >>>>> >> >> the >> >>>>> >> >> kubectl. Also, it depends what you want to achieve, but you >> >>>>> >> >> can >> >>>>> >> >> choose >> >>>>> >> >> your self >> >>>>> >> >> the node port to be used and then you "know" it. >> >>>>> >> >> >> >>>>> >> >> But I'm curious, sorry, what do you want/need? :) >> >>>>> >> > >> >>>>> >> > -- >> >>>>> >> > 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-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.
