I use Komodor for troubleshooting the platform, focused on tracking logs and also things like crashes and configuration. We use it in our Kubernetes in the CI/CD pipeline.After a new deployment, sometimes the pod crashes and fails, so we use Komodor to open it in the timeline and see the deployment, the config, and understand the config that was changed right before the failure. For example, once we deployed something and the pod crashed, we tried to understand why it crashed, and thanks to Komodor, we found out that the environment variable was missing. In conclusion, we use Komodor to trace a production issue in the deployment, and the timeline showed the configuration change that caused the pod crashes, allowing us to roll back immediately. Komodor also provides us the ability to see all the services we have, giving us a full picture of everything. It helps us understand why our CI/CD pipeline was not stable. Our cluster changed, we found new images version deployed, and that was a real bug. Thanks to Komodor, we found this flaky situation in our CI/CD and fixed it.
My main use case for Komodor is visualizing the workloads that we deploy onto the Kubernetes infrastructure across all three major clouds using Azure, EKS, AKS, and Google Cloud. We use Komodor to ensure application teams and other teams can visualize their applications running on the Kubernetes infrastructure. A specific example of how my team uses Komodor to visualize those workloads is that there are application teams who do not have access to Kubernetes jump hosts, so they use Komodor for accessing their applications from the Komodor UI. They use Komodor on a day-to-day basis to check if their workloads are running properly or if there are any issues. If the workloads are not running and are experiencing issues, they use Cloud AI integrated in Komodor for debugging the logs.
We are an HR analytics company, and we do a lot of data processing. Our customers send us their HR-related data, and we process it so that we can run analytics on it. We process it on Kubernetes clusters, and we use Komodor to monitor our clusters to ensure that the clusters are reliable, to troubleshoot them, and to optimize the setup to make it cost-efficient for us. My usage of Komodor may be a bit unusual because I go into it to troubleshoot or monitor something. I usually go in with a specific goal of looking at something via Komodor, so I use the workflows more than the dashboards. Either I'm running some process and want to monitor it in Komodor, or there is an incident and I want to find out what's going on via Komodor. I also look at the dashboard, and I can see at times that something does not look quite right. That's useful.
We use Komodor for two prominent use cases. The first is from an operational standpoint. It is our number one troubleshooting tool for our operations teams. The second is developer enablement. We use Komodor to allow developers to interact with their Kubernetes clusters, get alerts, and see what is going on without giving them direct access to Kubernetes. It is very helpful.
Senior SRE at a computer software company with 501-1,000 employees
Real User
May 23, 2023
We didn't have a very good story for our product engineers to help them visualize their application, post-deployment after migrating from Singularity to Kubernetes. Singularity has a nice user interface where they could see the deployments and scale, balance, restart, et cetera. When we moved to Kubernetes, things were more hidden. All we had was the Kubernetes Dashboard, which is verbose and clunky. We were looking for something to help our engineers visualize their deployments and troubleshoot them.
DevOps Engineer at a retailer with 1,001-5,000 employees
Real User
Mar 16, 2023
We have a multi-cluster setup with a lot of workloads being distributed throughout those clusters. Komodor is installed on all our clusters as a base component. We wanted an easy way for operations staff who are not as experienced to be able to look into what might be wrong with workloads across these clusters.
Komodor offers enhanced visibility and centralized event timelines for Kubernetes environments, enabling efficient debugging and proactive management across multiple clusters.Komodor provides a comprehensive platform for troubleshooting and monitoring Kubernetes deployments. It aids in root cause identification, deployment notifications, and tracking historical changes while maintaining real-time metrics and retained logs. The platform supports efficient CI/CD pipeline management and...
I use Komodor for troubleshooting the platform, focused on tracking logs and also things like crashes and configuration. We use it in our Kubernetes in the CI/CD pipeline.After a new deployment, sometimes the pod crashes and fails, so we use Komodor to open it in the timeline and see the deployment, the config, and understand the config that was changed right before the failure. For example, once we deployed something and the pod crashed, we tried to understand why it crashed, and thanks to Komodor, we found out that the environment variable was missing. In conclusion, we use Komodor to trace a production issue in the deployment, and the timeline showed the configuration change that caused the pod crashes, allowing us to roll back immediately. Komodor also provides us the ability to see all the services we have, giving us a full picture of everything. It helps us understand why our CI/CD pipeline was not stable. Our cluster changed, we found new images version deployed, and that was a real bug. Thanks to Komodor, we found this flaky situation in our CI/CD and fixed it.
My main use case for Komodor is visualizing the workloads that we deploy onto the Kubernetes infrastructure across all three major clouds using Azure, EKS, AKS, and Google Cloud. We use Komodor to ensure application teams and other teams can visualize their applications running on the Kubernetes infrastructure. A specific example of how my team uses Komodor to visualize those workloads is that there are application teams who do not have access to Kubernetes jump hosts, so they use Komodor for accessing their applications from the Komodor UI. They use Komodor on a day-to-day basis to check if their workloads are running properly or if there are any issues. If the workloads are not running and are experiencing issues, they use Cloud AI integrated in Komodor for debugging the logs.
We are an HR analytics company, and we do a lot of data processing. Our customers send us their HR-related data, and we process it so that we can run analytics on it. We process it on Kubernetes clusters, and we use Komodor to monitor our clusters to ensure that the clusters are reliable, to troubleshoot them, and to optimize the setup to make it cost-efficient for us. My usage of Komodor may be a bit unusual because I go into it to troubleshoot or monitor something. I usually go in with a specific goal of looking at something via Komodor, so I use the workflows more than the dashboards. Either I'm running some process and want to monitor it in Komodor, or there is an incident and I want to find out what's going on via Komodor. I also look at the dashboard, and I can see at times that something does not look quite right. That's useful.
We use Komodor for two prominent use cases. The first is from an operational standpoint. It is our number one troubleshooting tool for our operations teams. The second is developer enablement. We use Komodor to allow developers to interact with their Kubernetes clusters, get alerts, and see what is going on without giving them direct access to Kubernetes. It is very helpful.
We didn't have a very good story for our product engineers to help them visualize their application, post-deployment after migrating from Singularity to Kubernetes. Singularity has a nice user interface where they could see the deployments and scale, balance, restart, et cetera. When we moved to Kubernetes, things were more hidden. All we had was the Kubernetes Dashboard, which is verbose and clunky. We were looking for something to help our engineers visualize their deployments and troubleshoot them.
We have a multi-cluster setup with a lot of workloads being distributed throughout those clusters. Komodor is installed on all our clusters as a base component. We wanted an easy way for operations staff who are not as experienced to be able to look into what might be wrong with workloads across these clusters.