We just rolled out "enhancements" and "new functionality" from our upcoming v1.24 release to our Preview environment. This release will be promoted to our "Production" environment in a few weeks. Learn more about our Preview Environment and about the enhancements and new functionality in the v1.24 release.
How Platform Teams can enable developers to use their preferred Kubernetes Tools¶
There are cases where developers may prefer to use tools on their laptops such as Lens Desktop to visualize resources and interact with Kubernetes clusters. The use of a desktop based app such as Lens can be a better user experience for developers over the Kubectl CLI.
In this blog, we will describe how Platform Teams can use Rafay’s Zero-Trust Access service to enable developers to use popular Kubernetes visualization apps to troubleshoot their applications. Watch a video showing how a developer can use Lens Desktop with Rafay's Zero Trust Kubectl Access service to securely and remotely access Kubernetes clusters.
In this blog, we will look at the process used by Microsoft Azure to add support for new Kubernetes versions for their "Managed" Azure Kubernetes Service (AKS). We will also look at recommendations for customers on things they need to consider to operate their AKS clusters at scale without issues.
Azure's AKS managed Kubernetes is supported globally in 60+ regions. As one can imagine, it is not practical to update software in all these regions in one fell swoop. The AKS team at Microsoft employs a Safe Deployment Practice (SDP) where new releases are rolled out gradually in phases. This means that any given time, something new is being rolled out to some region.
The AKS team maintains a Release Tracker that provides visibility to customers that require it.
Considerations for In-Place Upgrades to Amazon EKS v1.24¶
Recently, AWS added support for Kubernetes v1.24 for their Amazon EKS offering. One significant change with this version is the removal of Dockershim as the Container Runtime (CRI). Amazon EKS clusters v1.24 onwards are standardized on "containerd".
New Amazon EKS v1.24 clusters are provisioned with containerd. Watch a brief video showcasing how customers can use Rafay to configure and provision an Amazon EKS v1.24 cluster.
When EKS clusters are upgraded to v1.24, the nodes in the EKS cluster's data plane are seamlessly migrated from "Dockershim" to "containerd".
A[Dockershim] --> B[Containerd];
Although this transition is mostly "behind the scenes" for users, the transition from Dockershim -> Containerd can cause disruptions to deployed applications that may be dependent on Docker. In this blog, we will look at what Rafay has done to protect our customers during an in-place upgrade to EKS v1.24.
Considerations for Windows Containers on Kubernetes¶
With increasing adoption of Kubernetes in organizations, we are seeing interest from a number of customers that would like to deploy and operate their "legacy Windows applications" on Kubernetes as well.
In this blog, we have attempted to capture our learnings from working with customers that use the Rafay Kubernetes Operations Platform to deploy and operate Kubernetes clusters with Windows based containerized applications.
Many customers of the Rafay Kubernetes Operations Platform are "Platform Teams". In many cases, the first priority for these platform teams is to "take over and standardize" existing Kubernetes clusters in active use by application teams.
However, one of the challenges they run into with the take over process is nobody in the team has complete clarity into what resources already exist on the cluster and for what purpose. Identifying an accurate list manually can be extremely error prone and time consuming for both the platform teams as well as the various application teams resulting in delays in adoption and standardization efforts.
These past few months, we've invested a lot of time as a team working to create a more seamless experience for our customer-facing product documentation. While we built a lot of content covering key functionality of the platform, one of the key questions that would arise from our readers was how do I know where to start?
Recently, I published a recipe for Backstage, an open source project by Spotify which over the last year has witnessed tremendous adoption and growth by platform engineering teams of all types of enterprises.
Some of the key features of Backstage include:
an easy-to-use interface for developers
extensible plugin ecosystem (for ex. plugins available for GitHub Actions, ArgoCD, AWS, and more)
ability to easily build and publish tech documentation
native Kubernetes plugin for cloud-native apps
ability to compose different developer workflows into an Internal Developer Portal (IDP)
Spinning up cost effective clusters for training sessions¶
We have been running a number of internal and external (with partners/customers) enablement sessions over the last few weeks to provide "hands-on, labs based training" on some recently introduced capabilities in the Rafay Kubernetes Operations Platform.
Here's what we setup for those enablement sessions:
Each attendee was provided with their own Kubernetes cluster
We spun up ~25 "ephemeral" Kubernetes clusters on Digital Ocean (for life of the session)
We needed the clusters to be provisioned in just a few minutes for the training exercise
Each attendee had their own dedicated "Project" in the Rafay Org
A question that we frequently got asked after those enablement sessions was "I would love to run similar sessions with my extended team, how much did it cost to run those clusters?".
Our total spend for ~25 ephemeral clusters on Digital Ocean for these enablement sessions was less than $15. It was no wonder there has been so much interest in this.
We decided that it would help everyone if we shared the automation scripts and the methodology we have been using to provision Digital Ocean clusters and to import them to Rafay's platform here.
Around three years back, we noticed many of our customers struggling with enterprise wide standardization of their Kubernetes clusters. Every cluster in their Organization was a snowflake and they were looking for a way to enforce that every cluster had a "baseline set of add-ons". This prompted us to develop Cluster Blueprints which has turned out to be one of the most heavily used features in our platform.
In this blog, we will describe a superpower setting in the cluster blueprints feature that we see customers use heavily for their production clusters to secure against unplanned drift.