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.
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.
Earlier this year, AWS added support for Kubernetes v1.23 for their Amazon EKS offering. One significant change with this version is with the Container Storage Interface (CSI) for working with AWS Elastic Block Store (Amazon EBS) volumes.
Specifically, the updates to the CSI driver require customers to take action to ensure a seamless upgrade process for EKS clusters from previous versions. The CSI was developed in Kubernetes to replace the in-tree driver. With the CSI, there is now a simplified plug-in model that makes it easier for storage providers to decouple their releases from the Kubernetes release cycle.
graph LR
A[In-Tree Storage Driver] --> B[CSI Plugin for EBS CSI];In a nutshell, this transition is good for Amazon EKS users because they do not have to upgrade Kubernetes versions for their EKS clusters just to get some additional functionality or bug fixes for EBS storage via the "in-tree driver".
Are you an App Developer struggling to learn the basics of Kubernetes because you have no time and no access to resources that help you with this in a step-by-step manner?
We invest a lot of time creating and maintaining our customer facing product documentation. Over the last few years, as we added significant width to our platform, we found ourselves in a situation where the way the content was presented especially for new users was overwhelming to them.
We have been working behind the scenes for a few weeks to present the breadth of capabilities of the platform in our documentation in a format that is "visually easy" for the user to navigate. Today, we launched our refreshed Product Documentation site. We thought it would be fun to memorialize this milestone by writing a brief blog.
We invest a lot of time training our employees, partners and customers on capabilities that are seeing a lot of inbound interest from our customers.
Earlier this week, we provided "hands-on, labs based training" for approximately 30 technologists on a very interesting "capability" in the Rafay Kubernetes Operations Platform.
Many of our customers that use AWS typically already have a few Amazon EKS clusters provisioned and in use before they intercept with the Rafay Kubernetes platform. They may have provisioned these clusters using Terraform or one of the many alternatives that exist in the market.
As they start using the platform, they naturally stumble onto the "Convert to Managed" option next to their imported EKS clusters and learn about this capability.
Last week, we wrapped up "hands-on enablement" on our recently released "Integrated Cost Management" service for approximately 25 technologists. Here's what the team experienced in the 60-minute lab.
1. What does it take to enable cost visibility and management for a fleet of clusters spanning Amazon EKS, Azure AKS, and on-premises clusters in data centers?
With the Rafay Kubernetes Operations Platform, you can do this literally in a "single click/step".