How To Troubleshoot Kubernetes Applications With Komodor

[@DevOpsToolkit]

What do you think about Komodor's ability to connect the tools and provide the context? IMPORTANT: For reasons I do not comprehend (and Google support could not figure out), KZbin tends to delete comments that contain links. Please do not use them in your comments.

[@Ruben-by4oy]

The most important issue with this tool - I don't want to share access to my cluster with some external service. If you have gitops implemented (like ArgoCD) then changes in code will be easy to discover. If you want some visibility of your cluster components, install Lens and use UI to manage your cluster.

[@drogunsky]

IMO Quite unique tool in the way to provide more vision into troubleshooting. However my personal issue will be that you cannot deploy this tool locally (or at least it that I understood please correct me if I’m wrong) and need to relay to 3rd party in terms of security. For extra secure environments it can be big blocker.

[@DevOpsToolkit]

That is the indeed true. It works only for those looking for a SaaS solution.

[@kevinyu9934]

Would you like to do a demo on Falco? I've seen a trend and increasing usecases around Falco xD

[@DevOpsToolkit]

I already have it on my TODO list. Let me bump it up to be closer to the top of the list...

[@VicenteFontanella]

Holla Victor, this tools seems to have a brilliant future, but I was wondering about security mechanisms to protect the cluster. My concern is about connectivity between the cluster (let’s say an EKS cluster) and the application itself. How that will work out?

[@DevOpsToolkit]

Typically, a new company starts with SaaS or a self-hosted solution and, eventually, moves into having both options. Otherwise, it might be too much to do both at the same time. Now, I do not know whether that will happen with Komodor as well, but I would be surprised if it does not come up with a self-hosted solution during 2022.

[@arifsali]

All these Komodor features are available in OpenShift out of the box (for the long period of time). Am I missing something?

[@DevOpsToolkit]

OpenShift is an ecosystem on its own and RedHat users tend to rely heavily on whatever is in the package. I think that Komodor, just as many other k8s-related projects are more for the rest of k8s users.

[@Yrez1234]

Hi Viktor, thanks for the great video! One of useful troubleshooting information would be to have Git information (commit message, code diff) between service version (image 1.1.0 and 1.0.0 for instance). This way, if our application is broken, we know which code changes occured in the last release. Are you aware if there is any way to add this kind of troubleshooting information, using komodor or other tool?

[@DevOpsToolkit]

Komodor can show that information but you need to add a label with the commit hash to k8s manifests. If you do, Komodor will fetch the info you need from that commit and compare it with the previous one. That works but is also one of my main complaints. I tend to use Argo CD and Flux for deployments. Since those are GitOps tools that are pulling manifests from Git, they already know what the commit is so, instead of adding labels to my manifests, I would prefer if Komodor would "discover" that info without them. So, the info is there and the only question is where you'll find it. If you use Argo CD or Flux, it's there no matter what and if you're not using those, you'll have to add a few labels so that Komodor can find it.

[@jonassteinberg3779]

What's the difference between Komodor and something like Lens or Infra? What benefit do the integrations bring, specifically?

[@DevOpsToolkit]

Tools like Lens are giving you insights into what's running in your Kubernetes clusters and do not focus much to create relations with the tools and processes that led to the specific state of your k8s cluster. A tool like Lens can also be used to manage the state of the resources in a cluster, but that's something that should be avoided. Click-ops is not a good thing when used alone. Komodor is more focused on debugging issues in k8s and providing a context by connecting the state of a k8s cluster with the tools that led to that state.

[@jonassteinberg3779]

@@DevOpsToolkit what will this give me that a datadog integration won't? Just "newer"?

[@DevOpsToolkit]

@@jonassteinberg3779 I haven't used DataDog in a while so I'm not up-to-date how it looks like now. In the past, DataDog was mostly focused on metrics and logs, similar to Elastic. If that's still it's main focus, than there are some similarities with Komodor, but they are still very different in their main objectives. Komodor tries to provide broader context that we can use to debug issues while DataDog is more focused on direct metrics and logs. I tend to use Prometheus combined with Loki and, assuming that those are somehow similar to DataDog, I'd say that Komodor complements it rather than competing with it.

[@jonassteinberg3779]

@@DevOpsToolkit You're the best!

[@franciscoagurto2227]

i know this has nothing to do with this but , have you taken a look on kubevela gitops "native" support ? , it would be nice to have a video on that subject , do we still need argo or flux ? , i really like and enjoy your videos victor , thumbs up!

[@DevOpsToolkit]

I guess you're referring to kubevela.io/docs/case-studies/gitops. I think that's new since I could swear that it did not exist the last time I checked the docs (6 months ago approx). Now I am very curious to see what they "cooked". Adding it to my TODO list... :)

[@franciscoagurto2227]

@@DevOpsToolkit yes indeed , i think it is part of their 1.1 release , just having a quick look it seems like overlaps some functionality with argo and flux , i got to know kubevela because of your videos and i've been poking around with it , it is pretty awesome . thumbs up again and thank you for your amazing content

[@jonassteinberg3779]

haha my man said "be ashaaaamed" 🙏

[@yxycman]

Atlassian users cry now :)