Kubernetes is a domain specific database

We’ve all seen domain specific languages - regular expressions, CSS, LaTex. Every once of these are created by folks who need specific functionality on a regular basis. Some DSLs end up being hyper specific and only used by a single person or organization to improve productivity. Other DSLs, such as CSS, end up defining entire industries as they’re a problem that everyone has. What does this have to do with Kubernetes?

It would be possible to think of Kubernetes as its own DSL, the YAML used has its own grammar and syntax. These get applied to the api-server and then domain specific things happen. This some of the real power behind Kubernetes' API. By thinking about what’s happening behind the scenes a little more, it is possible to fundamentally understand what creating or modifying something will actually do to the system. More importantly, much of the magic goes away and composition of the pieces themselves becomes easier.

A regular three tier app normally consists of a frontend that users interact with, an API that machines interact with and a database to store state. Kubernetes flips this around - you’re interacting directly with the database every time kubectl apply is run. Take a Pod as an example. Running kubectl create will add a record to the database that contains all the details required. Components observe this change, start to do work and then update the Pod’s record based off what’s happening in the system.

By flipping the story around, there are two major implications - end users are not necessarily meant to interact with API directly and the Kubernetes community doesn’t need to build a solution for everyone.