Operator and CRD lifecycle
Version-aware installation, resource ownership, reconciliation behavior, admission controls, upgrade ordering, and rollback preparation.
TiDB Operator engineering
TiDB on Kubernetes
In short: TiDB on Kubernetes uses TiDB Operator to reconcile database components and supported lifecycle resources. JusDB DBREs design TidbCluster topology, storage, scheduling, upgrades, backup and restore, observability, and failure tests, while defining the DBA and platform-team responsibilities that Kubernetes automation does not replace.
The goal is a testable operating model for PD, TiKV, TiDB, and optional TiFlash—not simply a successful Helm install or a set of healthy pods.
TiDB Kubernetes engineering scope
Topology and scheduling
Node pools, zones, affinity, topology spread, disruption controls, requests, limits, and maintenance headroom for every TiDB component.
Storage engineering
StorageClass benchmarking, durability and attachment review, volume growth, replacement, snapshots, encryption, and failure rehearsal.
Backup and restore
Supported backup resources, object storage, credentials, retention, job monitoring, isolated restores, evidence, and recovery runbooks.
Change safety
Preflight checks, release compatibility, staged rollout, health gates, rebalance observation, rollback triggers, and post-change verification.
Reliability operations
SLO signals, alerts, capacity forecasts, failure games, access controls, incident procedures, and or DBA ownership handoff.
Production acceptance is evidence-based
Steady state
Queries, transactions, replica health, capacity, storage, and alerts meet defined workload thresholds.
Planned change
Scale and upgrade procedures have preflight, health, pause, rollback, and verification gates.
Infrastructure failure
Pod, node, volume, zone, and control-plane scenarios are rehearsed with application observations.
Data recovery
An isolated restore proves data scope, consistency, access, duration, and the runbook used by on-call staff.
TiDB on Kubernetes questions
What does TiDB Operator manage?
TiDB Operator extends Kubernetes with custom resources and controllers for TiDB clusters and related lifecycle tasks. It reconciles components such as PD, TiKV, TiDB, and optional TiFlash, plus supported backup, restore, and monitoring resources. The exact resource APIs and supported procedures depend on the installed Operator release and must be checked before upgrades.
Does TiDB Operator make the database self-operating?
No. Reconciliation automates declared lifecycle actions, but teams still own topology, capacity, storage, scheduling, disruption budgets, version compatibility, backup validation, credentials, observability, incident response, and application behavior. A healthy Kubernetes object is not evidence that query latency, data recovery, quorum, or business objectives are being met.
How should TiKV storage be designed on Kubernetes?
Storage selection starts with latency, throughput, durability, failure domains, attachment behavior, expansion, replacement, snapshots, and recovery procedures. TiKV replicas provide database-level redundancy, but they do not remove storage or cluster failure risks. We benchmark the candidate StorageClass and rehearse pod, node, volume, and zone failures before production acceptance.
How do you schedule PD, TiKV, TiDB, and TiFlash?
We map each component's resource profile and quorum or replica constraints to node pools, zones, affinity, anti-affinity, topology spread, taints, requests, limits, and maintenance capacity. TiKV and TiFlash storage and CPU behavior differ from stateless TiDB servers. PD quorum placement is reviewed separately from application traffic distribution.
Can TiDB scale on Kubernetes without interruption?
Scaling is declarative, but impact is workload- and operation-specific. Adding or removing capacity can trigger scheduling, data movement, replica work, cache changes, and temporary resource pressure. We define headroom and acceptance thresholds, stage changes, observe rebalance behavior, and keep rollback or pause criteria rather than promising an interruption-free result.
How are backups and restores validated?
We select a supported TiDB Operator backup path and storage target, protect credentials, define retention, monitor jobs, and perform restores into an isolated environment. Validation checks data scope, consistency, schema, application access, duration, capacity, and operational steps. A completed backup job is not treated as proof of recoverability.
Technical review and primary sources
TiDB on Kubernetes guidance checked against TiDB Operator docs
Review scope: TiDB Operator reconciliation, TidbCluster resources, component scheduling, storage, topology, backups, upgrades, monitoring, disruption controls, and recovery testing. Recommendations and outcomes depend on the TiDB release, workload, data, topology, infrastructure, and tested failure conditions; no generic performance, availability, migration interruption, or savings result is promised.
Technically reviewed by the JusDB Database Reliability Engineering team. Last reviewed: . See the team and roles.
- TiDB Operator architecture
Official architecture for TiDB Operator controllers and the resources they manage.
- Deploy TiDB on general Kubernetes
Primary stable deployment guidance for namespaces, prepared TidbCluster configuration, and cluster access.
- TiDB backup and restore on Kubernetes
Official backup and restore workflow, prerequisites, and supported storage choices.
Related TiDB Services
Explore more ways our TiDB experts can help with your database infrastructure.