[BUG]the new endpoint after expose cannot be found by executing 'kbcli cluster describe NAME'.

[tianyue86]

Describe the bug

Kubernetes: v1.31.1-aliyun.1
KubeBlocks: 1.0.0-beta.30
kbcli: 1.0.0-beta.15

To Reproduce
Steps to reproduce the behavior:

1. Expose redis cluster

kbcli cluster expose redis-dueryf --auto-approve --force=true   --type internet --enable true    --components redis  --role-selector primary  --namespace default
OpsRequest redis-dueryf-expose-gftcw created successfully, you can view the progress:
	kbcli cluster describe-ops redis-dueryf-expose-gftcw -n default

kbcli cluster list-ops redis-dueryf --status all  --namespace default
NAME                        NAMESPACE   TYPE     CLUSTER        COMPONENT   STATUS    PROGRESS   CREATED-TIME                  
redis-dueryf-expose-gftcw   default     Expose   redis-dueryf   redis       Succeed   1/1        Feb 27,2025 17:56 UTC+0800

2. Check result

kbcli cluster expose --help
Expose a cluster with a new endpoint, the new endpoint can be found by executing 'kbcli cluster describe NAME'.

===>the new endpoint cannot be found by executing 'kbcli cluster describe NAME'.
kbcli cluster describe redis-dueryf
Name: redis-dueryf	 Created Time: Feb 27,2025 17:33 UTC+0800
NAMESPACE   CLUSTER-DEFINITION   TOPOLOGY      STATUS    TERMINATION-POLICY   
default     redis                replication   Running   WipeOut              

Endpoints:
COMPONENT        INTERNAL                                                                     EXTERNAL   
redis            redis-dueryf-redis-redis.default.svc.cluster.local:6379                      <none>     
redis-sentinel   redis-dueryf-redis-sentinel-redis-sentinel.default.svc.cluster.local:26379   <none>     

Topology:
COMPONENT        SERVICE-VERSION   INSTANCE                        ROLE        STATUS    AZ                 NODE                                   CREATED-TIME                 
redis            7.2.4             redis-dueryf-redis-0            primary     Running   cn-zhangjiakou-c   cn-zhangjiakou.10.0.0.128/10.0.0.128   Feb 27,2025 17:34 UTC+0800   
redis            7.2.4             redis-dueryf-redis-1            secondary   Running   cn-zhangjiakou-c   cn-zhangjiakou.10.0.0.145/10.0.0.145   Feb 27,2025 17:35 UTC+0800   
redis-sentinel   7.2.4             redis-dueryf-redis-sentinel-0   <none>      Running   cn-zhangjiakou-c   cn-zhangjiakou.10.0.0.128/10.0.0.128   Feb 27,2025 17:33 UTC+0800   
redis-sentinel   7.2.4             redis-dueryf-redis-sentinel-1   <none>      Running   cn-zhangjiakou-c   cn-zhangjiakou.10.0.0.145/10.0.0.145   Feb 27,2025 17:34 UTC+0800   
redis-sentinel   7.2.4             redis-dueryf-redis-sentinel-2   <none>      Running   cn-zhangjiakou-c   cn-zhangjiakou.10.0.0.144/10.0.0.144   Feb 27,2025 17:34 UTC+0800   

Resources Allocation:
COMPONENT        INSTANCE-TEMPLATE   CPU(REQUEST/LIMIT)   MEMORY(REQUEST/LIMIT)   STORAGE-SIZE   STORAGE-CLASS   
redis                                100m / 100m          512Mi / 512Mi           data:20Gi      kb-default-sc   
redis-sentinel                       100m / 100m          512Mi / 512Mi           data:20Gi      kb-default-sc   

Images:
COMPONENT        COMPONENT-DEFINITION             IMAGE                                                                                    
redis            redis-7-1.0.0-alpha.0            apecloud-registry.cn-zhangjiakou.cr.aliyuncs.com/apecloud/redis-stack-server:7.2.0-v10   
                                                  apecloud-registry.cn-zhangjiakou.cr.aliyuncs.com/apecloud/agamotto:0.1.2-beta.1          
                                                  apecloud-registry.cn-zhangjiakou.cr.aliyuncs.com/apecloud/redis-stack-server:7.2.0-v14   
redis-sentinel   redis-sentinel-7-1.0.0-alpha.0   apecloud-registry.cn-zhangjiakou.cr.aliyuncs.com/apecloud/redis-stack-server:7.2.0-v10   
                                                  apecloud-registry.cn-zhangjiakou.cr.aliyuncs.com/apecloud/redis-stack-server:7.2.0-v14   

Data Protection:
BACKUP-REPO   AUTO-BACKUP   BACKUP-SCHEDULE   BACKUP-METHOD   BACKUP-RETENTION   RECOVERABLE-TIME   

Show cluster events: kbcli cluster list-events -n default redis-dueryf

4. check svc

k get svc|grep redis
redis-dueryf-redis-headless                  ClusterIP      None              <none>         6379/TCP,9121/TCP,8888/TCP,3501/TCP,3502/TCP   3h43m
**redis-dueryf-redis-internet                  LoadBalancer   192.168.28.163    39.98.123.34   6379:31630/TCP                                 3h22m**
redis-dueryf-redis-redis                     ClusterIP      192.168.244.185   <none>         6379/TCP                                       3h43m
redis-dueryf-redis-sentinel-headless         ClusterIP      None              <none>         26379/TCP,3501/TCP,3502/TCP                    3h45m
redis-dueryf-redis-sentinel-redis-sentinel   ClusterIP      192.168.158.89    <none>         26379/TCP                                      3h45m

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.