With the 1.1.0 release of Rancher Desktop, there are some changes that give you more control over your environment.

Creating a DevOps workflow to optimize application deployments to your Kubernetes cluster can be a complex journey. I recently demonstrated how to optimize your local K8s development workflow with Rancher Desktop and Skaffold. If you haven’t seen it yet, you can watch it by viewing the video below. You might be wondering, “What happens next?” How do you extend this solution beyond a local setup to a real-world pipeline with a remote cluster?

When business is growing rapidly, the necessity to scale the processes is obvious. If your initial infrastructure hasn’t been thought through with scalability in mind, growing your infrastructure may be quite painful. The common tactic, in this case, is to transition to cloud native architecture. In this post, we will talk about what you need to know when you’re scaling up with the cloud so that you can weigh the pros and cons and make an informed decision.

We covered the what, when and why of Service Mesh in a previous post. Now I’d like to talk about why they are critical in Kubernetes. To understand the importance of using service meshes when working with microservices-based applications, let’s start with a story. Suppose that you are working on a big microservices-based banking application, where any mistake can have serious impacts. One day the development team receives a feature request to add a rating functionality to the application.

We are happy to announce the 1.0.0 release of Rancher Desktop. This release has been months in the making since development on Rancher Desktop began. After starting small and learning what users needed, we were able to adjust its path and develop the features needed for a 1.0.0 stable community release. But wait – what is Rancher Desktop again? It’s an open source app for desktop Kubernetes and container management on Mac, Windows and Linux.

I recently started working at SUSE. Before joining SUSE, my Kubernetes experience included vanilla Kubernetes, AKS and EKS but mostly OpenShift and Red Hat Advanced Cluster Management. I worked in technical pre-sales, so I knew about Rancher, K3s and RKE and their key features but I never spent time with them. When I joined SUSE, I started testing Rancher, Rancher Desktop, K3s, k3d and RKE2 and I had a great time with them. First things first, I will

The lockc project provides mandatory access controls (MAC) for container workloads. Its goal is to improve the current state of container/host isolation. The lockc team believes that container engines and runtimes do not provide enough isolation from the host, which I describe later in the “Why do we need it?” Section. In this blog post, I’ll provide an introduction to lockc, discuss why you need it and show you how to try it out for yourself.

Rancher Desktop has been in development for just over a year with the open question: when do we have a 1.0.0 stable release? Along the way the scope has expanded, it was ported to run in more places and the development team has grown. All of this happened as we worked out if Rancher Desktop would be useful for people, what features people want to use and what are good ways to build it. We are finally ready to answer that 1.0.0 question.

Cloud platforms are not new — they have been around for a few years. And containers have been around even longer. Together, they have changed the way we think about software. Since the creation of these technologies, we have focused on platforms and apps. And who could blame anyone? Containers and Kubernetes let us do things that were unheard of only a few years ago.

Epinio, the application development engine for Kubernetes, is meant to take you from app to URL in one step. It does that by either applying buildpacks to your app or using a pre-built docker image. Epinio installs into any Kubernetes cluster to bring your application from source code to deployment and allow for developers and operators to work better together.