CIRRUS Architecture
A look at the different components used to build CIRRUS and how they can be used to grow the reach of your science.
Basic CIRRUS Architecture
Understanding the CIRRUS Platform
CIRRUS is a cloud-native Kubernetes platform. This means workloads designed to run on CIRRUS can run on any Kubernetes cluster, whether on-premises, in the cloud (AWS, GCP, Azure), or on other infrastructure. The platform uses industry-standard tools and practices, ensuring your work is portable and not locked into a specific environment.
How CIRRUS Relates to HPC
CIRRUS is not a replacement for NCAR's HPC systems, it is a complement to them. HPC clusters and their batch schedulers are built for large, finite compute jobs such as model runs and simulations that start, run, and finish. CIRRUS is built for long-running, always-on workloads such as websites, dashboards, APIs, and interactive services that need to stay available around the clock.
Many research groups use both. You might run a simulation on HPC and then use CIRRUS to host a dashboard or API that serves the results to collaborators or the public. Because CIRRUS can mount NCAR storage and data, the work you do on HPC and the workloads you run on CIRRUS can share the same underlying datasets.
What is a Container?
A container is a way to package your application with all the dependencies it needs to run, without including anything extra. It provides only what you need and makes reproducibility easy. Your application runs the same way everywhere, whether on your laptop, a colleague's machine, or in production.
Storing Images in a Container Registry
Once you have a working container image, you store it in a container registry. CIRRUS provides Harbor as a private registry, and you can also use public registries like GHCR (GitHub Container Registry) or Docker Hub.
What is Kubernetes?
Kubernetes is a container orchestration platform that manages containerized workloads at scale. It handles deploying, scaling, and operating containers across clusters of hosts.
Defining Your Workloads with Helm Charts
Once your image is in a registry, it can be referenced in a Helm chart, a package that defines how your workload deploys on Kubernetes, including configuration, resources, and dependencies. Helm charts can be used to deploy resources on any Kubernetes cluster.
Continuous Delivery via Argo CD
Argo CD continuously monitors your Helm charts in Git repositories. When changes are detected, it automatically syncs and deploys your workload to the Kubernetes cluster, implementing true GitOps practices.
Automation with GitHub Actions
GitHub Actions workflows automate your deployment pipeline. When you push code changes, workflows automatically build a new container image, push it to your container registry, update your Helm chart values to reference the new image, and trigger Argo CD to deploy the updated workload.
With CIRRUS, you can connect a GitHub Actions Runner Scale Set to your repository. This provides access to more computational resources including GPUs, allowing your CI/CD workflows to run directly on the Kubernetes cluster with the hardware your builds and tests require.
Accessing Your Application: Ingress and TLS
CIRRUS provides two ingress paths: LoxiLB for external traffic using BGP peering to provide publicly accessible endpoints, and NGINX Ingress for internal traffic within the UCAR network.
ExternalDNS automatically creates DNS records in the *.k8s.ucar.edu domain for your services, while cert-manager issues and manages TLS certificates from Let's Encrypt to provide HTTPS endpoints for your web applications.
Mounting NCAR Storage and Data
Your workloads do not have to start from scratch. CIRRUS can mount NCAR storage systems and data directly into your containers, giving your applications access to existing datasets and shared storage without copying data into the cluster. This lets you bring compute to the data your research already depends on.
Security: Secrets Management
OpenBao works with the External Secrets Operator to securely store sensitive data like API keys, passwords, and credentials. Secrets are encrypted at rest in OpenBao and securely injected into your containers with encryption in transit, ensuring sensitive information never lives in your Git repository or Helm charts.
Databases: CloudNativePG
If your application needs a database, CIRRUS offers CloudNativePG, a Kubernetes operator that deploys and manages highly available PostgreSQL clusters with automated backups, failover, and scaling.
Observability: Monitoring and Logging
CIRRUS provides access to Grafana, which integrates with Prometheus (for metrics) and Loki (for logs) to gather telemetry from your applications. You can create custom dashboards to analyze and monitor application performance, set up alerts, and troubleshoot issues.