First up, quick refresher – what is a mutating admission controller?
Well it’s a nice feature in Kubernetes which lets you intercept objects when they’re created and make changes to them before they are deployed into the cluster.
Cool right? All those fiddly bits of YAML or hard to enforce company policies around network access, image stores you can and can’t use, they can all be enforced and FIXED automagically! (Like all magic caution is advised, choose wisely – queue Monty python gif)
So what’s the catch? Well without Open Policy Agent (OPA) you had to build out a web api to do the magic of changing the object then build/push an image and go through maintaining the solution. While you can write them quite easily now with solutions like KubeBuilder, or if you really love node I build one using that too, I wanted to see if OPA made things easier.
So say you want something more dynamic, flexible and a little easier to look after?
This is where Open Policy Agent comes in, they have a DSL language specially designed to build out and enforce complex policies.
Today I’ve been having a play with it to work out if I could build a controller which would set a certain
nodeSelector on pods based on which
namespace they are deployed in.
I’ll go over this very broadly I highly recommend looking at the docs in detail before diving in, I lost quite a bit of time to not reading things properly before starting.
I won’t lie, getting used to the DSL (
rego) was painful for me, mainly because I came at it thinking it was going to be really like Golang. It does look quite like it but that’s where the similarity ends, it’s more functional/pattern matching and better suited to tersely making decisions based on data.
To counter the learning curve of
rego I have to say, as I’ve raised issues and contributions the maintainers have been super responsive and helpful (even when I’ve made some silly mistakes) and the docs are great with runnable samples to get started.
Lets talk more about what I built out.
Continue reading →