DEV Community


Posted on

Introducing a Custom Operator for Unified Management of Kubernetes Tools


I developed a new custom operator, the Kubernetes Operator Manager (KOM), to simplify the management of Helm packages and other resources in Kubernetes environments and to enable declarative management.
This operator centralizes the deployment and management of various tools, enhancing the efficiency of version control and state monitoring.


The Kubernetes ecosystem includes a wide range of tools to meet various workloads and requirements.
These tools are commonly deployed using commands like helm install or kubectl apply.
For example, when using multiple tools such as prometheus and cert-manager in a Kubernetes cluster, you need to execute specific commands for each tool, as follows:

Installation example for cert-manager:

helm repo add jetstack --force-update
helm repo update
helm install cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--version v1.14.5 \
--set installCRDs=true
Enter fullscreen mode Exit fullscreen mode

Installation example for prometheus:

helm repo add prometheus-community
helm repo update
helm install prometheus prometheus-community/prometheus
Enter fullscreen mode Exit fullscreen mode

However, this method has several issues:

  • It increases operational load as you need to execute commands each time a new tool is introduced.
  • The installation process is not declarative, making version control and state management challenging.

These issues can lead to confusion, especially when managing multiple Helm packages.
To handle these problems, we developed the Kubernetes Operator Manager (KOM). With KOM, you can manage tool versions declaratively.
This makes it easy to keep track of current versions and upgrade as necessary, leading to more efficient and effective management of Kubernetes clusters.

How KOM Works

KOM operates within kubernetes environments where Flux or ArgoCD is installed.

Managing packages with Flux or ArgoCD requires creating various Custom Resources (CRs).


Flux uses CRDs such as HelmRelease and HelmRepository to manage Helm packages. For deploying resources from a Git repository, GitRepository and Kustomization CRDs are used.

In the case of ArgoCD, resources primarily used include Application CRDs and Secret.

KOM centrally manages these resources, enabling more straightforward and efficient operations. The following diagram outlines KOM's behavior, showing how it manages Flux or ArgoCD's CRs required to deploy Helm and Git resources.

kom architecture

By leveraging the functionalities provided by Flux and ArgoCD, KOM functions as a highly lightweight operator.

How to Use KOM

Installation procedures and basic usage instructions for KOM are detailed in the README, but here we present a more specific usage example.

If you want to install two Helm packages, cert-manager and prometheus, you can configure KOM as follows. This configuration allows you to specify argo or flux depending on the environment.

kind: OperatorManager
  name: kom
  namespace: kom-system
  tool: argo # Set to "flux" if using Flux
  cleanup: true
      - name: jetstack
          - name: cert-manager
            version: v1.14.4
              installCRDs: true
      - name: prometheus-community
          - name: prometheus
            version: 25.20.1
Enter fullscreen mode Exit fullscreen mode

This configuration file uses the specified Helm charts to deploy the necessary packages to your Kubernetes cluster.
By changing the tool setting, you can choose to use either Flux or ArgoCD.
Additionally, setting the cleanup flag automates resource deletion, simplifying environment maintenance.


I developed KOM to manage packages in Kubernetes environments simply and declaratively.

I hope this article has helped you understand KOM's concept, structure, and usage. KOM is still under development, and its API may change, so please refer to the Git repository for the latest information.

Top comments (0)