Getting started

Before your first deployment, three things need to be in place: repository access, a staging environment that genuinely mirrors production, and a rehearsed way back. This page covers those three.

Prerequisites

Every example in these docs assumes the following tools are on your machine:

First login

Once your invitation lands, pull your cluster credentials through the internal CLI. The token is written to disk and expires after twelve hours.

mizban auth login --org acme
mizban cluster use production
kubectl get nodes -o wide

If the third command returns nothing, the problem is your RBAC binding, not the cluster. Ask the platform team to check your role.

Namespace layout

Each team owns exactly one namespace per environment, named <team>-<env>. Deviating from that pattern silently breaks the network policies, which select on these labels.

apiVersion: v1
kind: Namespace
metadata:
  name: payments-production
  labels:
    app.kubernetes.io/part-of: payments
    mizban.io/environment: production
    mizban.io/oncall-rotation: payments-primary

Your first deploy

Deployments always originate from the default branch and always travel through the pipeline. A manual kubectl apply against production is rejected by a Gatekeeper policy.

Breaking glass during an incident is allowed. Leaving it broken is not: whatever you did by hand must land as a merge request within twenty-four hours. Infrastructure that exists only in one person's memory is not infrastructure.

Next

"Pipeline anatomy" walks through exactly what happens between git push and traffic reaching the new revision.