Enjoyers of the high fantasy genre, or RPG games, are certainly familiar with the trope of an adventurer's guild. Parties of adventurers can register, find missions, and go questing under the guild's organization. Today, I'd like to explain Kubernetes in the context of this beloved trope.

Kubernetes comes from the Ancient Greek word for helmsman or pilot, so it's no surprise that Kubernetes is the Head of the Guild. What's more interesting is the distribution of control plane responsibilities amongst members of the staff:

  • The guild receptionist is the API Server. Everyone talks to the guild's staff team through the receptionist: kubectl, dashboards, internal components. The receptionist speaks usually in REST API format.
  • The quest board manager is the Scheduler. Whenever a quest is added to the quest board, the quest board manager reaches out to adventuring parties that are best suited for based on resource availability, constraints, and affinity rules.
  • The guild steward is the controller manager, running a set of control loops that constantly compare desired state vs. actual state and take corrective action. This is the core of how the guild operations run reliably.
  • The guild ledger is etcd: a distributed key-value store that holds all guild operation state. "Node 2 has 3 pods running, Pod X needs 512 MB RAM." If the ledger is lost, then the guild critically loses all knowledge of its operations.

What do adventuring parties look like, in Kubernetes terms? They're worker nodes!

  • The party leader is a kubelet, receiving instructions from the control plane of the guild. They're the local supervisor.
  • The adventurers themselves are container runtimes, which actually run containers (containerd, CRI-O). The Head of the Guild themself doesn't run containers; they tell the adventurers to do it.

Quests are pods, or units of work that need to run. Quests are the smallest deployable unit of work for guilds.

  • They're broken up into containers, or individual tasks within a quest.
  • Quests can be created, taken down, even re-assigned to different adventuring parties if previous ones get too busy or incapable of completing the work. So how does the guild keep track of a quest's status and assignment? A Service provides a stable network identity for a set of quests.

If a city or state is considering opening up a guild to handle any quests that crop up in their territory, from clearing slimes from farmland to hunting down nefarious outlaws, there are some factors to consider before making the decision. A guild's pros are that it can orchestrate many different quests with high availability and reliability, and can support frequent quest assignments. However, if a city or state expects very few quests to crop up, simpler solutions with less operational overhead are necessary. And if they only require completion of batch jobs with no uptime requirement, just hire freelance adventurers (a.k.a. use AWS Batch or Cloud Functions instead)!