@Namrata and I have been doing some testing with Tutor on Kubernetes this week, and we’ve been running into a situation that looks a bit like a catch-22. Our Kubernetes cluster is managed by OpenStack Magnum.
The documentation says that in order to run
tutor k8s in production mode, you must first create DNS records — presumably a single A (or AAAA) record pointing to the external-ip associated with the Caddy service, plus a few CNAMEs.
Now, the external-ip of the
caddy service is only being allocated during
tutor k8s start (or
quickstart), which means that you’d have to
tutor k8s [start|quickstart]
- Wait until the
caddyservice is up, and retrieve its
kubectl(at this point other pods may be hitting the
CrashLoopBackoffstate because they rely on name resolution to connect to other Tutor-managed services)
- Create the DNS record,
- Recover any failed pods.
This process would need to be repeated every time one runs
tutor k8s stop followed by
tutor k8s start, because generally Kubernetes doesn’t guarantee the persistence of external IPs. (If you throw a service away and recreate it, you can’t expect that its external IP is the same as before.)
We’re guessing that for someone running EKS on AWS, they could work around this issue by automatically creating DNS records via Route 53, but in our case with Magnum on OpenStack (and unfortunately lacking Designate) we don’t have that option.
So, is there a more elegant way to resolve this chicken-and-egg issue than steps 1-4 above?
And perhaps related, under what circumstances does it really make sense to run
tutor k8s quickstart and answer ‘n’ on the “Are you configuring a production platform” question? It would appear that the non-production settings don’t play nicely with the
tutor-minio plugin, which the documentation says is required for running
tutor k8s. That’s why we skipped straight to the “production” configuration where we ran into the DNS catch-22.
Thanks in advance for your thoughts!