Skip to content
Kestrel Docs

What is Kestrel?

Kestrel is a multi-tenant Kubernetes service running on the Arbutus cloud at UVic. Arbutus is one of the Digital Research Alliance of Canada’s national cloud sites; UVic Research Computing Services (RCS) operates it. Kestrel layers a multi-tenant Kubernetes cluster on top of Arbutus so researchers with an Alliance Cloud RAP can run container workloads with persistent storage, inbound HTTPS, and shared compute without provisioning their own virtual machines.

Access is organized around tenants: each Alliance Cloud RAP maps to one Capsule Tenant on Kestrel, 1:1. The tenant name matches the Cloud RAP’s POSIX group name. Every user inside a tenant authenticates with their Alliance CCDB identity — there is no separate Kestrel account system.

Who it is for

Section titled “Who it is for”

Alliance-federated researchers across Canada who already know their way around container workloads. “Alliance-federated” is specific: you have an Alliance CCDB account, and your PI (any faculty at a CFI-eligible Canadian institution) holds a Cloud RAP on Arbutus. UVic affiliation is not required — researchers at any Canadian institution with a CCDB account and a Cloud RAP can use Kestrel.

“Already know their way around container workloads” is also specific: you know what a Kubernetes Pod is, you have used kubectl before, and you understand that YAML is the configuration language. Kestrel documentation assumes this baseline and does not teach it.

If you do not have the Kubernetes baseline, the tutorials section has brush-up material on containers, the core Kubernetes objects, kubectl, and YAML. Come back here after.

If you do not yet have a CCDB account or a Cloud RAP, start with Requesting access — it walks the CCDB registration and the PI-adds-you-to-the-RAP flow.

What is included

Section titled “What is included”
  • Multi-tenant Kubernetes with Capsule — Tenants, the namespace prefix rule, shared resource pools, and NetworkPolicy isolation. See Tenancy model and Network model for the mechanics.
  • Persistent storage via OpenStack Cinder CSI — two block storage classes supporting ReadWriteOnce only. ReadWriteMany (shared) volumes are not offered through a storage class; open a ticket with RCS to have a per-tenant NFS volume provisioned. See Storage classes.
  • Inbound HTTPS via Traefik plus cert-manager, with Let’s Encrypt production certificates for tenant Ingresses.
  • GitOps deployment via ArgoCD — a user-brings-repo pattern: you point ArgoCD at your own Git repo and it reconciles your manifests. See Your first deployment.
  • OIDC authentication via Keycloak, federating Alliance LDAP. See Identity chain for the full 6-layer chain from CCDB to RBAC.
  • Cluster monitoring via Grafana, with tenant-scoped dashboards for your own Namespaces.

What is not included

Section titled “What is not included”
  • GPU workloads. Not available in v1 — hardware is pending. See Known limitations.
  • A self-serve provisioning portal. The current access path is through CCDB and a PI’s Cloud RAP (see Requesting access). A portal is planned but not yet available — see Self-serve portal.
  • Alliance HPC workloads. Kestrel is a Kubernetes service for cloud-style workloads backed by a Cloud RAP. Alliance HPC scheduler submission (Cedar, Graham, Narval, etc.) is a different family of services backed by HPC RAPs (rrg-*, rpp-*), not Cloud RAPs — Kestrel does not cover those workloads.
  • A general-purpose hosting service. Kestrel is for research computing workloads on an Alliance allocation. It is not the right home for static marketing sites, commercial web applications, or workloads that could run equally well on a laptop.
  • Kubernetes training. The docs assume the working-knowledge baseline described above. tutorials has brush-up material; Kestrel’s own pages do not re-teach Kubernetes.

Where to go next

Section titled “Where to go next”