Today we are proud to introduce Navigator, a centralised controller for managing the lifecycle of complex distributed applications. It intends to be the central control point for creating, updating, managing and monitoring stateful databases and services with Kubernetes.
Navigator is open source and extensible from day one. We launch today with support for Elasticsearch in alpha, with Couchbase support soon to land in the next few weeks, and more planned.
We’ll also be working closely with the Service Catalog Special Interest Group (SIG) to make it even easier to bring the power of Navigator to your applications by implementing the Open Service Broker API. You can read more about service catalog on GitHub.
Containerisation is quickly becoming the standard in modern enterprises. At Jetstack, we’ve seen a massive influx of organisations wishing to embrace containers and Kubernetes, to reduce costs, improve reliability and standardise the way in which they deploy their systems.
So far, this has not been so true for databases. A combination of mistrust and immaturity in today’s orchestration systems leads teams to utilise vendor-provided solutions such as RDS, Cloudant and Cloud SQL (to name but a few). These services work well, and push the onus of database management to a third-party. However, it can also mean that you are now locked-in to a particular cloud vendor, data interoperability is restricted to the feature set provided, and you are susceptible to business decisions which may not best align with your interests.
There have been a number of projects that attempt to simplify deployment of stateful services in containers, but few attempt to deliver an end-to-end solution that can deploy, manage and monitor your services. We want to make common databases and distributed applications first-class citizens in Kubernetes. we’ve developed Navigator to assume the role of database administrator within your own organisation, building on the tried-and-tested foundations of Kubernetes.
Navigator is the product of Jetsack’s experiences deploying stateful services on Kubernetes. For over a year, we have worked closely with database vendors and customers alike, and evolved our approach. We build heavily on the Operator model, but with a number of differences, including enabling support for multiple applications, whilst offering the same rich feature set for each.
In order to allow Navigator to support many different applications, it’s designed to remove application-specific knowledge from the Navigator itself. Instead, Pilots are programmed to directly interact with your system in order to trigger application-level actions in response to scale-up, scale-down or any other cluster-level action. Navigator is then able to communicate directly with these Pilots in order to instruct them as to any actions that must be taken.
Navigator architecture
Because the Pilots are able to communicate with Navigator, as well as control the database process, they are able to interrupt scale events and
inform Navigator of any state changes within the application that may occur. Without this model, it would not be possible for accurate and precise
management of the application’s state.
You can get started with Navigator by following our quick-start guide on GitHub.
We’d love to hear feedback and even accept contributions towards either the Navigator itself, or the Pilots.