TiCDC changefeed management

Is your feature request related to a problem?

Background

This is a follow-up to the tidb-operator discussion:

https://github.com/pingcap/tidb-operator/issues/6771

The original proposal was to add a TiCDCChangefeed CRD to tidb-operator so changefeeds could be managed declaratively through Kubernetes. After discussion, I agree with the concern that tidb-operator should stay focused on Kubernetes resource management, while TiCDC changefeeds are logical TiCDC API resources.

I would like to discuss whether TiCDC should provide, host, or help define a separate management plane for declarative TiCDC API resources, starting with changefeeds.

Motivation

Today, TiCDC changefeeds are usually managed imperatively through cdc cli or the TiCDC OpenAPI. This works for small deployments, but becomes difficult when users manage:

• many changefeeds in one TiCDC cluster
• many TiCDC clusters across environments or regions
• changefeeds owned by different application teams
• changefeed definitions that should be reviewed, versioned, applied, and reconciled

With the TiCDC new architecture designed to handle many changefeeds per cluster, users need a reliable way to declare desired changefeed state, apply it consistently, detect drift, reconcile changes, and expose status.

A Kubernetes/GitOps workflow would be useful here:

• declare changefeeds as YAML
• apply through kubectl, Argo CD, Flux, or another deployment system
• reconcile remote TiCDC OpenAPI state continuously
• expose changefeed status in Kubernetes
• use RBAC/admission/audit around changefeed lifecycle changes
• manage many TiCDC clusters through a consistent API

Proposal

Create a separate controller/operator, outside tidb-operator, for managing TiCDC API resources declaratively.

The first resource could be a Changefeed or TiCDCChangefeed CRD:

apiVersion: ticdc.pingcap.com/v1alpha1
kind: TiCDCChangefeed
metadata:
  name: user-events
spec:
  clusterRef:
    name: prod-ticdc-us-east
  changefeedID: user-events
  sinkURISecretRef:
    name: user-events-sink
    key: sinkURI
  startTs: "438102428640256000"
  paused: false
  replicaConfig:
    filter:
      rules:
      - app_user.*
status:
  state: Normal
  checkpointTs: "438102428640256512"
  resolvedTs: "438102428640256600"
  observedGeneration: 3

A separate TiCDCCluster or similar target resource could define how to connect to one TiCDC cluster. This is important because not all TiCDC deployments run inside Kubernetes; the controller should be able to manage any reachable TiCDC OpenAPI endpoint, not only TiCDC clusters created by tidb-operator.

apiVersion: ticdc.pingcap.com/v1alpha1
kind: TiCDCCluster
metadata:
  name: prod-ticdc-us-east
spec:
  endpoint: http://ticdc-peer.tidb.svc:8300
  authSecretRef:
    name: ticdc-api-auth

The controller would reconcile desired state against TiCDC OpenAPI v2:

Desired state	Controller action
Changefeed CR exists, remote changefeed missing	Create changefeed
spec.paused: true	Pause changefeed
spec.paused: false	Resume changefeed
Spec changed while paused	Update changefeed config
CR deleted	Delete remote changefeed and remove finalizer
Remote status changed	Update CR status

Scope

I suggest starting with TiCDC changefeeds only.

This does not need to be part of tidb-operator. It could live in:

• pingcap/ticdc
• a new PingCAP repository

The controller should use TiCDC OpenAPI rather than shelling out to cdc cli.

It should also support TiCDC clusters that are not running on Kubernetes, as long as their OpenAPI endpoint is reachable and credentials are provided.

Open questions

• Does the TiCDC team think declarative/GitOps-style changefeed management is a valid direction?
• Should this live in pingcap/ticdc, or should it be a new PingCAP repository?
• Should the controller support any reachable TiCDC OpenAPI endpoint, including TiCDC deployments outside Kubernetes?
• Should the API group be TiCDC-specific, for example ticdc.pingcap.com, or broader?
• How should drift be handled if users modify changefeeds directly through TiCDC OpenAPI?
• What compatibility guarantees are expected across classic/new architecture and OpenAPI versions?

I have an existing implementation of the core reconciliation logic from the tidb-operator proposal and am willing to adapt it into a separate controller if this direction makes sense.

Describe the feature you'd like

As above.

Describe alternatives you've considered

No response

Teachability, Documentation, Adoption, Migration Strategy

No response

Start with the linked tidb-operator issue 6771 and the TiCDC OpenAPI v2 proposal, then review the author's existing reconciliation implementation. The issue provides no repository files or tests to edit; work is complete only after the controller's ownership, API scope, compatibility, and drift behavior are agreed.