pingcap / pingcap/tidb-operator
TiDB-operator fails to start the tiproxy servers if spec.tiproxy.version not provided
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 1.3k
- Forks
- 540
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 18
Description
Bug Report
What version of Kubernetes are you using?
Client Version: v1.31.1
Kustomize Version: v5.4.2
What version of TiDB Operator are you using?
v1.6.0
What's the status of the TiDB cluster pods?
TiProxy pods are in CrashBackOffLoop State.
What did you do?
We deployed a cluster with TiProxy.
How to reproduce
- Deploy a TiDB cluster with TiProxy enabled, for example:
apiVersion: pingcap.com/v1alpha1
kind: TidbCluster
metadata:
name: test-cluster
spec:
configUpdateStrategy: RollingUpdate
enableDynamicConfiguration: true
helper:
image: alpine:3.16.0
pd:
baseImage: pingcap/pd
config: "[dashboard]\n internal-proxy = true\n"
maxFailoverCount: 0
mountClusterClientSecret: true
replicas: 3
requests:
storage: 10Gi
pvReclaimPolicy: Retain
ticdc:
baseImage: pingcap/ticdc
replicas: 3
tidb:
baseImage: pingcap/tidb
config: "[performance]\n tcp-keep-alive = true\ngraceful-wait-before-shutdown\
\ = 30\n"
maxFailoverCount: 0
replicas: 3
service:
externalTrafficPolicy: Local
type: NodePort
tiflash:
baseImage: pingcap/tiflash
replicas: 3
storageClaims:
- resources:
requests:
storage: 10Gi
tikv:
baseImage: pingcap/tikv
config: 'log-level = "info"
'
maxFailoverCount: 0
mountClusterClientSecret: true
replicas: 3
requests:
storage: 100Gi
scalePolicy:
scaleOutParallelism: 5
timezone: UTC
tiproxy:
replicas: 5
sslEnableTiDB: true
version: v8.1.0
What did you expect to see?
TiProxy pods should start successfully and be in the Healthy state.
What did you see instead?
The TiProxy pods kept crashing and be in CrashBackOffLoop state due to ErrImagePull.
Root Cause
The root cause is that we specified spec.version to v8.1.0 which will be used for all components when pulling their images. However, there is no pingcap/tiproxy:v8.1.0 image available on the DockerHub causing the image pull process to fail for the TiProxy.
How to fix
Since the image tag for TiProxy follows a different naming convention compared to other components like TiKV and TiFlash, we recommend setting a default value of main for spec.tiproxy.version. This will ensure the TiDB Operator overrides the version tag for TiProxy and pulls the correct image.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No file or test is named. Start by tracing TiProxy spec handling and image-tag selection when spec.tiproxy.version is omitted; verify that the default uses main rather than spec.version v8.1.0, and reproduce the deployment to confirm TiProxy pods start successfully without ErrImagePull.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100