Gatekeeper is an easy way to deploy and manage admission policies in Kubernetes. Kubernetes admission policies allow you to set custom rules on what can and cannot be deployed in Kubernetes.

Gatekeeper is a CRD (Custom resource definition). This means that you can write policies as Kubernetes objects and deploy them to the cluster the same way you'd deploy any other object to cluster.

Gatekeeper policies are rego (created by OpenPolicyAgent), which is based on Datalog, and allows you to create these policies using a very rich and powerful language.

Ah, I think I get it now. So you could reject deployments for oversubscribing resources or using unsupported docker repos, as some contrived examples.

Yeah exactly. Kubernetes has some good built in tools for resource checking (and pods in general imo). I've found this most useful for asserting rules on ingress and services to control exposing of services to the public.

The nice thing is that you don't need to write custom admission controllers for each of your policies. You just need to write the policies and give them to Gatekeeper.

Rego is inspired by Datalog, but the syntax is very different.

Yes, very true. The rego syntax is not Datalog, but the language was inspired by Datalog

More specifically, Gatekeeper is (unless I’m mistaken) an “Operator,” which is a Kubernetes-native app that extends Kubernetes itself.

I would say it's a controller, because it is integrated with the Kubernetes system and reacts to changes to objects.

An operator generally creates Kubernetes objects as part of implementing a complex workflow that is normally taken care of by a human "operator". An example of this is the Cassandra operator, where you save a single object describing a Cassandra cluster at a fairly high level and the operator takes care of creating the pods and volumes and services and configuring the databases (and tearing it all down when you don't want it anymore).

Controller is usually reserved as the implementation that satisfies an API, regardless of what it does. Operators hide operational complexity via judicious use of APIs - if using it in the broadest sense the ingress API + a particular controller implementation (nginx which is a deployed object vs an ALB which might just be programmed) is an “operator”.

A Postgres operator could manage Postgres instances in pods, or it could program AWS RDS. Having a deployable entity isn’t really required. The thing reading the API and updating those objects is definitely a controller.

Although an ingress operator could be even higher level and ensure one or more ingress controllers were actually deployed (if you had an IngressController resource that made it easy to deploy them)

I wouldn't call this an operator since it isn't operating other applications.

It's a controller which is configured by Kubernetes Custom Resources that extends Kubernetes as you say.