Documentation

Welcome to Namespace-as-a-Service!

Thanks for choosing Namespace-as-a-Service (NaaS)! You've been set up with your own isolated namespace on the ISGINF operated Kubernetes clusters and a Git repo for your app. From here on, deploying is simple: you commit Kubernetes manifests to your repo, and ArgoCD automatically syncs them into your namespace. Your Git repo is the single source of truth - no servers to babysit, no manual kubectl apply.

What you received

  • An app repo - your GitOps repo, pre-seeded with some base files. It has a a prod/ folder for your manifests (and potentially dev/ and/or test/ folders as well for the other environments). The repo URL is: https://gitlab.inf.ethz.ch/k8s/<customer>/<app>
  • An isolated namespace - your own sealed space on the cluster. It's yours to fill, and it can't be reached from or reach into anything outside itself. The namespace is: <customer>-<app>
  • Deploy access - login access on the relevant clusters, ArgoCD and maintainer access to the repository for, all controlled by the LDAP group: k8s-<customer>-<app>

How it works

You never deploy by hand. Instead:

        you edit + push                 ArgoCD detects + syncs
   your laptop ─────────────▶ your Git repo ─────────────▶ your namespace
   (kubectl / git)            (source of truth)            (running app)
  1. You edit Kubernetes manifests in your repo and git push.
  2. ArgoCD notices the change and applies it into your namespace - and only your namespace.
  3. If you change something by hand in the cluster, ArgoCD restores it to match Git. Git always wins, so your repo is always an accurate picture of what's running.

The split of responsibility follows one simple rule:

  • You own everything inside your namespace that defines your app - commit it to your repo and ArgoCD syncs it. No tickets, no waiting.
  • The platform owns the namespace boundary and everything cluster-wide - you request these by opening a ticket.

The full breakdown is in the documentation.

Your path

And keep this handy as you build:

  • isg-example - a generic app with fully commented manifests, made for isg-* apps. Copy from here.

Need help, or something only the platform can set up?

Anything platform-managed (quota changes, network exceptions, new resource kinds, deploy-group changes, LoadBalancer IPs, …) is a quick request. Open a ticket at support@inf.ethz.ch and include:

  1. Cluster - e.g. k8s-isg-dev, the one this page runs on (see cluster login).
  2. Namespace / app - your namespace name (it matches your app).
  3. What you need - e.g. "raise memory quota to X", "allow egress to example.com:443", "add user xyz to our deploy group", "a LoadBalancer IP for service foo".
  4. Why - one line; exceptions to isolation or hardening are reviewed before they're granted.