## Upstream Kubernetes on RHEL 10 using Rafay

Our [upcoming release](https://docs.rafay.co/releasenotes/preview/upcoming/) update will add support for a number of new features and enhancements. This blog is focused on the upcoming support for Upstream Kubernetes on nodes based on [Red Hat Enterprise Linux (RHEL) v10.0](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/index). Both new cluster provisioning and in-place upgrades of Kubernetes clusters will be supported for lifecycle management.

## Support for Parallel Execution with Rafay's Integrated GitOps Pipeline

At Rafay, we are continuously evolving our platform to deliver powerful capabilities that streamline and accelerate the software delivery lifecycle. One such enhancement is the recent update to our **GitOps pipeline engine**, designed to optimize execution time and flexibility — enabling a better experience for platform teams and developers alike.

### Integrated Pipeline for Diverse Use Cases

Rafay provides a tightly integrated pipeline framework that supports a range of common operational use cases, including:

- **System Synchronization**: Use Git as the single source of truth to orchestrate controller configurations
- **Application Deployment**: Define and automate your app deployment process directly from version-controlled pipelines
- **Approval Workflows**: Insert **optional approval gates** to control when and how specific pipeline stages are triggered, offering an added layer of governance and compliance

This comprehensive design empowers platform teams to standardize delivery patterns while still accommodating organization-specific controls and policies.

### From Sequential to Parallel Execution with DAG Support

Historically, Rafay’s GitOps pipeline executed all stages **sequentially**, regardless of interdependencies. While effective for simpler workflows, this model imposed time constraints for more complex operations.

With our latest update, the pipeline engine now supports **Directed Acyclic Graphs (DAGs)** — allowing stages to execute **in parallel**, wherever dependencies allow.

## Important Update: Changes to Bitnami Public Catalog

Recently, Bitnami announced significant changes to its container image distribution [here](https://github.com/bitnami/charts/issues/35164). As part of this update, the **Bitnami public catalog (`docker.io/bitnami`) will be permanently deleted on September 29th**.

### What’s Changing

- All existing container images (including older or versioned tags such as `2.50.0`, `10.6`, etc.) will be moved from the public catalog (`docker.io/bitnami`) to a **Bitnami Legacy repository (`docker.io/bitnamilegacy`)**.
- The **legacy catalog will no longer receive updates or support**. It is intended **only as a temporary migration solution** to give users time to transition.

## Simplifying Day-2 Operations with Agent Pools

Implementing Day-2 Operations such as **agent replacement** is cumbersome today because every configuration tied to a previous agent must be reconfigured manually. This makes tasks like scaling, retiring agents, or handling failures both error-prone and time-consuming.

To address this pain point, we are introducing the concept of an **Agent Pool**.

### Why Agent Pools?

Instead of binding configurations directly to individual agents, customers can now attach multiple agents to a shared **Agent Pool**. Configurations such as **Environment Templates** and **Resource Templates** reference the pool, rather than a single agent.

This simple shift brings significant operational benefits:

- **Seamless Failover and Replacement**: Add or remove agents from a pool without reconfiguring existing associations.
- **Simplified Day-2 Operations**: Manage scaling, upgrades, and retirements without disruption.
- **Load Balancing**: Distribute load across multiple agents within a pool for higher availability and performance.

## NVIDIA Performance Reference Architecture: An Introduction

Artificial intelligence (AI) and high-performance computing (HPC) workloads are evolving at unprecedented speed. Enterprises today require infrastructure that can scale elastically, provide consistent performance, and ensure secure multi-tenant operation. NVIDIA’s Performance Reference Architecture (PRA), built on HGX platforms with Shared NVSwitch GPU Passthrough Virtualization, delivers precisely this capability.

This is the introductory blog in a multi part series. In this blog, we explain **why PRA is critical** for modern enterprises and service providers, highlight the benefits of adoption, and outline the key steps required to successfully deploy and support the PRA design/architecture.

## Deep Dive into `nvidia-smi`: Monitoring Your NVIDIA GPU with Real Examples

Whether you're training deep learning models, running simulations, or just curious about your GPU's performance, **`nvidia-smi`** is your go-to command-line tool. Short for **NVIDIA System Management Interface**, this utility provides essential real-time information about your NVIDIA GPU’s health, workload, and performance.

In this blog, we’ll explore what `nvidia-smi` is, how to use it, and walk through a **real output** from a system using an **NVIDIA T1000 8GB GPU**.

### What is `nvidia-smi`?

`nvidia-smi` is a CLI utility bundled with the NVIDIA driver. It enables:

- Real-time **GPU monitoring**
- **Driver and CUDA version** discovery
- Process visibility and control
- GPU configuration and performance tuning

You can execute it using:

```
nvidia-smi
```

## Enhancing Namespace Chargeback Reports with Custom Label-Based Metadata in Rafay

In the world of **FinOps**, precise cost allocation is more than just a “nice to have”, it’s the foundation for accurate chargeback, accountability, and informed decision-making. With Rafay’s latest release, **Chargeback Summary Reports** aggregated by **namespace** now support **custom label-based metadata enrichment**.

This enhancement empowers FinOps teams to add business-relevant metadata (like `team` or `cost_center`) directly into their cost reports making it easier to trace expenses to the right owners and justify resource consumption.

### Why This Matters for FinOps

In large, multi-tenant Kubernetes environments, namespaces often represent workloads owned by different teams, applications, or business units. Without enriched metadata, a FinOps practitioner might see “Namespace A” incurring costs, but need extra steps to figure out which **team** or **cost center** is responsible.

Now, you can define **specific label keys** (e.g., `team`, `cost_center`) in the **chargeback report configuration**, and Rafay will automatically include them as **additional columns** in the report—populated with values from the namespace labels. This directly embeds organizational context into your cost visibility.

## GitOps Without Borders: Running Argo CD Across Isolated Security Domains with Rafay’s Zero-Trust Kubectl

Modern enterprises rarely run applications in a single cluster. A production fleet might include on-prem clusters in Singapore and London, a regulated environment in AWS us-east-1, and a developer sandbox in someone’s laptop. **GitOps with Argo CD** is the natural way to keep all those clusters in the desired state—but the moment clusters live in different _security domains_ (fire-walled data centers, private VPCs, or even air-gapped networks) the simple `argocd cluster add` story breaks down:

- Bespoke bastion hosts or VPN tunnels for every hop
- Long-lived bearer-token Secrets stashed in Argo’s namespace
- High latency between the GitOps engine and far-flung clusters, turning reconciliations into a slog

**Rafay’s Zero-Trust Kubectl Access (ZTKA)** solves all three problems in one stroke. By front-loading the connection with a hardened **Kube API Access Proxy**—and issuing _just-in-time_ (JIT), short-lived ServiceAccounts inside every cluster.

## Turbo-charging kubectl: How Rafay’s Zero-Trust Access + Regional Proxies Deliver Lightning-Fast CLI Performance

When developers are halfway around the world from their clusters, every kubectl get pods can feel like it’s moving through molasses. Rafay’s Zero-Trust Kubectl (ZTKA) service fixes the security risks and the lag by adding a network of regional proxies between the user and the cluster.

**Zero-Trust Kubectl in a Nutshell**

Rafay ZTKA routes all CLI and web-terminal traffic through its Kube API Access Proxy. The key design goals are:

1. Friction-free for users (“vanilla kubectl”),
2. Zero infrastructure to manage for platform teams,
3. Centralized RBAC + audit, and “great performance” even for clusters behind firewalls.

## Drift Prevention vs Detection: Does a Polling Approach make sense At Scale?

Many organizations typically rely on pull-based GitOps tools (e.g. Argo CD) to detect and remediate drift on their Kubernetes clusters. This approach allows clusters to diverge before reconciling them on the next polling interval. For the last 4 years, Rafay customers have benefited from an architecturally different approach that focuses on true drift prevention, backed by robust detection capabilities across both [**cluster blueprints**](https://docs.rafay.co/blueprints/overview/) and [**application workloads**](https://docs.rafay.co/workloads/workload_types/).