How to Deploy TiDB on Private or Public Cloud with TiDB Operator

How to deploy TiDB clusters on private or public cloud? TiDB was designed to work with Kubernetes from the start, and TiDB Operator is the tool that makes it run on the cloud.

Kubernetes Overview

Before discussing TiDB Operator, a brief introduction to Kubernetes (k8s) is provided.

<code>Kubernetes (often abbreviated as K8s) is an open‑source system for automating deployment, scaling, and management of containerized applications.</code>

<code>The system was designed by Google and donated to the Cloud Native Computing Foundation (CNCF).</code>

<code>It provides a platform for automatic deployment, scaling, and running application containers across a cluster of hosts and supports tools such as Docker.</code>

The architecture of Kubernetes includes a master plane and worker nodes.

Master components

kube‑apiserver : the single entry point for resource operations, handling authentication, authorization, access control, API registration and discovery.

kube‑controller‑manager : maintains cluster state, performs fault detection, auto‑scaling, rolling updates, etc.

kube‑scheduler : schedules Pods onto suitable nodes according to defined policies.

etcd : stores the entire cluster state and metadata.

Node components

kubelet : manages container lifecycles and handles volumes (CVI) and networking (CNI).

cAdvisor : collects resource usage statistics of containers and nodes, exposing them via the kubelet API.

kube‑proxy : provides service discovery and load balancing inside the cluster.

Pod : the smallest deployable unit in Kubernetes, which may contain one or more tightly coupled containers.

Kubernetes networking uses two IP types: Pod IP (real IP on a network interface) and Service Cluster IP (virtual IP managed by kube‑proxy and iptables).

Kubernetes Operator Overview

What is an Operator?

A Kubernetes Operator packages, deploys, and manages a Kubernetes‑native application. It simplifies the management of stateful services such as MySQL or Redis by using the Kubernetes API and kubectl to automate complex operational tasks.

Typical automation provided by an Operator includes:

On‑demand deployment of applications or databases

Backup and restore of application state

Handling upgrades and configuration changes

Publishing a service so that non‑Kubernetes‑aware applications can discover it

Simulating failures to test stability

Leader election for distributed applications without built‑in election mechanisms

TiDB Operator Features

TiDB Operator is an automatic operation system for TiDB clusters on Kubernetes. It manages the full lifecycle of TiDB, including deployment, upgrade, scaling, backup/restore, and configuration changes, allowing TiDB to run seamlessly on public or private clouds.

Secure horizontal scaling : enables TiDB to expand across the cloud.

Rolling updates : performs graceful, zero‑downtime updates of TiDB clusters.

Multi‑tenant support : multiple TiDB clusters can be deployed and managed within a single Kubernetes cluster.

Automatic failover : detects node failures and switches the TiDB cluster to healthy nodes automatically.

Kubernetes package manager integration : users can deploy TiDB with a single Helm command.

Built‑in monitoring : automatically deploys Prometheus and Grafana with features such as cross‑namespace monitoring, multi‑replication, sharding, dynamic rule updates, and integration with the Thanos monitoring stack.

Heterogeneous clusters : supports mixed workloads (e.g., separate TiDB servers for OLTP and OLAP or different storage for TiKV nodes) within a single cluster.

In short, TiDB Operator can be regarded as the “TiUP” tool for Kubernetes clusters.

TiDB Operator Architecture

The architecture consists of custom resources (CR), TiDB Pods, the Operator itself, and underlying Kubernetes modules.

CR (Custom Resource) : the TidbCluster CRD defines the desired state of a TiDB cluster.

TiDB Pods : Pods for TiDB Server, PD, TiKV, TiFlash, TiCDC, etc., plus a discovery Pod for component discovery.

Operator core : tidb‑controller‑manager: controllers for TiDB, PD, TiKV, etc., reconcile the actual state with the desired state defined in the TidbCluster resource. tidb‑scheduler: extends the Kubernetes scheduler with TiDB‑specific scheduling logic, such as pod affinity rules that prevent PD and TiKV from landing on the same node.

Underlying modules : the Operator leverages native Kubernetes capabilities (kube‑scheduler, kube‑apiserver, kube‑controller‑manager) and follows the CRD + controller pattern to automate application management and reduce operational overhead.

More details will be covered in upcoming articles, including step‑by‑step deployment of TiDB Operator on a self‑built Kubernetes cluster and various operational tasks.