[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: DNS support added to OpenShift

----- Original Message -----
> On 03/09/2015 11:16 AM, Clayton Coleman wrote:
> > Yes - it's also to remove the need for you to use environment variables at
> > all.  If you have a DB service you're expecting, just reference "db.local"
> > in your config files, or set your own custom env var.  Ordering is a big
> > one - you can launch a pod that refers to "db.local" before the "db"
> > service is created, and it will eventually resolve.  After all, DNS is the
> > original service-discovery.
> > 
> > Eventually, this will support things like headless services, so you can run
> > clustered software - imagine a Replication controller that gives each pod
> > a unique label "member=<number>" and ensures that there's always a 1, 2,
> > 3, etc.  Then imagine a service called "mongodb" that is enabled to
> > support this.  The name:
> > 
> >    mongodb.mynamespace.local
> > 
> > would resolve to multiple A records - one for each pod.  But the service
> > would also expose a DNS name for each named member:
> > 
> >    1.mongodb.mynamespace.local
> >    2.mongodb.mynamespace.local
> >    3.mongodb.mynamespace.local
> > 
> > The DNS value for each member would resolve to the pod directly - if a pod
> > gets deleted, and recreated, then eventually the DNS name (assuming you
> > have a properly configured resolve.conf that honors TTL) would pick up
> > that 1.mongodb.mynamespace.local changed from to  This
> > isn't a final implementation of course.
> That sounds rather dangerous. What happens when a container looks for a
> service endpoint via DNS that no longer exists? What is the TTL for
> these skydns-based entries?

It gets a not found.  30s.

> This sounds like we're going down the same path of "dns for ha" which
> does not work because of TTL and/or performance of lookups.

No, the DNS is for the service entry, which is a stable IP.  Infrastructure components use DNS for HA all the time, but you have to be aware of the TTL issues in clients to handle it.  It's fairly easy to build infrastructure around DNS that uses DNS for propagation but manages dynamic change.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]