Story of Our Transition to a Custom Kubernetes Operator for an API Gateway

At Ubisoft, we're building an internal platform to provide managed services - such as Kubernetes clusters, databases, ... - through a unified experience. Any team can contribute to the platform by bringing their own services, which will need to be integrated at the API Gateway level. This talk is the story of our transition from a manually managed API Gateway - configuration and rules - to a self-service one, using a custom Kubernetes Operator. We'll go through the challenges we faced with our initial setup while scaling the platform, and our reasons for writing our own operator, instead of relying on existing solutions. We'll explain our platform's conventions, and how we are using OpenAPI as a central point of entry for our APIs. And we'll detail the features we needed - and implemented - to automatically configure our API Gateway based on the OpenAPI documents provided by the different services. While doing so, we'll also relate some organizational challenges, such as switching responsibilities, as well as technical benefits from using the controller pattern: the reconciliation loop, dry-run - with server-side apply. And we'll highlight what we learned along the way. Our technical stack is based on Kong, Kubebuilder/controller-runtime, testcontainers, Kind, Telepresence...