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.
Microservices — this is something we can use for querying Kubernetes API. There are built-in CRUDi methods and a parser/pathfinder.
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
Now the Node list looks like this:
The Pod list looks like this:
And the Service list looks like this:
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.