That's such a broken assumption. StatefulSet is the only primitive that satisfies this condition for now.
On Thu, Mar 1, 2018 at 1:48 PM, <james.mas...@jmips.co.uk> wrote: > 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. > > no - hostname detected on the pod has to be resolvable on other pods. > > > On Thursday, 1 March 2018 21:43:53 UTC, Tim Hockin wrote: >> Does it have to be DNS? Are unique IPs sufficient? >> >> On Thu, Mar 1, 2018 at 10:15 AM, <James M> 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. -- 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.
