How to Install iTop CMDB Open-Source Tool on Kubernetes

July 09, 2026 — LiveStream

Embarking on the journey to centralize your IT asset and service management just got a whole lot smoother. This comprehensive guide will walk you through the seamless process to install iTop CMDB on Kubernetes, transforming your infrastructure into a robust, scalable, and manageable powerhouse. Whether you're aiming to deploy a powerful open-source CMDB solution or enhance your existing Kubernetes skills, you'll find everything you need right here to get iTop CMDB up and running efficiently.

Hey junior, grab a chai, we need to talk about CMDBs and Kubernetes. You know, in our fast-paced tech world, managing IT assets and services can feel like herding cats, especially across a distributed infrastructure. That’s where a good Configuration Management Database (CMDB) comes into play, aur iTop CMDB on Kubernetes is a fantastic combo to tackle this challenge head-on. iTop is a popular open-source tool, excellent for IT asset management and IT service management (ITSM). When you deploy it on Kubernetes, you get all the benefits of containerization – scalability, resilience, and easier management. Today, we'll walk through the entire installation process, setting up iTop with its MySQL backend on a Kubernetes cluster using standard YAML configurations. By the end, you’ll have a centralized system to effectively manage all your IT assets.

Setting the Stage: Prerequisites and Initial Kubernetes Setup

Before we dive into the YAML files and commands, let's make sure our environment is ready. Think of it like preparing your kitchen before you start cooking – you need all the ingredients and tools handy. This entire exercise of deploying iTop CMDB on Kubernetes relies on a few fundamental components being in place.

What You'll Need (Our Ingredients List):

1. A Running Kubernetes Cluster: This is non-negotiable, boss. Whether you’re running a local minikube instance, a kind cluster, or leveraging a managed service like AWS EKS, Google GKE, or Azure AKS, your cluster needs to be operational and accessible. For a production-grade setup, obviously, you’d opt for a managed service for reliability and scaling.
2. kubectl Command-Line Tool: This is your primary interface to interact with your Kubernetes cluster. It needs to be installed, configured, and authenticated to your cluster. You can quickly check its configuration with kubectl config current-context.
3. The Necessary YAML Files: You’ll need a set of Kubernetes manifest files that define how iTop and its dependencies (like MySQL) should be deployed. These include:
   • deployment_itops.yaml: Defines the iTop application deployment.
   • svc_itops.yaml: Defines the Kubernetes Service for iTop.
   • mysql-secret.yaml: Securely stores sensitive MySQL credentials.
   • mysql-deployment.yaml: Defines the MySQL database deployment.
   • mysql-svc.yaml: Defines the Kubernetes Service for MySQL.

Make sure you have these files organized. For our tutorial, we'll assume they are in your current working directory.

Creating a Dedicated Namespace (Ghar Banao!):

First things first, let's create a dedicated playground for our iTop installation. In Kubernetes, namespaces provide a way to logically partition your cluster, allowing you to isolate resources, manage access, and avoid naming conflicts. It's a best practice, especially when deploying new applications, to give them their own space.

kubectl create namespace itops

This command creates a new namespace called itops. Simple, right? Now, all our subsequent commands should target this namespace.

Setting the Namespace Context (Sahi Address Pe Jaao!):

To ensure that every kubectl command you run from now on applies to our itops namespace, we can set our current context to it. This saves you from typing -n itops with every command and reduces the chances of accidental deployments in the wrong namespace.

kubectl config set-context --current --namespace=itops

Now your kubectl is pointed directly at the itops namespace. Verify it with kubectl config view --minify | grep namespace. You should see namespace: itops.

Deploying iTop and its MySQL Backend: The Core Infrastructure

Alright, let's get into the heart of the matter – deploying iTop and its database. This involves creating Kubernetes Deployments for both the iTop application and the MySQL database, along with their respective Services for networking and exposure. This is where we define the desired state of our application on the cluster.

1. Creating MySQL Secrets (Password Ka Khayal Rakho!):

Before deploying the MySQL database itself, we need to handle its credentials securely. Kubernetes Secrets are designed for this exact purpose. The mysql-secret.yaml file will store the root password, database user, and their password for MySQL.

