Kubernetes Troubleshooting And Management With Komodor

[@DevOpsToolkit]

What do you think of Komodor? What do you use to troubleshoot Kubernetes?

[@RafOgoogle]

Thanks for the review. Very useful as usually! Our team was using/evaluating Komodor's free version. Unfotunately they limited the free tier to only one user. Moreover they just blocked us saying that we are exceeding limits. Overall very unexpected behaviour of the team! I have mailed all our concerns and got no respons. I even cant login to delete our profile. I am using multicloud deployments with a ton of tools and never met this kind of disrespectful approach to the customer

[@mehmetdemir4781]

Hey, thank you for your videos. It's really interesting especially about K8s related ones.

[@whitehatcomua]

Setting pull policy to "Always" for versioned images is the best way to get throttled (or charged $$$ in case of enterprise docker subscription) by container registry API if several of your deployments are in the crash loop.

[@DevOpsToolkit]

You're absolutely right on that one.

[@jurgen5557]

Thx for the insight into a tool I didn't know - just a remark on editing yaml's / other resources manually via a DevOps-tool: While you are clearly right, that you shouldn't do this in general to avoid diffs to your repo, I personally also see added value in these features, because they give me a much quicker access, to try out / troubleshoot with some config, then waiting 15+ minutes on my CI/CD, having sbdy else merge etc... Sure you need to know what you're doing and sync with the repo finally instead of forgetting about the manual intervention.

[@DevOpsToolkit]

Sometimes we do need to break glass and do things manually. Nevertheless, it's important to know how to do that. Otherwise, manual interventions can easily be in conflict or be undone with automation. When using only pipelines, the situation is a bit easier since they are triggered only when we push something to Git so the solution is to make sure that whatever we did manually is later pushed to Git and, until that is done, to deny anyone write permissions to Git. When using GitOps, the situation is more complicated since the tools like Argo CD or Flux will undo whichever changes you do directly to your cluster. One solution is to push to Git and manually execute sync instead of waiting for those tools to get to the next sync cycle. Another one is to temporarily disable synchronization of those tools. What I'm trying to say is that, once deployment automation is in place (preferably GitOps instead of pipelines), doing manual changes directly in the cluster becomes dangerous. If you know how to navigate around those dangers it's OK to make changes to the cluster directly. Nevertheless, if you're not absolutely certain you understand the relation between automation and the cluster, manual intervention might easily end up taking more time or, even worse, having undesitable negative effects. With great power comes great responsability.

[@joebowbeer]

5:25 needs a "Roll forward" button 😊

[@DevOpsToolkit]

I think there should be only roll forward option (no rollback at all). If you want to roll back, undo the last commit or, even better, push a change to Git that points to the previous release.

[@sergeyp2932]

Some off-topic, but... Yesterday I re-watched your videos about Argo Workflows and Tekton. You said that eventing in Tekton (Tekton Triggers) is horrible. I looked into it myself (it was almost two years, something must have changed, right?), and found that Tekton Triggers (Argo Events analog) looking almost okay. But the tutorial ("Getting started") is still really bad. Big, scary-looking shell scripts, only to generate self-signed certificate and expose webhook receiver via Ingress. (Who needs to do it via openssl commands, if there is cert-manager?) But other examples looks almost okay, very close to Argo Events, regarding to webhooks (only disadvantage I found - Tekton wouldn't create webhook in your Github account automagically, you must do it yourself). So, maybe, not the whole Tekton Triggers is bad, but only their basic tutorial?

[@DevOpsToolkit]

Tekton triggers improved a lot but, the last time I checked they were still behind argo events. I'm not following it closely so I might be wrong though.

[@vn7057]

I am always wonder when we should use a subscription service In short term we can say we don’t need to host our debug platform for this example But I imagine in long run if we need to have say 10 cluster and we want them have same alignment config which means all cluster I need to make subscribe this kind of 3party tools licenses for each time provision a cluster 😢😢

[@DevOpsToolkit]

That depends on the service you're using but, in general, that should not be a problem. In case of Komodor, once you get the `helm install --upgrade` command it is the same for all clusters with only the name (and maybe one more thing) being different. That should be easy to do especially if you use GitOps tools like Argo CD or Flux.

[@vn7057]

@@DevOpsToolkit may be or may be not depend on cost model if the company everything require a financial team member to inserting credits card information and wait them make approval, it really no fun and big blocker here

[@erangrin1383]

I don't see how Komador helps me in troubleshooting more than using Lens for example

[@DevOpsToolkit]

It has more troubleshooting-specific features while trying to enter the Lens teritory of being Kubernetes "explorer". The same is true the other way around. Lens is first and foremost a k8s explorer with the tendency to enter the troubleshooting space.

[@erangrin1383]

@@DevOpsToolkit Ok which specific features you are talking about?

[@DevOpsToolkit]

Showing the events in a timeline view with potential issues clearly marked, notifications based on predefined queries with thresholds, integrations with observability tools like Prometheus, etc.

[@erangrin1383]

@@DevOpsToolkit Ok but to be honest I don't see any of those meaningful and/or effective addition to the troubleshooting process.

[@ioannisgko]

Thank you for the extended demo. But if a tool requires a paid subscription and in the same time it reports the wrong number of Pods in my cluster, this is simply unacceptable. The first characteristic I search for, is reliability for my toolset. And I think Komodor should be in a beta version, just for testing. Regarding its features, I personally do not see its usefulness. I can use the ArgoCD UI, Rancher/Lens, Prometheus/Grafana and I have reliable, more sophisticated dashboards that can help me troubleshoot, for free. I see zero reasons of using Komodor.

[@180doman]

Yeah, same feelings here. It MAY be fun tool to use in some non-prod/non-critical clusters but i would not dare to install it in some client clusters. Even the DEV ones not to mention PROD. Not at current state of the application. Yet my fingers are crossed for Komodor team. As Viktor said it has good potential to be really nice troubleshooter.