Skip to content

Kubernetes

Sunet offers Kubernetes as a service to all customers. Kubernetes is an open-source container orchestration system for deploying, scaling, and managing containerized applications across a cluster of machines.

Introduction

Sunet's Kubernetes service is designed to be accessible to researchers across all experience levels with containerization. It follows industry-standard GitOps principles using ArgoCD, letting you manage applications and infrastructure declaratively through Git repositories.

Ordering

Order the service via the Sunet website. When ordering, specify:

  • Initial cluster size (small, medium, large, XL)
  • Initial users
  • Whether ArgoCD should run on a sunet.se subdomain or your own custom domain
  • Any optional add-ons you want to include (block storage, object storage, backup and disaster recovery, DNS management API)

If you choose a custom domain, you'll need to set up a CNAME record pointing to the cluster's ingress controller. We'll then provision the cluster with Gateway API, ArgoCD, and cert-manager, and deliver credentials to your team.

What's Always Included

  • A managed Kubernetes cluster sized to your specification
  • ArgoCD for GitOps-based application and infrastructure management
  • Gateway API for ingress traffic
  • cert-manager for TLS certificates
  • External load balancing, with routing handled by the Gateway API
  • A DNS name (sunet.se subdomain or your custom domain)
  • Regular maintenance and updates to the underlying infrastructure

Optional Add-ons

Optional services are billed in addition to the base cluster cost.

  • Block storage as persistent volumes - billed at standard block storage rates.
  • S3-compatible object storage - billed at standard object storage rates.
  • Backup and disaster recovery via Velero, with regular backup schedules. Storage is billed at standard object storage rates based on backup volume and retention. We'll work with you to determine the right backup strategy for your applications.
  • DNS management API for automating DNS record creation and updates. This is currently free of charge, but we reserve the right to introduce pricing if demand grows significantly.

Getting Started

Once your order is complete, you'll receive a kubeconfig file with everything needed to connect: API server endpoint, authentication credentials, and configuration details. Use it with kubectl or any other Kubernetes tooling.

Your account is scoped via RBAC to the argocd namespace, where you manage applications and resources through ArgoCD. Other namespaces and cluster-wide resources remain isolated for security.

Credentials are delivered via PGP-encrypted email to all users specified in the order, unless otherwise agreed. Make sure your team has kubectl and a PGP client ready before delivery.

GitOps with ArgoCD

To use GitOps you'll need a Git repository - GitHub, GitLab, Codeberg, or any other host - containing YAML files that describe your cluster's desired state. ArgoCD continuously monitors the repository and applies changes automatically, keeping the cluster in sync.

You can configure ArgoCD to:

  • Watch specific branches or directories - useful for managing multiple applications or environments from a single repository.
  • Require signed commits before applying changes, adding an extra layer of authorization.

Namespaces

Although your kubectl access is scoped to the argocd namespace, ArgoCD itself runs with the permissions needed to create and manage resources elsewhere in the cluster. To deploy into another namespace, commit an Application (or ApplicationSet) manifest to your Git repository that targets the destination namespace; ArgoCD will create the namespace if it doesn't already exist (using syncOptions: CreateNamespace=true) and deploy your resources into it.

High Availability and Scalability

Design your applications to take advantage of Kubernetes' availability and scaling features: Deployments, StatefulSets, multiple replicas, and Horizontal Pod Autoscaling. Keep applications stateless and use external storage for persistent data so they can scale and recover gracefully. The Twelve-Factor App methodology is a solid starting point.

Sunet handles maintenance and rolling updates of the underlying infrastructure without prior notice. We never perform updates that bring down the entire cluster, but individual nodes may briefly restart during the process - your applications need to handle this.

Pod Disruption Budgets and the rolling-restart contract

Kubernetes lets you protect workloads from voluntary disruption with a PodDisruptionBudget (PDB). PDBs are useful, but the platform reserves the right to drain any node at any time for maintenance - and drain must be able to succeed. A PDB that can never let a pod be evicted will block the entire cluster's maintenance schedule.

Not allowed - these PDBs cannot tolerate eviction and will be treated as a configuration error during maintenance windows:

# A single-replica Deployment + minAvailable: 1.
# Eviction is never allowed; drain fails forever.
apiVersion: apps/v1
kind: Deployment
metadata: {name: my-app}
spec:
  replicas: 1
  ...
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: {name: my-app}
spec:
  minAvailable: 1
  selector: {matchLabels: {app: my-app}}

# maxUnavailable: 0 - never allow any pod to go down.
spec:
  maxUnavailable: 0

Recommended patterns:

# Multi-replica + relative budget - drain can take one pod at a time.
spec:
  replicas: 3
---
spec:
  maxUnavailable: 1   # or minAvailable: 2

# Single-replica workload that genuinely cannot be HA (legacy app etc.):
# omit the PDB entirely. The pod will be restarted on another node
# during drain; expect a brief outage. Use a readiness probe so
# traffic stops before the pod is killed.

If you operate a stateful workload that requires multiple replicas to remain available (a database with quorum, for example), set the PDB to maxUnavailable: 1 against an N≥3 StatefulSet. That tolerates drain and protects the quorum.

Summary: every workload on the platform must be drain-tolerant. Either run multiple replicas with a PDB that allows at least one disruption, or accept eviction on a single replica with no PDB. PDBs that block all eviction are not supported.

Secrets Management

We recommend Sealed Secrets for managing sensitive data. It encrypts secrets so they can be safely committed to a Git repository - only your cluster can decrypt them.

Load Balancing and Gateway API

External traffic is handled by an external load balancer, with the Gateway API routing requests to services inside the cluster based on hostname or path. In practice, your external services use a CNAME record pointing to the load balancer.

Your cluster gets a DNS name as a sunet.se subdomain, or you can use a custom domain (just point a CNAME record at the load balancer).

We can also provide a DNS management API to automate record creation and updates - particularly useful for large deployments or frequent DNS changes. To use this with a custom domain, delegate the zone to Sunet by updating your domain's NS records to point to our nameservers.

Backup and Disaster Recovery

Backup and disaster recovery is an optional service. If you don't order it, you're responsible for backing up your own applications and data - for example with Velero for Kubernetes resources and persistent volumes. Establish backup schedules and test recovery procedures regularly.

If you use Sunet's S3-compatible object storage or block storage for application data, note that these services are not backed up by default. Plan your own backup strategy accordingly.