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, LoadBalancer IPs announced over BGP, and persistent volumes on Latitude Block Storage and File Storage. 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, LoadBalancer IP allocation and BGP announcement, and provisioning and attaching persistent volumes.

You handle

Workloads, Node Pool configuration, Kubernetes version upgrades, ingress and gateways, the data on your volumes, 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 and other add-ons are yours to install and maintain. Latitude Block Storage and File Storage volumes are built in; other storage drivers are yours.
  • 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.

​
Persistent storage boundary

When a Pod uses a PersistentVolumeClaim, Latitude.sh creates a Latitude Block Storage volume, attaches it to the Pod’s Node, moves it when the Pod moves, and grows it when you grow the claim. For a claim on latitude-file, Latitude.sh creates a Latitude File Storage filesystem, mounts it on every Node that runs one of its Pods, and grows it when you grow the claim. What Latitude.sh provides The volume is created, attached, mounted, moved and expanded for you, and deleted or kept according to the claim’s StorageClass. What you own
  • The data on your volumes and its backups. Volume snapshots aren’t available yet.
  • Choosing a reclaim policy, and deleting volumes you keep after their claim or Cluster is gone. Kept volumes continue to bill.
  • Access within your project. Volumes and filesystems are reachable only from your project’s storage network, and any Pod in the Cluster can reach that network. Any server on it can mount any filesystem in the project. Treat the project as the security boundary for your volumes.
See Persistent storage, Persistent volumes and File volumes.