Best Practices - Rafay Product Documentation

Understanding ArgoCD Reconciliation: How It Works, Why It Matters, and Best Practices

ArgoCD is a powerful GitOps controller for Kubernetes, enabling declarative configuration and automated synchronization of workloads. One of its core functions is reconciliation, a continuous process by which ArgoCD ensures that the live state of a Kubernetes cluster matches the desired state defined in a Git repository.

While this might sound straightforward, reconciliation plays a critical role in the GitOps lifecycle, and its default behavior can be surprisingly aggressive. In this blog post, we’ll explore:

• What reconciliation in ArgoCD actually does
• Why it exists and how it ensures cluster integrity
• The pitfalls of the default timer
• Best practices for tuning reconciliation to balance responsiveness and resource efficiency

In a related blog, we describe how customers using Rafay are able to Block Drift in the first place.

Simplifying Blueprint and Add-on Management with Draft Versions

Managing infrastructure at scale demands both agility and precision—especially when it comes to version control. At Rafay, we have long supported versioning for key configuration objects such as Blueprints and Add-ons, enabling platform teams to roll out changes systematically and maintain operational consistency.

However, as many teams have discovered, managing these versions during testing and validation phases can introduce unnecessary complexity. We are excited to announce a major usability enhancement: Support for Draft Versions.

Why Versioning Matters

Versioning in Rafay’s platform delivers several key advantages:

• Change Tracking: Keep a historical record of changes made to Blueprints and Add-ons over time
• Staged Rollouts: Gradually deploy updates across environments and clusters to minimize risk
• Compliance Assurance: Demonstrate adherence to organizational policies and track Day-2 changes in a controlled way

These capabilities are especially crucial for teams responsible for maintaining secure, production-grade Kubernetes environments.

The Challenge: Version Sprawl During Testing

While versioning is powerful, it has traditionally introduced friction during the testing and validation phase. Each time a platform engineer made a minor change to an Add-on or Blueprint, a new version needed to be created—even if the version wasn’t production-ready.

This led to:

• Version fatigue, with large volumes of partially validated versions cluttering the system
• Increased manual overhead and inefficiency for platform teams
• Risk of accidental usage of incomplete configurations in downstream projects

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.

Using Lens Desktop with Rafay's Zero Trust Kubectl Access - YouTube

Using Lens Desktop with Rafay's Zero Trust Kubectl Access

Multi-tenancy: Best practices for shared Kubernetes clusters

Some of the key questions that platform teams have to think about very early on in their K8s journey are:

• How many clusters should I have? What is the right number for my organization?
• Should I set up dedicated or shared clusters for my application teams?
• What are the governance controls that need to be in place?

The model that customers are increasingly adopting is to standardize on shared clusters as the default and create a dedicated cluster only when certain considerations are met.

Request for compute from Application teams

Evaluate against list of considerations

Dedicated or shared clusters

A few example scenarios for which Platform teams often end up setting up dedicated clusters are:

• Application has low latency requirements (target SLA/SLO is significantly different from others)
• Application has specific requirements that are unique to it (e.g. GPU worker nodes, CNI plugin)
• Based on Type of environment - ‘Prod’ has dedicated clusters and 'Dev', 'Test' environments have shared clusters

With shared clusters (which is the most cost efficient and therefore the default model in most customer environments), there are certain challenges that platform teams have to solve for around security and operational efficiencies.