A crucial correction: The original source's mysql-secret.yaml structure for stringData with configMapRef is incorrect. stringData is used to provide unencoded string data directly, and configMapRef is typically used within a Pod's envFrom or volume section, not directly in a Secret definition like that.

Here's the corrected and expanded mysql-secret.yaml that correctly uses stringData for readability and demonstrates how to get the base64 encoded values, which Kubernetes internally converts to data:

# mysql-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: mysql-secret
type: Opaque
stringData: # Use stringData for unencoded values directly in YAML
  MYSQL_ROOT_PASSWORD: "Premaa@1965" # Replace with your strong root password
  MYSQL_USER: "itops"             # The user iTop will use
  MYSQL_PASSWORD: "Premaa@1965" # Replace with your strong user password
  # Add the database name here so iTop can pick it up easily
  MYSQL_DATABASE: "itops"

Why stringData? While data requires base64 encoded values, stringData allows you to define plain text values, and Kubernetes automatically encodes them when the Secret is created. This makes your YAML more human-readable.

To get base64 encoded values (if you were using data instead of stringData):

echo -n 'Premaa@1965' | base64
# Expected output: UHJlbWFAMTk2NQ==
echo -n 'itops' | base64
# Expected output: aXRvcHM=

Now, apply this secret:

kubectl apply -f mysql-secret.yaml

You can verify the secret exists and contains the keys (but not easily readable values) by running kubectl get secret mysql-secret -o yaml.

2. Deploying MySQL Database (Database Banana Hai!):

Next up is our database. iTop relies on a MySQL backend, so we'll deploy a MySQL instance within our Kubernetes cluster. This deployment will link to the secret we just created to get its credentials.

Important Note: The provided mysql-deployment.yaml does not include persistent storage. For a production database, this is a critical oversight. A single replica database without persistent storage means if the pod restarts or moves, all your data is lost! For this guide, we'll proceed as given, but keep in mind that for any real-world scenario, you must add a Persistent Volume Claim (PVC) to your MySQL deployment. I’ll add a dedicated section on this later.

Here's the mysql-deployment.yaml:

# mysql-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: mysql:5.7 # A stable, widely used version
          envFrom:
            - secretRef:
                name: mysql-secret # Reference our secret here
          ports:
            - containerPort: 3306
          resources:
            requests:
              memory: "512Mi"
              cpu: "250m"
            limits:
              memory: "1Gi"
              cpu: "500m"
          # FOR PRODUCTION: Add a Persistent Volume Mount here
          # volumeMounts:
          #   - name: mysql-persistent-storage
          #     mountPath: /var/lib/mysql
      # FOR PRODUCTION: Add Persistent Volume Claim here
      # volumes:
      #   - name: mysql-persistent-storage
      #     persistentVolumeClaim:
      #       claimName: mysql-pvc

Apply the MySQL deployment:

kubectl apply -f mysql-deployment.yaml

Monitor its status: kubectl get pods -l app=mysql. Wait until the pod is in a Running state.

3. Creating MySQL Service (Database Ko Pata Chale Kaha Se Connect Kare!):

A Deployment creates pods, but how do other pods (like our iTop application) find and communicate with these database pods? That’s where a Kubernetes Service comes in. It provides a stable IP address and DNS name for your database.

# mysql-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: mysql-service
spec:
  type: ClusterIP # Changed to ClusterIP for internal service. LoadBalancer is not needed for an internal DB.
  selector:
    app: mysql
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306

