MongoDB sponsored this post.
Everyone needs a database. At MongoDB, we’ve recognized the power and potential of the Kubernetes platform for running database workloads, ever since StatefulSets and Operators made that possible. While we believe the easiest way to use MongoDB is with Atlas — our global cloud database which runs across the three major public cloud vendors — we’re aware that some organizations are at different stages of their cloud journey. Many of these organizations are turning to Kubernetes to run both their application and storage layers, and want to run MongoDB there too.
The beauty of Kubernetes is that you are able to get many of the benefits of running in a public cloud, while running on-premises or in a hybrid cloud environment. MongoDB integrates natively with Kubernetes, so you are able to have full-stack database management capabilities on a modern orchestration platform.
Making Database-Level Changes
In the early days of container orchestration systems, the general advice was that they were good for managing and scaling stateless applications — usually web servers or batch jobs. Over time, Kubernetes has added many features that make running databases and other stateful, heterogeneous systems more natural.
Statefulsets guarantees consistent hostnames that survive pod restarts, PersistentVolumeClaims allows connecting to specific storage hardware, Custom Resource Definitions and Operators extends the Kubernetes API to make it possible to define services of any level of complexity (and has an Operator to take the steps required to deploy them for you).
The MongoDB Enterprise Kubernetes Operator does all this. You can define every piece of configuration you want your MongoDB instances to have, from the number of instances in a replica set, to shards in a sharded cluster, to whether you need SSL or authentication — all in a single yaml definition. You can then pass this to the Kubernetes API and have it deployed for you. This makes it incredibly easy to deploy MongoDB clusters based on a template matching your company’s standards and environment — from specific versions you’ve approved, to common security settings and access controls.
Our Operator builds on the many years of experience we have deploying MongoDB outside of orchestrated environments, by using the MongoDB Agent — which handles changes to MongoDB configuration — while the Operator handles the requests for the Kubernetes Objects that it needs. This means that complex state transitions — such as enabling TLS or authentication — are handled smoothly and with a minimal number of elections.
Building the Operator alongside our existing database management platforms, Ops Manager and Cloud Manager also make their full feature-sets available to databases deployed on Kubernetes. From backup, monitoring and alerting to our Performance Advisor, which gives advice on query performance.
As we expand the range of functionality available through the Operator, we simply add fields to the MongoDB CustomResourceDefinition. So as you upgrade the Operator, you will gain access to new options available through the Kubernetes API.
The Operator is available via its github repo and operatorhub.io. We are very excited about the possibilities of what we can achieve with upcoming Kubernetes features, such as PersistentVolume Snapshots and other improvements to Statefulsets, and seeing how the Operator ecosystem continues to evolve. If you have a Kubernetes cluster, and are interested in running MongoDB, then with the Operator a deploy can be a simple kubectl apply -f mongodb.yaml away!
Feature image by from Pixabay.
