Skip to main content
Latitude.sh delivers a running Kubernetes cluster on dedicated bare metal, including the control plane, worker nodes, network fabric, and a LoadBalancer IP announced over BGP. Once you receive your kubeconfig, day-2 operations (workloads, upgrades, observability, backups) are yours. This page details what each side owns.

​
At a glance

Latitude.sh handles

Bare metal, control plane availability, worker node provisioning, kubeconfig delivery, LoadBalancer IP allocation, and BGP advertisement.

You handle

Workloads, Kubernetes version upgrades, ingress, storage classes, monitoring, backups, network policies, and node OS patching.

​
RACI matrix

The matrix uses standard RACI definitions:
  • Responsible (R): performs the work.
  • Accountable (A): owns the outcome.
  • Consulted (C): opinion is sought (two-way).
  • Informed (I): kept up to date (one-way).

​
Where the boundaries are

As a bare metal provider, Latitude.sh handles the physical lifecycle.
  • Hardware replacement: if a node goes offline due to a hardware fault, Latitude.sh is responsible for the physical remediation.
  • Network fabric: Latitude.sh owns the leaf-spine architecture and the handover to your LoadBalancer IP.
Latitude.sh delivers the running cluster. Once you receive the kubeconfig, accountability for what happens inside the API server shifts to you.
  • Bootstrap and availability: Latitude.sh keeps the control plane up.
  • What runs on it: RBAC, CRDs, controllers, and operators are yours to manage.
You are the cluster operator.
  • Maintenance: coordinate node drains and cordons during maintenance windows.
  • Add-ons: if you need a specific StorageClass for persistent volumes or an ingress controller for HTTP routing, installation and troubleshooting are yours. The core networking stack (CNI, kube-proxy, CoreDNS, MetalLB) ships as an opinionated RKE2 setup and is not customer-replaceable.
  • Observability: Latitude.sh will not alert you if your pods are in CrashLoopBackOff. Own the monitoring stack (Prometheus, Alertmanager, etc.) to catch workload-level failures.

​
LoadBalancer and BGP boundary

Latitude.sh allocates a /32 LoadBalancer IP at cluster creation and advertises it over BGP from the underlying network fabric, terminating at MetalLB inside the cluster. What Latitude.sh guarantees The IP is reachable. BGP advertises it from the cluster nodes; the network fabric routes traffic to those nodes. What you own
  • Creating a Kubernetes Service of type: LoadBalancer (which claims the IP through MetalLB).
  • Any ingress controller (Nginx, Traefik, HAProxy) sitting behind it.
  • Application-level troubleshooting. If the IP is reachable at L3/L4 but the application returns 404, 502, or connection refused, the cause is on the customer side: Service selectors, Endpoints, Ingress rules, Pod readiness, etc.