Takeover Lifecycle Management of Amazon EKS Clusters¶
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.
Background¶
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.
What Are We Seeing?¶
We are seeing an accelerating trend with our customers transitioning the lifecycle management responsibilities of "existing EKS clusters" to the Rafay Kubernetes Operations Platform. When we ask them "Why and Why Now?", they share the following with us.
Efficiency¶
Customers seem to be fatigued with "lifecycle management" of clusters and categorize it as "repetitive, undifferentiated" work. By offloading this to the Rafay platform's "built in" automation and lifecycle management for Amazon EKS clusters, they no longer have to develop and maintain required automation. As a result, they are able to to refocus their limited technical resources on higher value tasks that propels their business forward.
GitOps for EKS Lifecycle¶
Many customers seem to really prefer GitOps for lifecycle management of Amazon EKS clusters. They seem to prefer to maintain version controlled declarative specifications for their EKS clusters in their Git repositories.
ClickOps to Code¶
Many customers tell us that many of their users tend to start an Amazon EKS cluster's life with "ClickOps" because of time constraints.
They seem to really like the platform's ability to automatically generate a declarative specification for the EKS cluster and automatically keep this in sync with a configured Git repository.
Important
Given the growing interest in this capability, we intend to write a dedicated blog about this very soon.
Self Service¶
Organizations find themselves struggling to scale to support the needs of multiple application teams and business units especially pre-production, development environments.
They tell us that they prefer to provide a self service experience for their scenarios by leveraging cluster templates in the Rafay platform.
The Lab Exercise¶
Back to our hands-on lab. We had provisioned approximately 30 Amazon EKS Clusters in our AWS account with one EKS cluster dedicated to each attendee for the hour. We wanted each attendee to experience what it takes to "takeover lifecycle management" of these brownefield EKS clusters. Here are the three simple steps each attendee followed:
Step 1¶
Import the "brownfield" Amazon EKS Cluster into their project in the "Training" Org. This step can take a couple of minutes.
Step 2¶
Click on the "Convert to Managed" option on their EKS cluster. This step takes 2-3 minutes as well. The platform will automatically detect all the infrastructure resources as it performs the takeover.
Step 3¶
To demonstrate that the platform can now perform lifecyle management, they performed from the list of Day-2 operations. For example,
- Add a new node group
- Scale existing node groups
- Upgrade the EKS cluster to a new Kubernetes version
- Update the AMIs powering the nodes.
- Add IRSAs etc
It was great to see all 30 users complete this exercise in minutes and convert their imported EKS clusters to managed.
...