Database Services
Based on Kubernetes Operators and the Kubernetes resource model, Database Services provides unified cluster management for relational, analytical, NoSQL, messaging, vector, and other database engines. Standard APIs, database-engine plugins, and controllers organize resource orchestration, operations, data protection, and observability for database clusters in a unified management plane.
The standard resource model maps database topology, composition, and runtime behavior to common resource objects, decoupling core control logic from individual database engines. Database instances run in Kubernetes environments and use foundational compute, storage, network, and identity-and-access capabilities; the specific supported version, topology, and functional scope of each database engine are defined by the corresponding plugin and its version.
The service uses declarative resource management to organize database-cluster configuration, scaling, data protection, runtime diagnostics, and access security. Database-engine capabilities, foundational resources, and tenant-access boundaries are associated in one model while preserving runtime boundaries across environments and engines.
Database Service Architecture
Database Services separates the control plane from the database runtime plane. The control plane provides consoles, open APIs, identity authentication, metadata, and resource and task management. The database runtime plane uses Kubernetes and Operator controllers to orchestrate database clusters and their associated resources.
Standard Resource Model
Database Services uses a layered resource model to describe the topology, composition, service relationships, and runtime behavior of different database engines, decoupling control logic from individual database engines. The model exposes resource relationships and state changes through standard APIs so different engines can integrate with consistent resource semantics in the management plane.
| Layer | Resource Object | Architectural Responsibility |
|---|---|---|
| Infrastructure layer | Kubernetes API | Provides foundational resource objects such as Pods, Services, PVCs, Secrets, and ConfigMaps. |
| Instance layer | Instance | Describes the foundational resources required to compose a single database replica. |
| Replica-set layer | InstanceSet | Organizes multiple Instances into a database instance set with multiple replicas. |
| Component layer | Component | Describes database behavior such as member management and backup and recovery, and organizes related instance sets. |
| Cluster layer | Cluster | Combines one or more Components into a complete database cluster. |
| Engine-extension layer | Addon and definition resources | Defines the topology, version, and capabilities of a database engine and maps them to the standard resource model. |
Engine Extension Mechanism
Database engines are integrated into the standard resource model through Addons and their definition resources. Plugins define engine versions, cluster topologies, runtime images, and the associated management capabilities, and map engine-specific behavior to the standard Cluster, Component, InstanceSet, and Instance resources. The available scope of an engine in an environment is determined by the enabled plugin and its version; plugin versions can evolve independently without changing the standard resource model.
Control and Runtime Relationships
- Control plane: Logically separates the console boundaries for platform administration and tenant use, centrally hosts open APIs, identity authentication, and metadata, and organizes control logic for resource management, task management, scheduling, and database-cluster runtime state.
- Database runtime plane: Uses Kubernetes, database Operators, and engine plugins to host database-cluster runtime state and resource relationships.
- Engine plugins: Map the topology, version, and operations behavior of a specific database engine to standard resources such as Clusters, Components, InstanceSets, and Instances.
- Foundational services: Storage, network, observability, and alerting capabilities are associated with database clusters through standard interfaces or supporting controllers.
Database Engines and Cluster Capabilities
Database Services integrates different database types through engine plugins and organizes their cluster topology and compute architecture within the standard resource model. Engine definitions can map standalone, primary-standby, and distributed topologies and their service roles to standard resource objects; the available version and topology are determined by the corresponding engine plugin version.
Core Capability Domains
| Capability Domain | Technical Capability |
|---|---|
| Cluster lifecycle | Defines cluster configuration for version, topology, availability zone, parameter template, time zone, namespace, and labels, as well as lifecycle states and resource relationships for deletion protection, compute and storage specification changes, horizontal scaling, start and stop, ordered restart, and service access addresses. A stopped state can release compute resources while retaining storage, network, and backup relationships. Deletion semantics can be associated with compute and network resource release and backup-retention policies. |
| Topology and access | Organizes standalone, primary-standby, or distributed topologies as defined by each engine, and can expose database service addresses through service roles, LoadBalancer, NodePort, or Host Network. Access patterns such as read-write separation are defined by the corresponding engine topology and service components. |
| High availability and disaster recovery | Supports engine-specific fault detection, failover, role switching, standby rebuilding, and recycle-bin capabilities. Role switching can retain the service access entry point. The applicable scope is defined by the engine topology and plugin implementation. |
| Parameter and data management | Manages parameter types, descriptions, value ranges, parameter templates, and parameter-change history, as well as database accounts and permissions, database objects, DDL and DML, SQL execution plans, sessions, and data import and export. |
Data Protection and Observability
Database Services organizes runtime assurance for database clusters around backup and recovery, runtime monitoring, log auditing, alert processing, and access security. These capabilities are associated with database clusters and their runtime environments through the standard resource model; their applicable scope is defined by the engine topology and plugin implementation.
Data Protection
Data protection consists of backup mechanisms, backup repositories, and recovery capabilities.
- Backup mechanisms: Supports online full, incremental, and continuous backups.
- Policies and repositories: Backup policies define execution time, frequency, and retention period. The service centrally manages backup policies, backup sets, recovery records, and backup repositories, which can integrate S3-compatible object storage, NAS, and other storage services.
- Backup security and audit: Supports backup encryption and retains backup, recovery, and related management-operation records for audit.
- Recovery capabilities: Supports new-cluster recovery and point-in-time recovery from backup sets, as well as same-environment and cross-environment recovery.
Observability, Audit, and Access Security
- Observability data interfaces: Uses OpenTelemetry to organize monitoring-data interfaces and formats across hosts, containers, Kubernetes objects, database clusters, and their logs. Monitoring data can integrate with metric systems such as Prometheus and VictoriaMetrics; logs can integrate with systems such as ClickHouse, Elasticsearch, and Loki; and data can also be pushed to messaging systems such as Kafka.
- Metric collection: Host metrics can be collected through Node Exporter, container metrics through cAdvisor, and Kubernetes object status through kube-state-metrics. Database-cluster metrics are collected through the corresponding engine Exporter, including QPS, TPS, and response time.
- Runtime logs and audit: Manages database runtime logs, slow logs, and SQL audit logs.
- Alert processing: Uses rule-evaluation and notification services to organize metric collection, rule evaluation, alert aggregation, and notification policies into an alert-processing path, and supports threshold or PromQL rules, alert suppression, and repeated-alert noise reduction.
- Access security: Protects database-service access paths through mechanisms such as TLS certificates.
Common mechanisms for unified identity authentication, general licensing, platform-level observability and operations, and lifecycle management are described in the Platform Management and Operations chapter. This topic describes only the resource and runtime boundaries of those mechanisms in Database Services.
Multi-Environment and Multi-Tenant Management
Database Services abstracts one Kubernetes cluster as one environment and hosts managed database clusters within that environment. An environment can run in a public cloud, private cloud, or data center and host virtual or physical foundational resources. The multi-environment model brings different regions, data centers, or cloud environments into a unified management view while retaining the resource and runtime boundaries of each environment. Organizations and roles define tenant access boundaries for environments and database resources.
Environment Resource Model
| Object | Resource and Runtime Boundary |
|---|---|
| Environment | Corresponds to a single Kubernetes cluster and defines the management boundary for database clusters, nodes, storage, and network resources. |
| Control-plane nodes | Host platform-management components such as Operators, monitoring, logging, and task scheduling. |
| Data-plane nodes | Host database instances and runtime collection components. Node groups can isolate resources between database engines, online and offline workloads, and critical and noncritical workloads. |
| Node groups and scheduling | Use node roles and groups to constrain database-instance placement, and use topology distribution, scheduling suspension, and maintenance eviction to reduce the risk of concentrating like replicas on one node. |
| Storage resources | Incorporate log, backup, object-storage, and database StorageClass resources into environment settings. Database storage can integrate local disks, cloud disks, or distributed storage through CSI. |
| Network resources | Support LoadBalancer, NodePort, and Host Network service exposure to provide database clusters with access addresses and ports, and organize access entry points by service role. Private environments can use service-exposure components such as MetalLB and address pools to provide highly available Layer 4 VIP entry points. A VIP can be rebound to another node when its bound node fails. |
| Engine specifications | Define resource specifications for database engines, including CPU and memory requests and limits. The ratio between requests and limits can express scheduling requests and runtime ceilings, and can support policy-based resource overcommitment. The corresponding engines and specifications can be enabled by environment. |
Tenants and Governance
- Tenants and permissions: Uses organizations to manage tenant members, roles, and resource-access boundaries, and supports enabling database engines per environment. The role model can distinguish administration, member, audit, and read-only access responsibilities.
- Resource and availability governance: Provides resource metering and service-availability statistics, and can collect service health through periodic database connections or simple queries.
- Vulnerability impact identification: Associates CVE information with database-engine versions and affected clusters, and supports identifying the impact scope by engine type and severity.
- Automated inspection: Supports inspection policies for database instances or environments, runs checks according to defined schedules and objects, and produces inspection results.