Correction and Explanation: The original source specified type: LoadBalancer for the MySQL service. This is generally not advisable for an internal database. A LoadBalancer Service exposes your database directly to the internet (or to your cloud provider's load balancer), which is a security risk. For an application like iTop running within the same cluster, a ClusterIP Service is perfect. It makes the MySQL database accessible only from within the cluster via a stable internal IP and DNS name (mysql-service.itops.svc.cluster.local).

Apply the MySQL service:

kubectl apply -f mysql-svc.yaml

Now, any pod in the itops namespace can reach the MySQL database using the hostname mysql-service.

4. Deploying iTop Application (CMDB Ko Live Karo!):

Now that our database is ready, let's deploy the iTop application itself. This involves defining the iTop container, its image, and crucially, how it connects to our MySQL database.

Crucial Fix for the ConfigException: The error Fatal error: Uncaught ConfigException: Syntax error in configuration file... Undefined array key "DB_ENV_MYSQL_DATABASE" clearly indicates that the iTop application pod is failing to receive the database connection parameters. The provided deployment_itops.yaml in the source does not pass any environment variables to the iTop container. We need to rectify this by referencing our mysql-secret in the iTop deployment.

Here's the corrected and expanded deployment_itops.yaml:

# deployment_itops.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: itops-cmdb-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: itops-cmdb
  template:
    metadata:
      labels:
        app: itops-cmdb
    spec:
      containers:
        - name: itops-cmdb
          image: vbkunin/itop:2.7.1 # Use a specific, stable tag
          ports:
            - containerPort: 80
          env: # Pass database connection details as environment variables
            - name: MYSQL_HOST
              value: mysql-service # The name of our MySQL Kubernetes service
            - name: MYSQL_PORT
              value: "3306"
            - name: MYSQL_DATABASE
              valueFrom:
                secretKeyRef:
                  name: mysql-secret
                  key: MYSQL_DATABASE
            - name: MYSQL_USER
              valueFrom:
                secretKeyRef:
                  name: mysql-secret
                  key: MYSQL_USER
            - name: MYSQL_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-secret
                  key: MYSQL_PASSWORD
          resources: # Good practice to set resource requests/limits for iTop
            requests:
              memory: "1Gi"
              cpu: "500m"
            limits:
              memory: "2Gi"
              cpu: "1000m"

Explanation of the Fix: I've added an env section to the itops-cmdb container.

• MYSQL_HOST: Set to mysql-service, which is the DNS name of our MySQL Service within the cluster.
• MYSQL_PORT: Standard MySQL port.
• MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD: These are pulled directly from our mysql-secret using valueFrom: secretKeyRef. This securely injects the credentials into the iTop container's environment variables. The iTop image (or its underlying PHP application) will then pick up these variables to connect to the database, resolving the ConfigException.

Apply the iTop deployment:

kubectl apply -f deployment_itops.yaml

Check the status: kubectl get pods -l app=itops-cmdb. Ensure it's Running. If it restarts in a loop, check the logs with kubectl logs <itops-pod-name>.

5. Creating iTop Service (CMDB Ko Duniya Ko Dikhao!):

Finally, we need a way to access the iTop web interface from outside our Kubernetes cluster. A LoadBalancer Service type will provision an external IP address (if your cloud provider supports it) or expose a port on your nodes (if using minikube/kind and NodePort).

# svc_itops.yaml
apiVersion: v1
kind: Service
metadata:
  name: itops-cmdb-service
spec:
  selector:
    app: itops-cmdb
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer # Exposes iTop via an external IP

Apply the iTop service:

kubectl apply -f svc_itops.yaml

Now, let's move to database initialization and UI access.

Database Configuration and Initial iTop Access

With all the deployments and services in place, our pods are up, and our services are exposing them. However, for iTop to fully function, its database needs to be created and schema initialized.

1. Initializing the iTop Database Schema:

Even though our MySQL server is running and the iTop container is pointing to it, the actual database schema for iTop needs to be created and populated. We'll do this by connecting directly to the MySQL pod.

First, identify your MySQL pod name:

kubectl get pods -l app=mysql

You'll get something like mysql-deployment-698cdf4c88-f727r. Use your pod name in the next command.

Execute a shell inside the MySQL pod:

kubectl exec -it <your-mysql-pod-name> -- /bin/bash

Once inside the pod, connect to MySQL as root using the password you set in mysql-secret.yaml (which was Premaa@1965 in our example).

mysql -u root -p

It will prompt for the password. Enter Premaa@1965.

Now, within the MySQL prompt, create the database and grant privileges to the itops user:

CREATE DATABASE itops;
SHOW DATABASES;
GRANT ALL PRIVILEGES ON itops.* TO 'itops'@'%' IDENTIFIED BY 'Premaa@1965'; -- Ensure the password matches your secret
FLUSH PRIVILEGES;
EXIT;

Then exit the pod's shell:

exit

Why the IDENTIFIED BY clause with GRANT? While the user itops already exists from the envFrom in the MySQL deployment, granting privileges explicitly with IDENTIFIED BY ensures the user has the correct authentication method and password set within MySQL itself, especially for older MySQL versions or specific scenarios. Modern MySQL versions handle user creation and authentication slightly differently with CREATE USER and then GRANT, but this combined command is often used for simplicity.

2. Accessing iTop from the UI (Dekho, Ab Chal Gaya!):

Now for the moment of truth! We need to find the external IP address assigned to our iTop service.

kubectl get svc -n itops

Look for the itops-cmdb-service. Under the EXTERNAL-IP column, you'll find the IP address. If it shows <pending>, your cloud provider is still provisioning the LoadBalancer. Give it a few minutes and try again. For minikube or kind, you might see a NodePort or need to use minikube service itops-cmdb-service --url to get the URL.

Once you have the external IP, open a web browser and enter http://<external-IP>.

You should now be greeted by the iTop web installer! Follow the on-screen instructions:

1. Welcome: Click "Next".
2. License: Accept the license.
3. Prerequisites: It should pass all checks because we've configured PHP and MySQL correctly.
4. Database Connection: The fields for hostname, user, and password should ideally be pre-filled or suggested based on the environment variables we passed. If not, enter mysql-service as the host, itops as the user, Premaa@1965 as the password, and itops as the database name.
5. New Installation: Select "Install a new iTop instance".
6. Configuration: Choose your configuration options (e.g., enable change management, service management).
7. Admin Account: Create your iTop administrator account.
8. Summary & Installation: Review and proceed with the installation.

Once the installation is complete, you will be redirected to the iTop login page. Congratulations, you've successfully installed iTop CMDB on Kubernetes!

Advanced Considerations and Best Practices for Production

While our basic setup for iTop CMDB on Kubernetes is complete, a production environment demands more robustness, security, and scalability. Let's discuss a few crucial areas you'll need to consider.

Persistent Storage for MySQL (Data Loss Nahi Chahiye!):

As mentioned, our current MySQL deployment lacks persistent storage. This is acceptable for a quick test, but in production, if the MySQL pod restarts or is rescheduled, all your iTop data will be lost. You must implement persistent volumes (PVs) and persistent volume claims (PVCs) for your database.

Here’s a conceptual mysql-pvc.yaml:

# mysql-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce # Can be mounted as read-write by a single node
  resources:
    requests:
      storage: 20Gi # Request 20 GB of storage (adjust as needed)
  # storageClassName: standard # Optional: Specify a StorageClass provided by your cloud provider

Then, you would modify mysql-deployment.yaml to include this PVC:

# Inside mysql-deployment.yaml, add to spec.template.spec:
      volumes:
        - name: mysql-persistent-storage
          persistentVolumeClaim:
            claimName: mysql-pvc
# And add to the mysql container's volumeMounts:
      volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql # This is where MySQL stores its data

This ensures your database data persists across pod restarts and rescheduling.

Ingress for Production Access and TLS (Secure Access Zaroori Hai!):

Using a LoadBalancer service directly for iTop might be okay for some setups, but for a professional production environment, an Ingress controller is highly recommended. An Ingress provides:

• Single Entry Point: Manage access to multiple services under a single IP address.
• Domain-Based Routing: Access iTop via itop.yourcompany.com instead of an IP.
• TLS/SSL Termination: Easily configure HTTPS for secure communication using tools like cert-manager.

This would involve:

1. Deploying an Ingress controller (e.g., Nginx Ingress, Traefik).
2. Creating an Ingress resource that routes traffic from your domain to the itops-cmdb-service on port 80.

# iTop Ingress Example
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: itops-ingress
  annotations:
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: "letsencrypt-prod" # If using cert-manager
spec:
  ingressClassName: nginx # Or your chosen ingress controller class
  tls:
    - hosts:
        - itop.yourcompany.com
      secretName: itop-tls # Kubernetes secret for your TLS certificate
  rules:
    - host: itop.yourcompany.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: itops-cmdb-service
                port:
                  number: 80

Remember to provision a proper DNS A record for itop.yourcompany.com pointing to your Ingress controller's external IP.

Resource Management and Scaling (Thoda Scale Bhi To Karenge!):

We’ve set basic requests and limits for memory and CPU, which is good. For a production iTop instance, you might need to adjust these based on your expected workload. Also, consider setting up Horizontal Pod Autoscalers (HPAs) for both iTop and potentially MySQL (if using a highly available MySQL setup like Percona XtraDB Cluster or MySQL InnoDB Cluster on K8s) to automatically scale pods based on CPU or memory usage.

Security Hardening (Safety First!):

• Secrets: Never commit raw secrets to version control. Use tools like Sealed Secrets or a secrets management solution like HashiCorp Vault.
• Network Policies: Implement Kubernetes Network Policies to control traffic flow between your iTop pods, MySQL pods, and other services. For example, only allow the iTop pod to connect to the MySQL service.
• Least Privilege: Ensure your containers run with the minimum necessary privileges.

Monitoring and Logging (Kya Ho Raha Hai, Dekhna Padega!):

Integrate your iTop and MySQL deployments into your cluster’s monitoring and logging solutions (e.g., Prometheus for metrics, ELK Stack or Grafana Loki for logs). This is crucial for troubleshooting, performance tuning, and proactive issue detection.

By incorporating these advanced considerations, you can transform your basic iTop CMDB on Kubernetes setup into a resilient, secure, and scalable solution ready for enterprise-level IT asset and service management. This is the difference between a proof-of-concept and a production-ready deployment, yaaron.

Key Takeaways

• iTop CMDB on Kubernetes offers a robust, scalable, and manageable solution for IT asset and service management by leveraging containerization benefits.
• Properly segmenting your deployment with Kubernetes Namespaces is a fundamental best practice for organization and isolation.
• Kubernetes Secrets are essential for securely managing sensitive information like database credentials, and stringData makes YAML definitions more readable.
• For production environments, Persistent Volume Claims (PVCs) are critical for databases like MySQL to prevent data loss upon pod restarts or rescheduling.
• Configuring environment variables within your iTop deployment YAML is crucial for the application to correctly connect to its MySQL backend, preventing common configuration errors.
• An Ingress controller is highly recommended for production iTop deployments for domain-based access, URL routing, and seamless TLS/SSL termination.
• Always prioritize security hardening, resource management, and comprehensive monitoring for any production-grade deployment on Kubernetes.

Frequently Asked Questions

What is iTop CMDB and why use it on Kubernetes?

iTop is an open-source IT service management (ITSM) and Configuration Management Database (CMDB) tool that helps organizations manage their IT assets, services, and relationships effectively. Deploying iTop on Kubernetes provides significant advantages, including enhanced scalability, high availability, declarative infrastructure management, and simplified deployment, allowing for efficient resource utilization and resilience compared to traditional deployments.

How do I ensure data persistence for MySQL in my Kubernetes iTop deployment?

To ensure data persistence for your MySQL database in a Kubernetes iTop deployment, you must use Persistent Volume Claims (PVCs) and Persistent Volumes (PVs). This involves defining a PersistentVolumeClaim in your YAML and then referencing that claimName within your MySQL Deployment's volumes and volumeMounts sections, typically mounting to /var/lib/mysql inside the MySQL container. Without PVCs, all database data will be lost if the MySQL pod restarts or is deleted.

What if I encounter the "ConfigException" error during iTop setup?

The "ConfigException" error, often indicating "Undefined array key" for database variables (like DB_ENV_MYSQL_DATABASE), typically means the iTop application container is not receiving the necessary database connection details. The primary fix is to ensure your itops-cmdb-deployment.yaml includes an env section in the container definition, pulling database credentials (host, port, username, password, database name) from your mysql-secret using valueFrom: secretKeyRef. This securely injects the required environment variables into the iTop pod.

How can I access iTop securely using a custom domain and HTTPS?

To access iTop securely via a custom domain (e.g., itop.yourcompany.com) and HTTPS, you should implement an Ingress controller (like Nginx Ingress or Traefik) in your Kubernetes cluster. You then create an Ingress resource that maps your custom domain to the itops-cmdb-service. For HTTPS, you'd typically integrate with a certificate manager (like cert-manager) to automatically provision and renew TLS certificates, ensuring encrypted communication for your iTop web interface.

There you have it, junior. A complete deep dive into getting iTop CMDB up and running on Kubernetes. Remember, the journey doesn't end with deployment; continuous improvement and adherence to best practices are key. If you found this guide useful, make sure to watch the original video on this topic and subscribe to @explorenystream for more such valuable DevOps content. Keep exploring, keep learning!