I did not (yet) dive deeper into KubeApps so I cannot compare it. Knowing the work Bitnami does with Helm charts, I suspect it's great for that type of a tool. Let me dive into KubeApps a bit more and get back to you...
Got Lens and k9s installed. 99% of the time I use k9s. A must. Every now and then I try Lens… and go back to k9s. Maybe one day I’ll consider k9s alpha…
I have to admit, I used Lens as a learning tool and to get together my first ever cluster (running on VMs with k3s). I used k3sup to build the initial cluster, then used Lens to build it out. It's been a good experience and I've learned a lot (like a lot of the warnings you've given in this video too). I'd also suggest Lens would be a good tool for local cluster management IF (and only if) you are doing it on your own for whatever reasons. It is definitely more efficient than working with the terminal, especially for troubleshooting, because Lens shows you graphically, when something isn't running right. And that leads me to a question. Let's say we want to give developers a simple path to running a pre-modelled k8s cluster locally, i.e. there are a good number of required resources necessary to develop for a particular platform, like certain databases and other services. What would be the best tool or tools to offer a developer to basically (hopefully) have a one-touch running k8s cluster. I'm thinking of something kinda like docker-compose up? Is that even possible? Ok. Ok. Docker has to be running already for docker-compose to do its thing. Still, I'd love to be able to offer a one-touch install for a k8s cluster locally, then just offer a Helm chart of something to that effect to get the cluster up to speed. 🤔
There is a wrong assumption in the industry that Docker Compose is easier than, let's say, Helm. One argument is that it is easier to define Compose manifest compared to Helm templates, but that is not true since you'll have to define it anyway for production (assuming that production is k8s). The second argument is that Compose is easier to operate than Helm which is also not true. Both are single command (`docker compose up` vs `helm install`). What I'm trying to say is that you should indeed give Helm to devs to spin up locally the same things that you're running in production (with few variations like the number of replicas, host, etc.). If, in the future, you start offering remote dev environments (e.g., vCluster, dedicated Namespace, etc.), than it becomes even better if you define apps through OAM/KubveVela or Crossplane.
@@DevOpsToolkit Yeah, after thinking about what I just wrote, Helm is the counterpart to Docker Compose and theoretically the whole process could be automated via a shell script. Build out the cluster, run the helm chart. Bam. Running k8s with all the necessary bells and whistles. I'm just in the middle of watching your Kind review. Seems almost every question I come up with, you've covered somewhere in your videos. Thanks for that. 😁
@@scottamolinari Check out Rancher Desktop instead of KinD (th-cam.com/video/bYVfCp9dRTE/w-d-xo.html and th-cam.com/video/evWPib0iNgY/w-d-xo.html). That's my current recommendation for running local k8s cluster. There are certainly many things I did not cover and most of the material already available is based on requests. So, just let me know what you need (what is missing) and I'll add it to my TODO list.
Lens does not simplify the complexity of k8s in any form or way. It only provides a graphical UI that (partly) replaces `kubectl`. Kubernetes simplification will likely be archived through CRDs like Knative, OAM/KubeVela, GKE Autopilot, etc.
Actually Kubernetes is not so complex by itself. Its complex in the sense that there are so many config parameters available, its really easy to make mistakes when deploying a large cluster across different machines.
@@sf2998 That's why I prefer the GitOps approach to managing k8s resources (or anything else). If all the manifests are stored in Git, it is easier to review, collaborate, see the history, etc. I can test a change in one cluster and be sure that exactlt the same change will be applied to the production cluster later. And so on and so forthe. The importance of that increases with the size of a cluster or the number of clusters.
I open Lens and I can click around, I get it, I see things. I see CRDs - nice! The visuals are nice on pods and being able to click into logs is nice too. It's easy convenient and intuitive - for a dashboard.
Exactly. The keyword is "dashboard". Tools like Lens can be great for observing what's in the cluster, not for managing it. It should not be used as an IDE.
I love Len's, simply because its Desktop based, makes it great for self-hosted and lab clusters, being able to quickly click and drill through configuration has saved me hours of cli clickety-clack! But yes, it 100% is not an IDE... If you have a well configured cluster with Prometheus etc, it will pull all the resources and graphs from that, and its blazingly fast.
My complain of Lens is it required login, and this is inconvinent. My employer need pay for it, which is a bad idea. If I login use my personal account, it's not safe, at least it's violate company policy.
You're right. I did not make something better since I work on other types of tools. Does that mean that only those working, in this case, on Kubernetes dashboards, are entitled to share their experience using them? Should I be a sci-fi movie director to say that Matrix 2 and 3 were bad?
![[k8s] Администрировать кластера kubernetes просто. Обзор Lens](http://i.ytimg.com/vi/mX0tnNvgkH0/mqdefault.jpg)
Are you using a Kubernetes dashboard or an IDE? If you are, which one do you prefer?
What do you think about kubeapps?
I did not (yet) dive deeper into KubeApps so I cannot compare it. Knowing the work Bitnami does with Helm charts, I suspect it's great for that type of a tool.
Let me dive into KubeApps a bit more and get back to you...
As a newbie, I am using only VIM and the CLI
Just published a video about Kubeapps: th-cam.com/video/DJ_k5fhODi0/w-d-xo.html
Thanks for featuring us! Greatly appreciated!
Got Lens and k9s installed. 99% of the time I use k9s. A must. Every now and then I try Lens… and go back to k9s. Maybe one day I’ll consider k9s alpha…
I still did not have time to check whether k9salpha is worth $$$. Until then, k9s is my go-to dashboard.
Thanks for hinting at K9s, so much happier at work!
Oh yeah. K9s is amazing.
I have to admit, I used Lens as a learning tool and to get together my first ever cluster (running on VMs with k3s). I used k3sup to build the initial cluster, then used Lens to build it out. It's been a good experience and I've learned a lot (like a lot of the warnings you've given in this video too). I'd also suggest Lens would be a good tool for local cluster management IF (and only if) you are doing it on your own for whatever reasons. It is definitely more efficient than working with the terminal, especially for troubleshooting, because Lens shows you graphically, when something isn't running right.
And that leads me to a question. Let's say we want to give developers a simple path to running a pre-modelled k8s cluster locally, i.e. there are a good number of required resources necessary to develop for a particular platform, like certain databases and other services. What would be the best tool or tools to offer a developer to basically (hopefully) have a one-touch running k8s cluster. I'm thinking of something kinda like docker-compose up? Is that even possible? Ok. Ok. Docker has to be running already for docker-compose to do its thing. Still, I'd love to be able to offer a one-touch install for a k8s cluster locally, then just offer a Helm chart of something to that effect to get the cluster up to speed. 🤔
There is a wrong assumption in the industry that Docker Compose is easier than, let's say, Helm. One argument is that it is easier to define Compose manifest compared to Helm templates, but that is not true since you'll have to define it anyway for production (assuming that production is k8s). The second argument is that Compose is easier to operate than Helm which is also not true. Both are single command (`docker compose up` vs `helm install`).
What I'm trying to say is that you should indeed give Helm to devs to spin up locally the same things that you're running in production (with few variations like the number of replicas, host, etc.). If, in the future, you start offering remote dev environments (e.g., vCluster, dedicated Namespace, etc.), than it becomes even better if you define apps through OAM/KubveVela or Crossplane.
@@DevOpsToolkit Yeah, after thinking about what I just wrote, Helm is the counterpart to Docker Compose and theoretically the whole process could be automated via a shell script. Build out the cluster, run the helm chart. Bam. Running k8s with all the necessary bells and whistles. I'm just in the middle of watching your Kind review. Seems almost every question I come up with, you've covered somewhere in your videos. Thanks for that. 😁
@@scottamolinari Check out Rancher Desktop instead of KinD (th-cam.com/video/bYVfCp9dRTE/w-d-xo.html and th-cam.com/video/evWPib0iNgY/w-d-xo.html). That's my current recommendation for running local k8s cluster.
There are certainly many things I did not cover and most of the material already available is based on requests. So, just let me know what you need (what is missing) and I'll add it to my TODO list.
Thanks for the review. Do you think Kuberentes is still overly complicated even when using the Lens IDE?
Lens does not simplify the complexity of k8s in any form or way. It only provides a graphical UI that (partly) replaces `kubectl`.
Kubernetes simplification will likely be archived through CRDs like Knative, OAM/KubeVela, GKE Autopilot, etc.
Actually Kubernetes is not so complex by itself. Its complex in the sense that there are so many config parameters available, its really easy to make mistakes when deploying a large cluster across different machines.
@@sf2998 That's why I prefer the GitOps approach to managing k8s resources (or anything else). If all the manifests are stored in Git, it is easier to review, collaborate, see the history, etc. I can test a change in one cluster and be sure that exactlt the same change will be applied to the production cluster later. And so on and so forthe.
The importance of that increases with the size of a cluster or the number of clusters.
I open Lens and I can click around, I get it, I see things. I see CRDs - nice! The visuals are nice on pods and being able to click into logs is nice too. It's easy convenient and intuitive - for a dashboard.
Exactly. The keyword is "dashboard". Tools like Lens can be great for observing what's in the cluster, not for managing it. It should not be used as an IDE.
I love Len's, simply because its Desktop based, makes it great for self-hosted and lab clusters, being able to quickly click and drill through configuration has saved me hours of cli clickety-clack!
But yes, it 100% is not an IDE... If you have a well configured cluster with Prometheus etc, it will pull all the resources and graphs from that, and its blazingly fast.
im using lens for already 2 years :'v. Tyu i like your video
Isn't it acquired by Mirantis?
I'm not sure whether it was acquired or developed from scratch by mirantis. In any case, they are behind Lens.
The Thing you say at 4:10 is in the current beta
That's great.
Very funny.. great ideas
My first comment
Thanks Viktor
My complain of Lens is it required login, and this is inconvinent. My employer need pay for it, which is a bad idea. If I login use my personal account, it's not safe, at least it's violate company policy.
True
K9s only, I don’t need more.
The only correct answer. K9s is ❤️
So why don't you make something better that has all the feature you claiming. I'm just saying.
You're right. I did not make something better since I work on other types of tools. Does that mean that only those working, in this case, on Kubernetes dashboards, are entitled to share their experience using them? Should I be a sci-fi movie director to say that Matrix 2 and 3 were bad?