Keeping your Kubernetes clusters in order can sometimes be a daunting task, especially when multiple variables are in use. Why not make it simpler and aggregate a list of features across your clusters? In this blog, we will explore how to compile a feature list across your Kubernetes installation to minimize wasted time spent searching, and increase your productivity.
Kubernetes is a big beast, and almost no cluster matches another one. As a cluster user, it’s frustrating when features you were expecting a cluster to have are missing, and it’s equally annoying to have worked hard on fixing issues that your cluster can already solve.
So how about a central point to publish the features of a cluster so users know straight up what to expect? And what could be better than using the cluster and its API itself for doing the publishing? This simple idea led to a small project to provide a way to publish “Installed Features.”
Think about just asking the cluster what features it provides by using the oc-client:
$ oc get ift
NAME VERSION AGE DOCUMENTATION
features-catalogue 1.0.0-alpha1 1y https://github.com/klenkes74/k8s-installed-features-catalogue/
global-loadbalancing 1.0.5 1d https://github.com/redhat-cop/global-load-balancer-operator
aws-egressip 1.0.0 5w https://github.com/redhat-cop/egressip-ipam-operator
enterprise-proxy 1.0.0 1y https://it.entreprise.com/is/proxy
$
As you can see, these features may be purely technical components, but they can also describe integrations into services provided by other teams or departments. So this catalogue is more than a list of operators. It can be used to document the consumable features of the cluster as perceived by users, not software.
And using the cluster itself as a documentation base helps keep the drift as small as possible. You can automate the update of the information into your cluster automation. The information is comprised of Kubernetes resources as Custom Resources.
The data is easy managed:
---
kind: InstalledFeatures
apiVersion: features.kaiserpfalz-edv.de/v1alpha1
Metadata:
name: k8s-feature-library
Namespace: default
Spec:
kind: k8s-feature-library
version: 1.0.0-alpha1
provider: Kaiserpfalz EDV-Service, Roland T. Lichti
description: |+
The catalogue definition to hold all feature information of a cluster.
uri: https://github.com/klenkes74/k8s-installed-features-catalogue/
With this small CR, the feature is announced. From here, it is only a small step to using some automation in the form of an operator to check the dependencies:
---
kind: InstalledFeatures
apiVersion: features.kaiserpfalz-edv.de/v1alpha1
Metadata:
name: k8s-feature-library
Namespace: default
Spec:
kind: k8s-feature-library
version: 1.0.0-alpha1
provider: Kaiserpfalz EDV-Service, Roland T. Lichti
description: |+
The catalogue definition to hold all feature information of a cluster.
uri: https://github.com/klenkes74/k8s-installed-features-catalogue/
depends:
- kind:
name: k8s-feature-operator
namespace: default
The dependencies declared point to a namespace and provide the operator with the information to check and report missing dependencies. The operator will set the state, and that state can be queried via the oc-client:
---
kind: InstalledFeatures
apiVersion: features.kaiserpfalz-edv.de/v1alpha1
Metadata:
name: k8s-feature-library
Namespace: default
Spec:
kind: k8s-feature-library
version: 1.0.0-alpha1
provider: Kaiserpfalz EDV-Service, Roland T. Lichti
description: |+
The catalogue definition to hold all feature information of a cluster.
uri: https://github.com/klenkes74/k8s-installed-features-catalogue/
depends:
- kind:
name: k8s-feature-operator
namespace: default
Status:
Phase: pending
Message: dependencies missing ({default/k8s-feature-operator}) missing-dependencies:
- name: k8s-feature-operator
namespace: default
The operator will check the features every minute as long as there are missing dependencies.
But that’s only the current feature of the operator. In the future, the operator may be enhanced with other functions helping the users and the cluster administrators of a Kubernetes cluster.
There are more ideas to improve the operator and the functionality. So in addition to the dependencies, conflicting features may be modelled. Perhaps some features conflict, and this data can be put into these custom resources. And of course, the version can be used to model incompatible versions of dependencies.
Another improvement could be a feedback channel from the users to the cluster administration about which features are used. A custom resource may be defined for the project administrator to state which features he uses within the project. So the cluster administrators may query these usage files and decide about the further development of the cluster or whether a useless feature can be removed.
The operator is open source under the Apache 2.0 license and based on the operator-sdk 1.0.1 - you can find it on https://github.com/klenkes74/k8s-installed-features-catalouge. Currently, the software is not yet published to the OperatorHub but can be installed via operator-sdk to your cluster. As with every project, help is appreciated and new ideas are also welcomed.
