Kubernetes: Build a custom automation system for a containerized infrastructure. Quick and simple. Playing with MSActivator (TM).

Why do I need this?

Kubernetes has plenty of tools for various purposes, of course, I don’t need all of them in my daily practice. I need something very simple, a simple tool for managing a containerized infrastructure. For quick access, I need a dashboard with a set of the most frequently used functions that is intuitive for me and my team.

Architectural thoughts

How would I build a dashboard with a quick bar?

We need some kind of front-end with buttons and an ergonomic intuitive interface.

We need a database to store the configuration of Kubernetes objects.

We need an engine that will make requests to the Kubernetes API and parse the responses.

It would be great to attach tools for monitoring logs and visualizing metrics here. To work in a team, I need an access control system.

Prerequisites

Which knowledge will be useful to us:

- Kubernetes API

- Relational database

- Let’s choose Python as one of the most popular high-level programming languages (for requests, JSON, etc.)

- Basic Linux/networking training to host and maintain our solution

- Don’t forget about security and user privileges

Let’s get started

Kubernetes API

Let’s not think about visualization and the front-end for now and look at the Kubernetes API, let’s figure out where we can start working with a containerized infrastructure. We will assume that our Kubernetes cluster is already deployed and functioning. And so, first of all, we need to connect to the API.

Let’s find the IP: port where the API service is listening:

Then, expose it if is not available from an external network:

You will see something similar to this when opening with a browser:

Next step — Authentication. We need to get authenticated somehow.

Let’s find the token for a simple bearer token authentication:

Let’s try to authenticate.

I use [postman] for simple testing.

Specify Method, URL and Token:

Specify headers:

See if API returns something similar:

That means the API responds properly and we retrieved information successfully.

Infrastructure discovery

Let’s check if I can list nodes, pods and services, first of all, I need these three resource types:

list or watch objects of kind: Node

list or watch objects of kind: Pod

list or watch objects of kind: Service

For each resource type discovery response returns a pretty large number of lines, so let’s do a bit of design here.

Resource type — Node, fields I need:

  • Name (metadata/name)
  • OS Image (status/nodeInfo/osImage)
  • Kernel Version (status/nodeInfo/kernelVersion)
  • Container Runtime Version (status/nodeInfo/containerRuntimeVersion)
  • Kubelet Version (status/nodeInfo/kubeletVersion)
  • CPU (status/capacity/cpu)
  • Ephemeral Storage (status/capacity/ephemeral-storage)
  • Memory (status/capacity/memory)
  • Pods (status/capacity/pods)

For resource type — Pod:

  • Name (metadata/name)
  • Namespace (metadata/namespace)
  • Container Name (spec/containers/row/name)
  • Creation Date (metadata/creationTimestamp)
  • Container Image (spec/containers/row/image)
  • Container Status (status/phase)
  • App Name (metadata/labels/app)

For resource type — Service:

  • Name (metadata/name)
  • Creation Date (metadata/creationTimestamp)
  • Type (spec/type)
  • Cluster Ip (spec/clusterIP)
  • External IPs (spec/externalIPs/row)
  • Protocol (spec/ports/row/protocol)
  • Port (spec/ports/row/port)
  • Target Port (spec/ports/row/targetPort)
  • Node Port (spec/ports/row/nodePort)

Here we need a JSON parser/pathfinder to filter relevant data from the API responses.

Then we need a script to store the filtered data into a database. DB tables should be created accordingly. The front end should visualize DB tables.

Ok, let’s do some research here, as I’m looking for a solution to:

  • parse
  • store
  • and visualize data.

Furthermore, I’m building an interactive tool that will allow me and my team to edit Kubernetes resources (though the API methods POST, PUT, PATCH, DELETE). Also, it’s nice to have monitoring on the board.

Ok, here is something similar to what I need:

Let’s try it out

MSActivator terminology

Managed Entity — remote device representation, which should have the IP address and interface with which to interact.

In my case, the Kubernetes API could be a remote Managed Entity:

  • Protocol: REST / HTTPs
  • Authentication Type: Bearer Token
  • IP address / port: 10.31.1.64:16443

Good, what are the benefits here?

  • Inventory — I can simply track Managed Entities
  • Kubernetes overall status — whether available or not
  • There are many other features, we don’t need all of them now, so I’ll explore them later.
Managed Entities

Microservices — this is something we can use for querying Kubernetes API. There are built-in CRUDi methods and a parser/pathfinder.

Microservice configuration

Let’s check if I can see the desired resource tables:

  • One table for the Node list
  • One table for the Pod list
  • One table for the Service list
Managed Entity configuration

Now the Node list looks like this:

Kubernetes nodes

The Pod list looks like this:

Kubernetes pods

And the Service list looks like this:

Kubernetes services

Summary

Finally, I’ve got frequently used resources listed under a custom UI. Here I can easily filter properties, parse arguments, and add/remove interesting data. Now I can literally build my own Kubernetes web UI.

What’s next

Let’s do some interaction and play with resources, I know I can edit them and I need these functions. A more interesting case is that I’ve spotted a nice topology viewer, and its correlated monitoring tools. I’m planning to explore them as well.

Senior Systems (DevOps) Engineer