> ## Documentation Index
> Fetch the complete documentation index at: https://www.latitude.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Shared responsibility

> How responsibilities split between Latitude.sh and you across the LKS Cluster lifecycle

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

<CardGroup cols={2}>
  <Card title="Latitude.sh handles">
    The managed Control Plane, bare metal provisioning, Node images, Cilium networking, and LoadBalancer IP allocation and BGP announcement.
  </Card>

  <Card title="You handle">
    Workloads, Node Pool configuration, Kubernetes version upgrades, ingress and gateways, storage, monitoring, backups, and network policies.
  </Card>
</CardGroup>

## 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).

| Task / deliverable | Latitude.sh | Customer | Notes |
| - | - | - | - |
| Bare metal provisioning (rack, power, network) | A/R | I | Physical hardware health and connectivity. |
| Managed Control Plane (API server, etcd) | A/R | I | Availability and health of the Control Plane. |
| Control Plane version upgrades | R | A | You choose when to upgrade; Latitude.sh performs it. |
| Core networking (Cilium CNI) | A/R | I | Opinionated, managed stack, not customer-replaceable. |
| LoadBalancer IP allocation and BGP announcement | A/R | I | An Elastic IP per LoadBalancer Service, announced over BGP. |
| Node images (operating system) | A/R | I | Provided by Latitude.sh; updated through Node Pool upgrades. |
| Node Pool configuration (plan, size, Labels, Taints) | R | A/R | You define Node Pools; Latitude.sh provisions the Nodes. |
| Node Pool scaling | R | A | You trigger scaling; Latitude.sh provisions or removes Nodes. |
| Node Pool version upgrades | R | A/R | You trigger; Nodes are recreated on the new version. |
| Workload deployment (Pods, Services) | I | A/R | All containerized applications. |
| Ingress and gateways (L7) | I | A/R | Bring your own controller behind an L4 LoadBalancer Service. |
| Persistent storage | I | A/R | Latitude CSI is coming soon. |
| Monitoring and logging | I | A/R | Prometheus, Grafana, and similar stacks. |
| Backup and disaster recovery | I | A/R | Workload and volume backups. |
| Network policies and RBAC | I | A/R | In-cluster security posture. |
| Kubeconfig delivery | A/R | I | Issued at provisioning, retrievable from the dashboard. |
| Billing and metering | A/R | I | Hourly [bare metal pricing](https://www.latitude.sh/pricing). Cluster cost is the sum of its Node Pool Nodes. |

## Where the boundaries are

<AccordionGroup>
  <Accordion title="Bare metal and Control Plane (Latitude.sh)">
    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.
  </Accordion>

  <Accordion title="Node Pools (shared)">
    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.
  </Accordion>

  <Accordion title="Day-2 operations (you)">
    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.
  </Accordion>
</AccordionGroup>

## 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](/docs/lks/exposing-workloads) and [LoadBalancer Services](/docs/lks/load-balancer-services).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.