Operations | Monitoring | ITSM | DevOps | Cloud

With our latest releases of Epinio, we’ve focused on making both the setup and developer experience much more streamlined. We’ve looked at where users are having issues and removed many of the roadblocks. This reduced footprint also allows for more customizability and easier long-term maintenance. If you are not familiar with Epinio, it is an application development engine for Kubernetes that lets you go from code to URL in a single step.

Kubernetes provides a set of primitives to run resilient, distributed applications. It takes care of scaling and automatic failover for your application and it provides deployment patterns and APIs that allow you to automate resource management and provision new workloads.

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.