Couchbase Updates Operator for Database Running on Kubernetes Clusters
Couchbase today announced it has enhanced the Operator software it makes available for deploying its namesake document database on Kubernetes clusters to now include the ability to automate backup and recovery, replication and security tasks.
Anil Kumar, director of product management for Couchbase, says as more stateful applications are deployed on Kubernetes clusters, the demand for databases that can be deployed on Kubernetes clusters is increasing. Couchbase already has more than 75 customers who have employed its Operator software to deploy its database on Kubernetes clusters, he says.
Version 2.0 of Couchbase Autonomous Operator for Kubernetes takes Operator software to the next level, Kumar says, by automating various database management tasks in addition to making it easier to deploy Couchbase on a Kubernetes cluster.
Specifically, version 2.0 includes a fine-grained advanced Kubernetes Operator Security Model, certificate management capabilities and support for open source Prometheus container monitoring software commonly employed in Kubernetes environments. It also makes it easier to provision the Couchbase Sync Gateway, a web gateway through data shared between instances of Couchbase can be shared.
Kumar says much of the adoption of document databases is driven by developers who are downloading document databases, which are easier for them to incorporate within an application than a traditional relational database that typically requires a dedicated database administrator (DBAs). That doesn’t mean, however, that DBAs have no role to play; rather, they are now managing fleets of document databases that have been deployed by developers or different DevOps teams.
Version 2.0 of Couchbase Autonomous Operator for Kubernetes makes it easier to manage document databases deployed on Kubernetes clusters at scale regardless of whether they are deployed on-premises or on a public cloud, notes Kumar. The goal, he says, is to make troubleshooting the overall database environment easier by embedding self-healing capabilities into the Operator.
In general, Operators are starting to proliferate across Kubernetes environments. Based on open source code originally developed by CoreOS prior to its acquisition by Red Hat, Operators now exist for a wide range of software infrastructure that gets deployed on top of Kubernetes clusters. That shift has served to make Kubernetes clusters much more accessible to a wider number of IT organizations that might not have the skills needed to master all the nuances of Kubernetes application programming interfaces (APIs).
In the case of databases, the existence of those Operators may also play a significant role in accelerating the adoption of databases that are needed to build stateful applications based on microservices-based architectures. When coupled with access to multiple forms of persistent storage, it becomes apparent that more truly enterprise-class applications will be deployed on Kubernetes.
The challenge, of course, is to what degree the Kubernetes environments can be automated. IT teams may soon find themselves navigating through multiple Operators to manage those environments. While that may represent a substantial improvement from relying on APIs and command line interfaces (CLIs) to the average IT administrator, there may come a day soon when Operators become too much of a good thing.
