Learn GitOps with ArgoCD - Multi-Tenancy at Scale

#Introduction

In episode 27 we learned to solve problems — and most of those problems grow from a single root: too many things sharing one space without boundaries. When five teams use one ArgoCD, one cluster, and one set of namespaces without clear separation, it's not a matter of whether conflicts will appear, but when. In this episode we discuss multi-tenancy at scale — how to run one ArgoCD (or several) for many tenants with firm boundaries.

Why does this matter? Multi-tenancy is the point where GitOps turns from "how our team deploys" into "the company platform". This is where the platform team's job is to make self-service safe: tenants get speed without the platform losing control. This episode explains tenancy models, isolation strategies, self-service patterns, and how to manage resources and costs fairly.

#Tenancy Models

There are three main models, and the choice between them determines the entire subsequent design:

In the namespace-based model, one ArgoCD manages all tenants. Isolation is done through a combination of Projects (episode 10), ResourceQuota, and per-namespace NetworkPolicy. This is the most cost-effective model — but demands high discipline. In the cluster-based model, each tenant gets its own cluster (possibly provisioned by a hub ArgoCD); expensive but with undeniable isolation. Hybrid is the pragmatic answer: small tenants share a development cluster, while each tenant's (or environment's) production gets its own cluster.

#Isolation Strategies

Isolation isn't one layer, but four complementary layers.

#Network Policies

Control traffic between namespaces with a default-deny:

Default deny between tenants

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: tenant-billing
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Every tenant must allow inbound and outbound traffic explicitly. A NetworkPolicy ensures tenant A's applications can't become a path into tenant B even when the cluster is compromised.

#Resource Quotas

Quotas and LimitRanges prevent one tenant from consuming the whole cluster:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-billing-quota
  namespace: tenant-billing
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    count/deployments.apps: "20"

Without quotas, one misconfigured application could starve every other tenant of resources. Quotas also become the basis for cost calculations (see Resource Management below).

#RBAC Boundaries

Two RBAC layers work together: Kubernetes RBAC (who may touch what in the cluster) and ArgoCD RBAC (who may sync/view which applications). In ArgoCD, this is controlled through Projects:

Project with source and destination boundaries

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: tenant-billing
  namespace: argocd
spec:
  sourceRepos:
    - https://github.com/org/tenant-billing/*
  destinations:
    - namespace: tenant-billing
      server: https://kubernetes.default.svc
  roles:
    - name: developer
      policies:
        - p, proj:tenant-billing:developer, applications, get, tenant-billing/*, allow
        - p, proj:tenant-billing:developer, applications, sync, tenant-billing/*, allow

#Project Separation

A Project is ArgoCD's multi-tenancy logical unit. One project per tenant — not one project with many multi-tenant applications. A Project determines which source repos are allowed, which destination clusters are allowed, and which Kubernetes resources may be created.

#Self-Service Patterns

Good tenancy doesn't require the platform team to do everything manually. Self-service is the key to scale.

#Automated Onboarding

When a new tenant joins, the platform team performs one step: committing a single file to the onboarding repo. An ApplicationSet with a Git generator detects the new directory and provisions all the tenant's needs — namespace, quota, network policy, role, and Application:

ApplicationSet for tenant provisioning

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: tenant-onboarding
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://github.com/org/tenant-registry
        revision: main
        directories:
          - path: tenants/*
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      project: '{{path.basename}}'
      source:
        repoURL: https://github.com/org/tenant-registry
        path: '{{path}}/manifests'
      destination:
        namespace: '{{path.basename}}'
        server: https://kubernetes.default.svc

#Template Repositories

Each tenant isn't an empty starting point, but a descendant of a template. The template repo contains the platform standards: labels, security context, liveness probes, minimum resource requests. Differences between tenants are only the values overridden via a Kustomize overlay or Helm values — not a full duplicate that drifts.

#Governance Policies

Self-service without governance is anarchy. A policy engine like Kyverno (episode 30) validates every incoming manifest: rejects latest images, enforces a non-root securityContext, ensures resource requests always exist. Because ArgoCD applies from Git, these policies also apply to every sync — one automatic gate for all tenants.

#Resource Management

In a multi-tenant environment, resources are money — and a platform team that can't answer "who's spending how much" will struggle at budget review.

#Fair Allocation

Per-tenant quotas (above) set the allocation agreement. For fair allocation, combine: a fixed per-tenant quota for the baseline, plus a shared pool that can be temporarily drawn for spikes (with approval).

#Cost Allocation, Chargeback, Showback

• Cost allocation — label resources (episode 33): team=billing, environment=prod, tenant=.... The cloud provider uses these labels to map costs per tenant.
• Chargeback — tenants are actually billed for usage; applies in organizations where tenants are business units.
• Showback — tenants are not billed but see their usage reports; easier to accept and already enough to change behavior.

#Usage Monitoring

Monitor per-namespace usage with metrics:

kubectl get resourcequota -A
kubectl describe resourcequota tenant-billing-quota -n tenant-billing
kubectl top pods -n tenant-billing

kubectl top shows actual usage vs requests — important data for finding over-requesting tenants (asking for 8 vCPUs but using 0.5) and under-provisioned tenants.

#Closing

This episode mapped multi-tenancy in ArgoCD completely: the namespace-based, cluster-based, and hybrid models, four isolation layers (network policy, quota, RBAC, project separation), self-service patterns with automated onboarding, ApplicationSet provisioning, template repos, and governance policies, and resource management with fair allocation, cost allocation, chargeback/showback, and usage monitoring.

The points you should take with you:

• The tenancy model determines the whole design; start with namespace-based.
• Effective isolation is four layers, not one.
• The ArgoCD Project is the primary boundary: sources, destinations, and allowed resources.
• ApplicationSet turns tenant onboarding into a single commit.
• Disciplined labels from the start make cost allocation possible.

Good tenancy manages applications; the next step is managing what's below applications. In the next episode 29 we discuss infrastructure GitOps — Terraform with GitOps, Crossplane for native Kubernetes IaC, Cluster API for cluster lifecycle, and full-stack GitOps patterns. See you in episode 29!