How to Modify enableDashboardInternalProxy After Deploying tidb-operator 6.1

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: tidb-operator部署6.1后如何修改enableDashboardInternalProxy

| username: TiDBer_hf1k4gsi

[TiDB Usage Environment] Test/PoC
[TiDB Version] 6.1
[Encountered Problem: Symptoms and Impact]
Accessing the dashboard through ingress configuration

When I request ${host}/dashboard, it gets redirected to an internal service address and cannot be accessed
http://tidb-pd-2.tidb-pd-peer.default.svc:2379/dashboard/

[Reproduction Path]
Complete the default configuration through tidb-operator and deploy version 6.1
I need to enable the PD Dashboard. According to the official documentation, the first step is to configure enableDashboardInternalProxy: true

apiVersion: pingcap.com/v1alpha1
kind: TidbCluster
metadata:
  name: basic
spec:
  pd:
    enableDashboardInternalProxy: true
    replicas: 3

Apply it using kubectl apply -f
Check that the value exists using kubectl get TidbCluster basic -o yaml
Access through ingress configuration

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: access-dashboard
  namespace: ${namespace}
spec:
  rules:
    - host: ${host}
      http:
        paths:
          - backend:
              serviceName: ${cluster_name}-discovery
              servicePort: 10262
            path: /dashboard

When I request ${host}/dashboard, it gets redirected to an internal service address and cannot be accessed
http://tidb-pd-2.tidb-pd-peer.default.svc:2379/dashboard/

According to the documentation Modify TiDB Cluster Configuration | PingCAP Docs,
`After PD is successfully started for the first time, some configuration items of PD will be persisted to etcd, and subsequent configurations will be based on the configurations in etcd. Therefore, after PD is started for the first time, these configuration items can no longer be modified through TidbCluster CR.

Among the configuration items that support online modification in PD, except for log.level, other configuration items no longer support modification through TidbCluster CR after PD is started for the first time.

For TiDB clusters deployed in Kubernetes, if you need to modify PD configuration parameters, you need to use SQL, pd-ctl, or PD server API to dynamically modify them.`

It is estimated that the modification of TidbCluster has not been applied to PD
In the SQL query
show config where type='pd' and name='dashboard.internal-proxy'; all return false
Tried to update, although it returned success, it had no effect, still showing false
set config pd 'dashboard.internal-proxy'='true';

Some posts say that exporting the TidbCluster configuration and rebuilding it succeeded, but I am worried that rebuilding will lose data, so I dare not delete the cluster.

[Resource Configuration]
[Attachments: Screenshots/Logs/Monitoring]

image
image530×721 14.4 KB

image
image804×269 8.49 KB

2
| username: TiDBer_hf1k4gsi | Original post link

Tried to update the configuration using pdctl, but failed with the error "config prefix dashboard not found"

/ # ./pd-ctl config set dashboard/internal-proxy true
Failed to set config: [400] "config item dashboard/internal-proxy not found"

/ # ./pd-ctl config set dashboard.internal-proxy true
Failed to set config: [400] "config prefix dashboard not found"

/ # ./pd-ctl config set dashboard.prefix /dashboard
Failed to set config: [400] "config prefix dashboard not found"

/ # ./pd-ctl config set prefix /dashboard
Failed to set config: [400] "config item prefix not found"

/ # ./pd-ctl config set dashboard.public-path-prefix /dashboard
Failed to set config: [400] "config prefix dashboard not found"

/ # ./pd-ctl config set dashboard.prefix /dashboard
Failed to set config: [400] "config prefix dashboard not found"

/ # ./pd-ctl config set dashboard.internal-proxy true
Failed to set config: [400] "config prefix dashboard not found"
3
| username: Min_Chen | Original post link

Hi, I couldn’t reproduce your issue on my end.
Could you please provide your operator version and the tidbcluster YAML file?
Have you checked the operator logs for any anomalies? Also, did you check if the configmap has the configurations added?