Skip to content

250424-pdms.md

Latest commit

 

History

History
216 lines (164 loc) · 4.56 KB

250424-pdms.md

File metadata and controls

216 lines (164 loc) · 4.56 KB

PD Micro Service Mode

Release Signoff Checklist

Items marked with (R) are required prior to targeting to a release.

  • (R) This design doc has been discussed and approved
  • (R) Test plan is in place
    • (R) e2e tests in kind
  • (R) Graduation criteria is in place if required
  • (R) User-facing documentation has been created in [pingcap/docs-tidb-operator]

Summary

Currently, PD support ms mode. It should be supported by tidb operator.

Motivation

Goals

  • Deploy PD in ms mode
  • Update PD from normal mode to ms mode
  • Update PD from ms mode back to normal mode

Non-Goals

  • Reuse common fields between PD components.

Proposal

User Stories (Optional)

Story 1

As a TiDB user, create PD in ms mode.

Story 2

As a TiDB user, create TSO service and change PD from normal mode to ms mode.

Risks and Mitigations

  • There are too many component CRDs and all of them need a similar overlay field.
    • Extract a common CRD for overlay field which can be referred by all components.

Design Details

API

PD (API Service)

Reuse PDGroup/PD CRD for API Service of PD in ms mode. Just add a new mode field.

apiVersion: core.pingcap.com/v1alpha1
kind: PDGroup
...
spec:
  template:
    spec:
      mode: ms

TSO Service

apiVersion: core.pingcap.com/v1alpha1
kind: TSOGroup
metadata:
  name: tso
spec:
  cluster:
    name: db
  replicas: 2
  template:
    metadata:
      annotations:
        author: pingcap
    spec:
      resources:
        cpu: "4"
        memory: 8Gi
      config: |
        [log]
        level = "debug"

Scheduling Service

apiVersion: core.pingcap.com/v1alpha1
kind: SchedulingGroup
metadata:
  name: scheduling
spec:
  cluster:
    name: db
  replicas: 2
  template:
    metadata:
      annotations:
        author: pingcap
    spec:
      resources:
        cpu: "4"
        memory: 8Gi
      config: |
        [log]
        level = "debug"

Admission Control Service

apiVersion: core.pingcap.com/v1alpha1
kind: AdmissionControllerGroup
metadata:
  name: admission
spec:
  cluster:
    name: db
  replicas: 2
  template:
    metadata:
      annotations:
        author: pingcap
    spec:
      resources:
        cpu: "4"
        memory: 8Gi
      config: |
        [log]
        level = "debug"

Operations

Update PD to ms mode

Steps are unordered. PD/PDGroup controllers will wait until TSOGroup is synced and ready.

  • Change PD mode to ms
  • Apply TSO
  • (Optional) Apply scheduling svc
  • (Optional) Apply admission control svc

Update PD back to normal mode

Steps are also unordered. TSOGroup will block deletion if PD mode is still ms.

  • Change PD mode to normal
  • (Optional) Del TSO
  • (Optional) Del scheduling svc
  • (Optional) Del admission control svc

Upgrade versions

TiDB Operator will automatically ensure the version skew policy of PDMS components. Now the default skew poligy is versions of all PDMS components are not greater than PD

Update PD Config

All components can update config at the same time. It all depends on the request order of clients.

Test Plan

Feature Gate

No feature gate

Drawbacks

  • Add too many components
  • All PD components share many common fields

Alternatives

All PDMS components(TSO, scheduler, ...) in one CRD

Pros:

  • Some fields can be shared.

Cons:

  • Not flexiable.
  • Cannot support scale subresource.
  • Too complex and hard to display status of a specific component.