Proposal: Create an Agones operator

[roberthbailey]

Proposal: Create an Agones operator

I'd like to suggest that we build an operator to manage the lifecycle of Agones. It's easy to install Agones today (using kubectl apply or helm) but I don't see any instructions for how to upgrade Agones between versions.

CoreOS has a nice writeup about operators here, including a concise description of what an operator is:

Operators are purpose-built to run a Kubernetes application, with operational knowledge baked in.

Operators were originally written to help manage stateful applications (like Spark or etcd) that needed extra hand holding to manage the lifecycle of application pods, especially during application upgrades. But they are generally useful in any case where managing an application is complex and should be automated. Kubernetes is itself moving towards using operators to manage cluster addons.

Agones manages both stateless pods (unallocated game servers) and stateful pods (allocated game servers). Agones also has a number of CRDs that are likely to evolve over time.

Background Reading

• https://coreos.com/operators/
• https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps
• https://enterprisersproject.com/article/2019/2/kubernetes-operators-plain-english

[markmandel]

I'm looking at the CLI interfaces that Linkerd and [Istio](https://istio.io/docs/setup/install/istioctl/ are doing - which is pretty neat. (actually backed by Helm go libraries)

Wondering if a similar thing would make sense for Agones in-lieu of an operator?

[roberthbailey]

A CLI is generally a good experience for human end users but doesn't lend itself to automation quite as well. One possibility for an operator would be to replace helm as the installer/upgrader, which a CLI could do just as well (for a human). But we also use helm from within terraform, where a CLI might not easily slot in.

So I think it depends on what use cases we are trying to solve, and how many different methods for install/upgrade we want to support.

[EricFortin]

@roberthbailey Still interest on this? I have been thinking about it for a few days now since we are looking at installing(upgrading) Agones in multiple clusters in an automated fashion. While it could be achieved with a CLI, I like the reconciliation phase an operator would provide. I stumbled upon some documentation on operator capability model defined here: https://sdk.operatorframework.io/docs/operator-capabilities/. I also discovered(but not tried yet) that operator-sdk can generate an operator that install an helm chart. I figured that it would help reduce support if we went that way. Could that be interesting?

Helm operator is at low capability level but it may be all we need for Agones.

[roberthbailey]

@EricFortin - I've been thinking about this recently and I'm not sure what the best path forward is. Right now the upgrade experience (especially in place) isn't great, and an operator may be able to help there.

I've added this to the agenda for the monthly community meeting (this Thursday). If you can be there, it would be great to discuss use cases and options.

[markmandel]

Going through old issues, is this something we still want to explore? I haven't heard mention of an operator from the community in a while.

Going to mark as stale, and see what you all think. Let me know if you object to closing this issue.

[roberthbailey]

I was originally really excited about this but my excitement has waned as I'm become more comfortable with helm (and I think it would be a lot of work to reproduce the installation flexibility we have with helm).

[markmandel]

Okay - closing this for now. If the desire comes back, we can open a new ticket.