Helm, kubeVersion, and GKE
I was recently asked about an error someone got with Helm and GKE. The error provides some insight into how semantic versions work and how to work around cases where someone isn’t following them.
I was recently asked about an error someone got with Helm and GKE. The error provides some insight into how semantic versions work and how to work around cases where someone isn’t following them.
Several months ago, I moved from working on Rancher Desktop to work on Fleet. At the time, there wasn’t much development of Fleet and there were a lot of questions with it. Some of those were around feature requests, some of those were around bugs, and some of those were around the level of SUSE Rancher investment in Fleet.
I think actions speak louder than words. Now that we have two releases with Fleet changes behind us, I can show some of the things that have been happening.
Disclaimer: I work for SUSE but I don’t work in the Linux business unit. I’m a consumer of the base container images like anyone else who uses them.
If you’re building a containerized applications you have a base container image at the bottom. That base container image can make a difference to your stack. Is it really large which impacts what you pass around on the network and cache? Is it secure or are there vulnerabilities that will affect your operations? If you’re a company and there is a problem, can you get support?
It’s easy to pick a base container image if you’re a small company (maybe a startup) or an open source project. It’s different if you’re in a regulated industry.
SUSE has been building and shipping Linux distros since 1992. They have been doing Linux for more than 30 years. Over those years they have gained a lot of experience in shipping Linux that those in regulated industries or those who need support tend to like.
The SUSE SLES Base Container Images provide a foundation to use for various base use cases. Before I dig into them, I want to share why you might be interested in looking at them in the first place.
SLSA, the supply chain security project, as a model for attesting and verifing software artifacts. The project documentation has a whole section on software attestations. The SUSE SLE Base Container Images (BCI) are attested and you can verify them.
I’ve been regularly asked about comparisons between Docker Desktop and Rancher Desktop. As I have moved off of Rancher Desktop to work on other things at SUSE, I figure now is a good time to write up some of my thoughts. Note, there is an amazing team working on it now. They are incredibly talented and have made it better than I imagined.
First, I need to say what respect I have for the people who have worked on Docker Desktop. Having worked on a cross platform container desktop app, I’ve learned about so many nuances you have to deal with. They’ve done a lot of subtle work that I’ve learned to appreciate.
Rancher Desktop didn’t start out on a path to be in a comparison with Docker Desktop. When it began, it was all about Kubernetes and ones experience using Kubernetes on the desktop. Building and running containers were not in the initial road map. The container focused features came over time from end users with needs around Kubernetes. For example, being able to build a container image and then use it in Kubernetes without an OCI registry in the loop.
These days it’s possible for many to use Rancher Desktop as a replacement for Docker Desktop.
In full disclosure, I started Rancher Desktop. So, I am talking about one of my projects when I write this up. Keep that in mind.
Without further ado, here is a brief summary comparison: