A Kubernetes Operator is a software extension to Kubernetes that supports built-in capabilities to manage your Kubernetes applications in an automated fashion and that follows Kubernetes principles – especially the Control Loop pattern.

Why do we need a Kubernetes Operator? Let’s consider the StatefulSets example.

StatefulSets are great for certain use cases, but they don’t work that well for running complex software like databases because they focus on creating and managing pods, not on managing the software running on them. So if you wanted a four-node cluster and deployed Couchbase using StatefulSets, you would get four uninitialized Couchbase pods that don’t know about each other. It would then be up to you to join the nodes together into a cluster, and that means extra operational tasks.

By deploying Couchbase Autonomous Operator with a unique custom Couchbase controller, Kubernetes gets Couchbase-specific knowledge so that whenever a Couchbase pod is deployed, it can properly configure and join it with other Couchbase pods in the cluster.

Cluster provisioning, node failure, ad-hoc scaling, and many other management tasks also require Couchbase-specific knowledge within Kubernetes in order to be properly automated. Therefore, a Kubernetes operator is the best way to make the database a prime choice for cloud-native development on Kubernetes. However, when trying to find out which database is truly cloud-native and best fits your organization’s goals, you should consider multiple factors.

In this article, I compare Couchbase Autonomous Operator, a core part of the Couchbase Cloud-Native stack against MongoDB Enterprise Kubernetes Operator on various factors that are key to making the right decision on selecting a database for cloud-native developments.

Cloud-Native Integrations

An architecture diagram of the Couchbase cloud-native stack

Figure 1: Couchbase Cloud-Native Stack

As shown in Figure 1 above, Couchbase Autonomous Operator has tight – and in some cases, native – integrations with tools such as Prometheus Exporter, FluentBit, Helm Chart, Service Broker, Operator Metering, Istio Service Mesh, CoreDNS, GlusterFS, Ceph, Portworx, CNI. These are all fully certified and supported by the product.

MongoDB Enterprise Kubernetes Operator does not natively support all of these integrations. Service Broker and Helm Chart are extensions to MongoDB Atlas, but not for MongoDB Kubernetes Operator.

Architecture

An architecture diagram of Couchbase Autonomous Operator for Kubernetes

Figure 2: Architecture of Couchbase Autonomous Operator for Kubernetes

Couchbase Autonomous Operator is truly cloud-native and is based on the standard cloud-native Operator Framework. As a full-fledged product, all the operations are performed by Couchbase Autonomous Operator, whether it’s database provisioning, backup/restore, alerts/monitoring or native integrations with open source projects such as Prometheus or OSB API.

Couchbase Autonomous Operator provides a safety net for customers deploying on Kubernetes and simplifies Couchbase deployment with an admission controller with role-based access control (RBAC).

An architecture diagram of MongoDB Enterprise Kubernetes Operator

Figure 3: Architecture of MongoDB Enterprise Kubernetes Operator. Source

MongoDB Enterprise Kubernetes Operator is a wrapper around the MongoDB Ops Manager which itself is a wrapper around the MongoDB database. On the other hand, Couchbase Autonomous Operator is not a wrapper but a full-fledged utility product that extends Couchbase’s automation capabilities in the cloud to provide fully managed deployments.

MongoDB Enterprise Kubernetes Operator architecture is not cloud-native. Each Day-2 operation is performed not directly by MongoDB Kubernetes Operator but through MongoDB Ops Manager, including provisioning, backup/restore, alerts/monitoring, etc. MongoDB Enterprise Kubernetes Operator also doesn’t have an admission controller.

Operator Maturity Level

There are five maturity levels of any given Kubernetes Operator:

    • Basic Install
    • Seamless Upgrades
    • Full Lifecycle
    • Deep Insights
    • Auto-Pilot

 

Couchbase Autonomous Operator is certified as a Level 5 Kubernetes Operator that satisfies the criteria for each level up to the Auto-pilot, the highest level of the Operator Capability Maturity Model. (Reference.)

MongoDB Enterprise Kubernetes Operator is not a Level 5 operator. (Reference.)

Feature Comparison: Couchbase Autonomous Operator vs. MongoDB Enterprise Kubernetes Operator

Feature Category

Couchbase Autonomous Operator (CAO) 2.2 for Kubernetes

MongoDB Enterprise Kubernetes Operator 1.10
Auto-Scaling
 Couchbase Autonomous Operator supports auto-scaling of all Couchbase services.

This feature is unique across the database industry as you can horizontally auto-scale a single service or a group of services together based on fully customized and user-defined thresholds for any Couchbase stats as per your environment-specific needs.

 MongoDB Enterprise Kubernetes Operator does not support auto-scaling.

MongoDB Atlas supports only vertical auto-scaling with limited stats: memory and CPU utilization.

This limited flexibility can cost a lot during peak times if other operations are not configured (or prioritized) properly during auto-scaling.
Cluster Hibernation
 Couchbase Autonomous Operator supports cluster hibernation with an IMMEDIATE shutdown strategy.

Documents that are not flushed may die, but by setting an appropriate DURABILITY level, you can achieve better control over shutdown behaviour.

 MongoDB Enterprise Kubernetes Operator does not support cluster hibernation.

Cluster hibernation is supported only through Atlas. The documentation for PAUSE API lists all cluster config-properties being paused, except the DURABILITY level, which is the most vital parameter for customers to understand what happens to in-flight operations, queries, or documents. (Reference.)
Configuration and Deployment (CI/CD)
 CAO supports cloud-native integrations with Helm Charts and OSB API.

CAO can be deployed through Couchbase Helm Chart and Couchbase Service Broker.

 MongoDB Enterprise Operator does not support native integrations with Helm Charts and OSB API.

Note: MongoDB may support Helm or OSB API with other products such as Atlas or MongoDB Ops Manager, but MongoDB Enterprise Kubernetes Operator does not.
Maintenance and Upgrades
 Kubernetes Cluster Upgrades, CAO Upgrades, and Couchbase Cluster Upgrades are all supported through the Couchbase Autonomous Operator.

CAO supports bulk upgrades, along with traditional rolling upgrades with zero downtime.

Couchbase Autonomous Operator also supports custom rolling upgrades, i.e., you can select the number of pods or a percentage of pods in a cluster to upgrade while the rest of the pods continue to run as-is.

 MongoDB Enterprise Kubernetes Operator documentation does not mention the upgrade of MongoDB Database instances through MongoDB Enterprise Kubernetes Operator.

MongoDB Enterprise Kubernetes Operator does not support bulk upgrades. As per the steps mentioned here, the MongoDB Enterprise Kubernetes Operator may always throw an error and requires deleting the Operator, which involves downtime. (Reference.)
High Availability and Disaster Recovery
 Couchbase Autonomous Operator supports High Availability (HA), node affinity, auto-failover, fault tolerance, and XDCR. MongoDB Enterprise Kubernetes Operator supports fault tolerance and auto-failover.

However, it is internally dependent on MongoDB Ops Manager for HA and XDCR operations, which adds a service layer and may impact performance in terms of throughput and latency.
Security Management
 Couchbase Autonomous Operator’s security management includes RBAC, LDAP and TLS support. MongoDB Enterprise Kubernetes Operator provides security and also includes RBAC, LDAP and TLS support through the MongoDB Ops Manager.
Backup Management
 Backup and Restore are fully managed through Couchbase Autonomous Operator natively.

Backup to AWS S3 is also supported.

 Backup/restore is not managed through the MongoDB Enterprise Kubernetes Operator natively but through MongoDB Ops Manager.
Observability Analysis
 Couchbase Autonomous Operator has native integration with Prometheus, Grafana for monitoring, and alerts with FluentBit for centralized log forwarding and automated audit logging. Alerts and monitoring are supported through MongoDB Ops Manager.

MongoDB Enterprise Kubernetes Operator does not have a native enterprise integration with Prometheus or FluentBit

(Note: MongoDB Enterprise Kubernetes Operator documentation does not mention these integrations anywhere. Reference.)
Networking
 Couchbase Autonomous Operator supports cloud-native integrations with CNI, CoreDNS, and Istio Service Mesh. MongoDB Enterprise Kubernetes Operator does not have these native integrations.

MongoDB Enterprise Kubernetes Operator documentation does not mention any of these cloud-native integrations. (Reference.)
Storage
 Couchbase Autonomous Operator supports cloud-native storage integrations for GlusterFS, Ceph and Portworx.

Couchbase Autonomous Operator also supports the online expansion of persistent volumes as well as online backup volume scaling

Note: Online persistent volume expansion means scaling up persistent volumes without having to restart pods.

 MongoDB Enterprise Kubernetes Operator documentation does not mention any of these cloud-native integrations. (Reference.)

MongoDB Enterprise Kubernetes Operator does not support online storage scaling. It also does not support online backup volume scaling.

Conclusion

MongoDB provides most of its advanced features through MongoDB Ops Manager or MongoDB Atlas but does not support them through MongoDB Enterprise Kubernetes Operator. This additional layer of Ops Manager increases the cost of resources and impacts performance and adds unnecessary architectural complexities.

On the other hand, Couchbase Autonomous Operator is a full-fledged product and supports all services directly in a true cloud-native fashion. CAO is more mature than any other Kubernetes operator in the database industry.

References

 

Author

Posted by Madhuram Gupta

All Posts

Leave a reply