Does it have to be DNS? Are unique IPs sufficient? On Thu, Mar 1, 2018 at 10:15 AM, <james.mas...@jmips.co.uk> wrote: > I'm using Apache Airflow, which uses a scale out worker model. > > The workers run jobs, and the job logs are collected from the workers via a > http call from a central server. These pods definitely do have specific > identity, but they are not important individually in the way that StatefulSet > is designed for. > > I've ruled out the following methods. > > 1. Can't change the apparent hostname of the worker to be either an IP/ > dash-seperated IP worker DNS, as Airflow only supports a direct getfqdn call > in our version. > 2. Don't want to change the hostname on the pod OS on startup, as that would > entail the pod running as root, even with a privilege downgrade later. These > pods run code outside of our direct control. > 3. The stateful set method is not ideal, because it makes autoscaling awkward. > > Eventually, this whole problem may go away, with a native K8s scheduler in > airflow - but I'm not in control of Airflow's priorities and release cycles. > > To be clear, I already have a mature helm-packaged airflow installation that > does what I need. I'm just looking to support a feature, and that feature > requires Pods contactable via DNS - with a minimum tradeoff in other areas. > > I don't think there is an acceptable trade-off for Pod DNS in my case, but I > thought I'd ask. > > thanks > > James M > > On Thursday, 1 March 2018 16:19:54 UTC, Tim Hockin wrote: >> The short answer is that you are ascribing identity to pods that don't >> really have any. They are literally called "replicas". If you need >> identity, you really sort of want StatefulSet. If that doesn't work, >> it would be good to understand more concretely what you're trying to >> achieve. >> >> On Thu, Mar 1, 2018 at 1:22 AM, <James M> wrote: >> > Hi list, >> > >> > I'm following this guide: >> > https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods-hostname-and-subdomain-fields >> > >> > I wish to have each pod in a deployment have a unique hostname, which >> > allows another pod to contact each of the autoscaled pods by hostname. >> > >> > However, although the guide makes sense for individual pods, it does not >> > work for deployments, as due to the lack of parameterisation each pod >> > hostname set would be the same. >> > >> > Can anyone think of a way around this? >> > >> > I've considered StatefulSet, but the lifecycle of the pods doesn't really >> > fit this model. >> > >> > thanks >> > >> > James M >> > >> > -- >> > 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.
