Deploy a Production‑Ready TiDB 8.4 Cluster on Kubernetes with TiDB Operator

Remember the article "TiDB on Cloud with TiDB Operator" from October 2022? This continuation provides a step‑by‑step tutorial for deploying a TiDB 8.4.0 cluster in a self‑managed Kubernetes production environment using the latest TiDB Operator (v1.6).

Environment Requirements

Production: use the latest GA version of TiDB Operator (currently v1.6).

TiDB cluster version >= 8.0 also requires TiDB Operator v1.6.

Kubernetes client v1.28, server v1.20+ (check with kubectl version ).

Docker CE 18.09+.

TiDB version 8.4.0 (or any required version).

TiDB‑Operator Production Deployment

1. Production‑grade Kubernetes configuration

Ensure the following settings (not exhaustive):

Disable firewall.

Disable SELinux.

Turn off swap.

Kernel parameter tuning.

CPU performance mode.

Ulimit configuration.

2. Initialize PV resource pool

TiKV relies heavily on I/O performance, so use local NVMe‑SSD storage for production. Create a local storage pool with local-static-provisioner (or local-volume-provisioner ) and assume the PV pool is ready before proceeding.

3. Deploy TiDB‑Operator

TiDB‑Operator is installed via Helm. After installing Helm, add the PingCAP repository and inspect the charts:

<code># helm repo add pingcap https://charts.pingcap.org/
# helm search repo pingcap
NAME                     CHART VERSION   APP VERSION   DESCRIPTION
pingcap/br-federation    v1.6.0          v1.6.0        br-federation Helm chart for Kubernetes
pingcap/diag            v1.3.1          v1.3.1        clinic diag Helm chart for Kubernetes
pingcap/tidb-backup     v1.5.1          DEPRECATED    (refer new instructions at https://do...)
pingcap/tidb-cluster    v1.5.1          DEPRECATED    (refer new instructions at https://do...)
pingcap/tidb-drainer    v1.6.0          -             A Helm chart for TiDB Binlog drainer.
pingcap/tidb-lightning  v1.6.0          -             A Helm chart for TiDB Lightning
pingcap/tidb-operator   v1.6.0          v1.6.0        tidb-operator Helm chart for Kubernetes
pingcap/tikv-importer   v1.5.1          -             A Helm chart for TiKV Importer
pingcap/tikv-operator   v0.1.0          v0.1.0        A Helm chart for Kubernetes</code>

Create the custom resource definitions (CRDs) required by TiDB‑Operator:

<code># wget https://raw.githubusercontent.com/pingcap/tidb-operator/v1.6.0/manifests/crd.yaml
# kubectl create -f ./crd.yaml
# kubectl get crd | grep pingcap
backups.pingcap.com
backupschedules.pingcap.com
dmclusters.pingcap.com
restores.pingcap.com
tidbclusterautoscalers.pingcap.com
tidbclusters.pingcap.com
tidbdashboards.pingcap.com
tidbinitializers.pingcap.com
tidbmonitors.pingcap.com
tidbngmonitorings.pingcap.com</code>

TiDB‑Operator installs two components by default: tidb-controller-manager (core) and tidb-scheduler . The scheduler is optional; set scheduler.create=false in values-tidb-operator.yaml to skip it.

<code># helm inspect values pingcap/tidb-operator --version=1.6.0 > values-tidb-operator.yaml
# helm install tidb-operator pingcap/tidb-operator \
    --namespace tidb-operator \
    --version=1.6.0 \
    -f values-tidb-operator.yaml
# kubectl get pods -n tidb-operator</code>

TiDB on Kubernetes Deployment

Prepare a cluster topology (example: 3 PD, 3 TiKV, 3 TiDB, 2 TiFlash) and create a YAML manifest (tidb-test.yaml):

<code>apiVersion: pingcap.com/v1alpha1
kind: TidbCluster
metadata:
  name: tidb-test
  namespace: tidb-test
spec:
  timezone: Asia/Shanghai
  pvReclaimPolicy: Retain
  configUpdateStrategy: RollingUpdate
  enableDynamicConfiguration: true
  acrossK8s: true
  discovery:
    limits:
      cpu: 2000m
      memory: 4Gi
    requests:
      cpu: 1000m
      memory: 2Gi
  pd:
    baseImage: pingcap/pd:v8.4.0
    replicas: 3
    enableDashboardInternalProxy: true
    storageClassName: local-storage
    requests:
      cpu: 10000m
      memory: 15Gi
      storage: 300Gi
    limits:
      cpu: 10000m
      memory: 15Gi
  tiflash:
    baseImage: pingcap/tiflash:v8.4.0
    maxFailoverCount: 3
    replicas: 2
    storageClaims:
    - resources:
        requests:
          storage: 1000Gi
      storageClassName: local-storage
  tikv:
    baseImage: pingcap/tikv:v8.4.0
    replicas: 3
    storageClassName: local-storage
    requests:
      cpu: 6000m
      memory: 12Gi
      storage: 1760Gi
    limits:
      cpu: 14000m
      memory: 32Gi
      storage: 1760Gi
    config:
      log-level: "info"
      raftdb:
        max-background-jobs: 10
        max-sub-compactions: 4
      raftstore:
        apply-pool-size: 8
        store-pool-size: 8
  tidb:
    baseImage: pingcap/tidb:v8.4.0
    replicas: 3
    limits:
      cpu: 12000m
      memory: 20Gi
    requests:
      cpu: 12000m
      memory: 20Gi
    service:
      type: NodePort
    config:
      status:
        record-db-qps: true
      performance:
        feedback-probability: 0.0</code>

Create a dedicated namespace and apply the manifest:

<code># kubectl create namespace tidb-test
# kubectl apply -f tidb-test.yaml -n tidb-test</code>

Verify the deployment:

<code># kubectl get tc -n tidb-test
# kubectl get pods -n tidb-test</code>

The resulting cluster includes discovery, PD, TiDB, TiFlash, and TiKV pods, each managed by StatefulSets. Services, Deployments, ReplicaSets, and PersistentVolumeClaims are also created, as shown by kubectl get all -n tidb-test .

Summary

This article covered environment preparation, PV pool initialization, TiDB‑Operator installation, CRD creation, and the full deployment of a production‑grade TiDB 8.4.0 cluster on Kubernetes. Following these steps enables you to build a reliable TiDB service in a production setting; future posts will discuss cluster initialization and external access.