Case Study: Kubeflow

The Kubeflow team uses Ambassador as a central point of authentication and routing for their services. This post is based on the post on the Kubernetes blog: Dynamic Ingress in Kubernetes.

What is Kubeflow?

The Kubeflow project is focused on making deployments to machine learning workflows on Kubernetes simple, portable and scalable. The goal of the project is to provide a straightforward way to deploy best-of-breed open-source systems for ML to diverse infrastructures using Kubernetes.

The Problem

Before they started using Ambassador, they were deploying JupyterHub using the NodeJs proxy in JupyterHub, meaning all connections to the notebook are proxied through JupyterHub. In addition, the Kubeflow team was adding additional services to the project, many of which were ephemeral in nature. The need for a centralized point for routing and authentication became a growing challenge.

The Solution

With Ambassador, Kubeflow is able to use a distributed model for configuration. Each service can configure its route in Ambassador via Kubernetes annotations, instead of a central configuration file.

Now, Kubeflow is able to configure a single ingress object that directs traffic to Ambassador, then creates services with Ambassador annotations as needed to direct traffic to specific backends. Kubeflow is also able to take advantage of additional routing configuration like URL rewriting and method-based routing.

To read more about how the Kubeflow team is using Ambassador, check out this post on the Kubernetes blog.