In our July 2023 release, we added support automatic injection of project name as a cluster label. In Kubernetes, labels are key/value pairs that are attached to objects such as Pods, nodes etc.
Support for labels in Kubernetes ends at a node level. We extended the "label" construct to clusters over two years back as cluster labels. Cluster labels are critical for multi cluster workflows and have been the backbone of several unique and differentiated features in the Rafay Kubernetes Operations Platform.
In this release, we have automated the injection of the "name of the project" as a cluster label to all clusters in the project. Read on to understand some of the use cases that are enabled by this feature.
Note
In a separate blog, we will describe how cluster labels powers various multi cluster workflows and operations.
Many of our customers are platform teams that are focused on providing their end users (application developers) a great developer experience especially with ease of use with deploying and managing their applications on remote clusters. In our July 2023 release, we have enhanced the existing developer experience further by providing developers with a facility to quickly verify details about the workload under management.
Important
This enhancement was requested by multiple enterprise customers.
In our June 2023 release, we added support for a new turnkey role in the Rafay Kubernetes Operations Platform specifically targeted at users in a FinOps function.
This new role allows the FinOps team to access and view cost and usage data in the Rafay Kubernetes Operations Platform. Users with this role do not have the ability to impact infrastructure or applications.
Our recent release update in June adds support for a number of new features and enhancements. This blog is focused on support for Kubernetes v1.27 with Rafay MKS (i.e. upstream Kubernetes for bare metal and VM based environments).
Both new cluster provisioning and in-place upgrades of existing clusters are supported. As with most Kubernetes releases, this version also deprecates and removes a number of features. To ensure there is zero impact to our customers, we have made sure that every feature in the Rafay Kubernetes Operations Platform has been validated on this Kubernetes version.
Rafay has supported CentOS as an operating system for upstream Kubernetes clusters. With the EOL of CentOS, several customers asked us to support Rocky Linux as an alternative.
We just wrapped up our annual hackathon earlier this month. The theme and focus for this hackathon was AI and Generative AI and our teams had the opportunity to prototype and demonstrate fascinating solutions esp. based on Generative AI.
We had eleven (11) fully functioning submissions spanning both "external" and "internal" use cases. The panel that reviewed and judged the submissions observed extensive use of the following technologies associated with Generative AI.
In our recent release in May, we enhanced our turnkey integration with OPA Gatekeeper. In this blog, I describe why we worked on this enhancement.
Many of our customers that operate mission critical applications on Kubernetes clusters have to comply with organizational policies and best practices. These customers depend on and use Rafay's turnkey integration with OPA Gatekeeper in the Rafay Kubernetes Operations platform.
Prior to this release, our customers would use Rafay to
Centrally orchestrate and enforce OPA Gatekeeper policies, and
Centrally aggregate OPA Gatekeeper violations in the audit logging system
They would then use Rafay's audit log aggregator to push the OPA violations in real time to their corporate SIEM such as Splunk etc.
Since most "Infrastructure and Operations" personnel and "App Developers" are not provided access to the corporate SIEM, they have been asking Rafay to develop dashboards that will help them answer some critical questions related to compliance with policies.
What is my current posture (i.e. summary) and how has my posture evolved over time? (i.e. trend)?
This blog is a brief description of one of the enhancements from our recent release in May 2023. This feature was a frequently requested enhancement by our customers and it provides them with fine grained configuration for email notifications at a project level.
The Rafay platform acts as a single pane of glass providing a centralized view of all clusters and applications spanning the organization. Customers have had the option for over two years to leverage the Visibility & Monitoring service for centralized monitoring, alerting and notifications. This is a turnkey integration available for customers when they enable the visibility & monitoring managed add-on in their cluster blueprint.
The Visibility & Monitoring service can be leveraged to automatically generate and aggregate Alerts centrally for developers and operations personnel in their Orgs. In addition to centrally aggregated alerts, users have always had the option to optionally enable the platform to proactively send email notification when alerts are generated. To do this, administrators would specify email addresses for recipients that need to receive email notifications proactively everytime something needs immediate attention. Read on more about the enhancement below.
flowchart LR
subgraph c1[Cluster]
direction TB
bp1[Cluster <br>Blueprint] -->
vis1[Visibility & <br>Monitoring <br> Managed Add-on]
end
subgraph c2[Cluster]
direction TB
bp2[Cluster <br>Blueprint] -->
vis2[Visibility & <br>Monitoring <br> Managed Add-on]
end
vis1-->rafay
vis2-->rafay
subgraph rafay[Rafay Controller]
direction TB
notifier[Visibility & Monitoring <br> Service]
proja[Project A]-->notifier
projb[Project B]-->notifier
end
rafay --> |Notification|admin[Administrators]
classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000;
classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
class c1,bp1,vis1,c2,bp2,vis2,notifier,tsdb,admin box
In our recent release in May, we added support for a number of new features and enhancements. One of these was support for new EKS cluster provisioning based on Kubernetes v1.26.
Customers have shared with us that they would like to provision new EKS clusters using new Kubernetes versions so that they do not have to plan/schedule for Kubernetes upgrades for these clusters right away. On the other hand, they want to be extremely careful with their existing clusters and plan/test in-place upgrades for these. There is no benefit in rushing this and impacting mission critical applications etc.
Based on this feedback, starting this release, we plan to introduce support for new Kubernetes versions for CSPs (i.e. EKS, AKS and GKE) in two phases. In the first phase, which will come very quickly, we will support new cluster provisioning for the new Kubernetes version. This requires us to extensively validate support for ALL supported interfaces in the platform (See details below). We will follow up with a Phase 2 which will bring support for zero touch in-place upgrades.
Important
Support for zero touch, in-place upgrades in Rafay from EKS v1.25 to v1.26 will follow in a few weeks. This requires us to add support for new preflight tests etc and perform extensive testing and validation.
In late May 2023, Microsoft announced General Availability of Azure Linux Container Host. This is based on the "CBL Mariner" OSS project maintained by Microsoft.
It is an operating system image that is optimized for running container workloads on Azure Kubernetes Service (AKS).
The OS image is maintained by Microsoft and based on Microsoft Azure Linux, an open-source Linux distribution created by Microsoft.
It is lightweight, containing only the packages needed to run container workloads.
It is hardened based on validation tests and is compatible with Azure agents.
