Using kuberenetes CRD's to quickly codify your application portfolios.

TL;DR You don't need to make fancy controllers that respond to every beating heart of your applications in order to start making your management of apps cloud native.  In this post, you'll learn why you might want to start encoding your data center's app "spectrum" , or some aspects of it, as a CRD, and also get a simple, easy to start with example (with NO CONTROLLERS) that you can play with to make your own kubectl-friendly resources that you can start using to manage meta-info in your clusters.

Intro to CRDs, why you might want em.

If you're running a lot of stuff in kubernetes, you run into a ledgering problem:

- how do I map my apps to namespaces?

- where do I put meta-information about my apps?

- how do I scheduler and automate upgrade of my apps?

Because of the controller pattern in kubernetes, you're going to be itching to automate these sorts of tasks... however, for state, you typically would need :

- a git repo to start with, that versioned your app-topology in your data center?

- a key value store w/ updates/watches?

- some hybrid of the two ? 

For example: Imagine you're a bank.  You've got a transaction micro service.  You've got a database micro service.  Each upgrade independently.  Each is deployed in 100 or 200 namespaces for different regions.  You might have different tuning for each.  For example, you're services for branches in the midwest might have longer timeouts.  You're branches in the east might have special certificates. It starts to feel, a lot, like a big hierharchichcal json/yaml object... right? 

Wait... its starting to feel like a kubbe resource .  OMG !

Example

First, you can make a kubernetes CRD, which describes it as a resource, mainly, by defining

the group, version, kind, and plurality for the resource (i.e., its a noun. think REST).

crd.yml 

apiVersion: apiextensions.k8s.io/v1beta1

kind: CustomResourceDefinition

metadata:

  name: moneyapps.internalstuff.mybank

spec:

  group: internalstuff.mybank  # must be saas.hub to match the metadata.name

  version: v4-8-0

  names:

    kind: Moneyapp

    plural: moneyapps

  scope: Namespaced

THEN you can create that crd (kubectl create -f ./crd.yml).  Now, you can create "one of those"

CRD's that describes the app topology.  And you''ll have all the semantics and API facilities of kubernetes itself to handle updating and versioning.  Yup... 

apiVersion: internalstuff.mybank/v4-8-0

kind: Moneyapp

metadata:

  name: moneyapps

spec:

  regions:

    midwest:

      timeout: "24h"

      flavor: "Money"

      status: "Create"

   northeast-1:

      timeout: "1h"

      cert: "ne-certs"

      status: "Create"

      flavor: "Money"

Obviously the example above is totally contrived... the point here, though, is that now you can use the Kubernetes API to create, read, update these resources on the fly.  This includes things like json patching and so on.  For example, you can now do:

kubectl get moneyapp 

And you'll pull down the YAML above, and you can update it, kubectl edit it, whatever: and you can have controllers that responds to events in that config.  i.e. you've just made your entire application portfolio, not just the apps themselves, a cloud native construct that can be operated on as data.

Yuppppppp

Time to make a controller now !

https://github.com/kubernetes/sample-controller

Clone down the k8s.io official crd "sample-controller" project, and modify main.go as needed (i.e. I had to add GCP auth to the import headers, its a one line change), build it, and run it.. once you see how its manipulating and creating pods based on arbitrary metadata in the artifacts/examples/ directory, you can copy those files and make your own controller to do the same thing for your own apps.