Skip to main content
Latitude.sh delivers and operates a managed Kubernetes Cluster: a highly available Control Plane, Node Pools of bare metal Nodes, core networking, and LoadBalancer IPs announced over BGP. Once you have your kubeconfig, day-2 operations (Workloads, upgrades, observability, backups) are yours. This page details what each side owns.

​
At a glance

Latitude.sh handles

The managed Control Plane, bare metal provisioning, Node images, Cilium networking, and LoadBalancer IP allocation and BGP announcement.

You handle

Workloads, Node Pool configuration, Kubernetes version upgrades, ingress and gateways, storage, monitoring, backups, and network policies.

​
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

Latitude.sh runs the physical layer and the managed Control Plane.
  • Hardware: if a Node fails due to a hardware fault, Latitude.sh handles the physical remediation.
  • Control Plane: the API server and etcd run as a managed, highly available service. You don’t size, access, or patch Control Plane Nodes.
You define each Node Pool’s plan, size, Labels, and Taints; Latitude.sh provisions the bare metal and joins it to the Cluster.
  • Images: Node operating system images are Latitude.sh’s. New images reach your Nodes when you upgrade or scale a Node Pool, or add a new one.
  • Capacity: you decide how many Node Pools to run and how large each is.
You are the Cluster operator.
  • Workloads and add-ons: ingress controllers, storage drivers, and other add-ons are yours to install and maintain.
  • Upgrades: you choose when to upgrade the Control Plane and each Node Pool.
  • Observability: Latitude.sh won’t alert you if your Pods are in CrashLoopBackOff. Run your own monitoring to catch Workload-level failures.

​
LoadBalancer and BGP boundary

When you create a Service of type LoadBalancer with spec.loadBalancerClass: latitude.sh/elastic-ip, Latitude.sh allocates a Latitude Elastic IP and announces it over BGP from your Cluster’s Nodes. What Latitude.sh provides The address is allocated and reachable. BGP announces it from the Cluster, and the network fabric routes traffic to your Nodes. What you own
  • Creating the LoadBalancer Service and any Ingress or Gateway controller behind it.
  • Application-level behavior. If the IP is reachable at L4 but your app returns 404, 502, or connection refused, the cause is on your side: Service selectors, endpoints, ingress rules, or Pod readiness.
See Exposing Workloads and LoadBalancer Services.