Introducing the OSRM Operator: Painless Routing on Kubernetes

[itayankri]

Hi everyone! 👋

I’m excited to share a project I’ve been working on that simplifies one of the trickier parts of geospatial tech stacks: hosting the Open Source Routing Machine (OSRM) on Kubernetes.

If you’ve ever managed OSRM in production, you know the drill. It’s an incredible high-performance routing engine, but it’s also a beast to manage. You have to download massive .pbf map files, extract the graph (which eats up CPU and RAM), and then figure out how to distribute that pre-processed data to your serving nodes. Doing this manually is prone to errors, and automating it with cron jobs or bare pods often leads to downtime during map updates.

That’s why I built the OSRM-Operator.

What is it?
The OSRM Operator is a Kubernetes native operator built with the Operator SDK. It introduces a custom resource—the OSRMCluster—that turns your routing infrastructure into code.

Instead of writing complex StatefulSets and maintenance scripts, you define your cluster like this:

apiVersion: osrm.itayankri.io/v1alpha1
kind: OSRMCluster
metadata:
  name: osrm-marshall-islands
spec:
  profiles:
    - name: car
      replica: 3
    - name: bicycle
      replica: 2
  source:
    url: "https://download.geofabrik.de/australia-oceania/marshall-islands-210101.osm.pbf"

Key Features
I designed this operator to solve specific pain points I encountered while scaling OSRM. Here are the highlights:

1. Efficient Map Data Sharing 💾
   One of the biggest costs in running OSRM is memory and storage. A pre-processed planet file is huge. The operator efficiently deploys OSRM instances by sharing map data across all pods of a specific instance. This means you aren't duplicating gigabytes of graph data for every replica you spin up.

2. Blue/Green Map Updates 🟢 🔵
   Updating maps in a live routing system is terrifying. If you overwrite the file while the engine is reading it, you crash. If you take the service down to update, you lose traffic.

The OSRM Operator handles Blue/Green deployments for map updates automatically. When you change the map source or trigger an update, it spins up a new set of pods with the new map data, waits for them to be ready, and only then switches traffic over. Zero downtime, zero stress.

3. Multi-Profile Support 🚗 🚲 🚶
   Need routing for cars, bikes, and pedestrians? You can define multiple profiles within a single cluster configuration. The operator handles the independent scaling and lifecycle management for each profile type.

It’s super easy to try out. You can install the operator directly into your cluster with a single command:

kubectl apply -f https://github.com/itayankri/OSRM-Operator/releases/latest/download/osrm-cluster-operator.yaml

Once that's running, you can apply your first cluster config.

This is an open-source project, and I’d love your feedback.

Try it out: Deploy it in your dev environment.

Contribute: Found a bug? Have a feature request? Open an issue or submit a PR!

Happy routing! 🗺️