About this video
What You'll Learn
- Komodor can be injected into every vCluster through Helm init charts
- The same release name becomes the cluster label inside Komodor
- Broken workloads surface quickly in Komodor, including image pull failures
Integrate Komodor with vCluster to auto-deploy the Komodor agent into every ephemeral virtual cluster via Helm init charts, then use Komodor to observe and debug workloads (like a broken NGINX image pull) across each vCluster from a single UI.
Jump to a chapter
- 0:00 Introduction
- 0:06 What is vCluster?
- 0:52 The Need for Observability (Introducing Komodor)
- 1:11 Demonstration Setup (Host Cluster & Goal)
- 1:49 Automating Komodor Deployment in vCluster
- 2:52 Deploying Virtual Clusters
- 3:41 Viewing New Clusters in Komodor
- 4:24 Debugging a Workload with Komodor
- 5:39 Summary and Conclusion
Full transcript
Generated from the English captions. Timestamps jump the player to that moment.
Read the full transcript
0:00 Introduction
0:00 Let's take a look at something cool. Today, we're going to integrate Komodor with vCluster. What is vCluster? VCluster is a tool from Loft that allows you to have ephemeral or potentially ephemeral clusters inside of another Kubernetes cluster. It does this by running a control plane and save a namespace on Kubernetes to give you a complete virtual cluster, hence the name vCluster inside the host cluster. There are a lot of advantages to this approach. It allows you to operate and maintain a slightly larger cluster, but delegate virtual clusters to all of your teams, organizations, or maybe even just micro services.
0:06 What is vCluster?
0:43 That means that it's very easy to delete the virtual cluster, spin up a new one and you have pretty happy days. Of course, you have to provision those clusters, those still have to be debuggable, you still need to understand when things go wrong and this is where Komodor comes in. So today, I'm going to show you how to automatically deploy Komodor to all of your virtual clusters. We'll start off with the current landscape, this is my real production scale away Kubernetes cluster which has access to six nodes. Now these nodes aren't that heavily utilized, but
1:11 Demonstration Setup (Host Cluster & Goal)
1:24 I want to open this up to members of the Rawkode Academy community and to do so, I'm going to get them a virtual cluster, but I still have to make sure those clusters are healthy and to do that, I 100% need Komodor. As you can see, I've run Komodor already on my production cluster and if we click on the cluster drop down, you'll see that I only have Skidway production. Here I have a just file, this just file has a simple target for deploying a new virtual clusters with whatever name I give it. To do this, it uses helm upgrade
1:49 Automating Komodor Deployment in vCluster
2:00 install using the arguments provided to provide the cluster name and also the values. Yaml. Instead of our values. Yaml, we see that we want all virtual clusters to be KCS, here I'm just using version 123.5. We can then use the init section of the values file to say that we wish to deploy some helm charts. Here I'm specifying one chart and that's what I want to deploy to Kubernetes workshop chart from the Komodor LJOX repository. I've hard coded my key here, but of course you can find better ways to do that through secret management or even interpolation of
2:38 the template. I'm using values template here so that I can also reference the release name as the cluster name so that I can differentiate my virtual clusters within Komodor. Now we can just run vCluster Rawkode and that should just take a few seconds. And I'm gonna run it one more time only this time we'll call it academy one two three. So with these two simple commands on my production gateway cluster, I'm deploying two virtual clusters, both those virtual clusters are configured to automatically deploy Komodor injecting the release name which happens to be the cluster name.
2:52 Deploying Virtual Clusters
3:23 What does mean is that when I browse back to Komodor in just a few seconds, we'll now have access and observability, debug ability, the ability to visualize and understand the Kubernetes landscape of our virtual clusters. Easy peasy. Well, let's jump back and hit refresh and we can see that the Rawkode cluster is still available. I'm gonna wait a few more seconds for the academy cluster to also show up. There we go. So now if we filter to Rawkode, we'll see version one twenty three point five for the two nodes in that cluster and if we switch to the academy,
3:41 Viewing New Clusters in Komodor
4:09 we're still waiting on a node coming up but that's okay. We can then use Komodor just as we always do. Here we can see the core DNS and the watcher for the academy cluster and if we switch to Rawkode, we have to save there. So let's deploy a broken workload to our virtual cluster. To do so, we do vCluster, connect to Rawkode in the default namespace and kubectl apply dash f nginx dot yaml. Easy. So let's pop back over to Komodor and already we can see our nginx deployment under the pod workloads screen and we can see that there's an error
4:24 Debugging a Workload with Komodor
4:55 pulling our image. So if we click on this and pop open the containers, we'll see that the image being used is NGINX non existent. Not really a typhoon, but a common problem that we all have to debug and one that Komodor solves with ease. Let's fix this to deploy NGINX one nineteen, and we'll run our apply command one more time. And let's just watch from the Commodore UI. We already see the new pod, we already see its container creating and now it's running. So vCluster and Commodore work together just like a charm. Take advantage of ephemeral clusters within mega clusters,
5:39 Summary and Conclusion
5:46 but don't sacrifice your ability to operate each of those clusters as well. I hope you enjoyed this video. We'll be back with more Komodor videos soon. Have a good day.
Technologies featured
Stay ahead in cloud native
Tutorials, deep dives, and curated events. No fluff.
Comments