[Docs] Clarify ClusterMesh troubleshooting steps when KVStoreMesh is enabled

[weizhoublue]

when the KVStoreMesh is on, I find the debug steps are not in line with the facts, the hostAliases does not exist in Cilium DaemonSet, but exist in the clustermesh-apiserver deployment

the chart code

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cilium
  namespace: {{ .Release.Namespace }}
  labels:
    k8s-app: cilium
    .....
      {{- if and .Values.clustermesh.useAPIServer .Values.clustermesh.config.enabled (not .Values.clustermesh.apiserver.kvstoremesh.enabled) }}
      hostAliases:
      {{- range $cluster := .Values.clustermesh.config.clusters }}
      {{- range $ip := $cluster.ips }}
      - ip: {{ $ip }}
        hostnames: [ "{{ $cluster.name }}.{{ $.Values.clustermesh.config.domain }}" ]
      {{- end }}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: clustermesh-apiserver
  .......
      hostAliases:
      {{- range $cluster := .Values.clustermesh.config.clusters }}
      {{- range $ip := $cluster.ips }}
      - ip: {{ $ip }}
        hostnames: [ "{{ $cluster.name }}.{{ $.Values.clustermesh.config.domain }}" ]
      {{- end }}

and the remote cluster address does not exist in the secret cilium-clustermesh, but exist in the secret cilium-kvstoremesh

[root@master1 ~]# kubectl get secret -n kube-system cilium-clustermesh -o yaml | yq '.data' | awk '{print $2}' | base64 -d
endpoints:
- https://clustermesh-apiserver.kube-system.svc:2379
trusted-ca-file: /var/lib/cilium/clustermesh/common-etcd-client-ca.crt
key-file: /var/lib/cilium/clustermesh/common-etcd-client.key
cert-file: /var/lib/cilium/clustermesh/common-etcd-client.crt

[root@master1 ~]# kubectl get secret -n kube-system cilium-kvstoremesh -o yaml | yq '.data' | awk '{print $2}' | base64 -d
endpoints:
- https://cluster2.mesh.cilium.io:32379
trusted-ca-file: /var/lib/cilium/clustermesh/common-etcd-client-ca.crt
key-file: /var/lib/cilium/clustermesh/common-etcd-client.key
cert-file: /var/lib/cilium/clustermesh/common-etcd-client.crt

[lambdanis]

docs structure OK, but someone from @cilium/sig-clustermesh please review the content.

[giorio94]

Looks good to me content wise. I know that there's some ongoing effort to revamp the clustermesh troubleshooting guide, but this improvement is definitely worth.

[lambdanis]

/test

[lambdanis]

@weizhoublue Could you maybe update the CODEOWNERS file to add sig-clustermesh as an owner of the docs you changed? That is:

Documentation/operations/troubleshooting_clustermesh.rst @cilium/sig-clustermesh @cilium/docs-structure

But it's only tangentially related to the change, so it's fine to merge the change as is IMO.

[weizhoublue]

@weizhoublue Could you maybe update the CODEOWNERS file to add sig-clustermesh as an owner of the docs you changed? That is:

Documentation/operations/troubleshooting_clustermesh.rst @cilium/sig-clustermesh @cilium/docs-structure

But it's only tangentially related to the change, so it's fine to merge the change as is IMO.

my pleasure, and updated

[giorio94]

/test

[weizhoublue]

the PR seems to have no business failing the connectivity test of the check
should I try to rebase the main branch ?

[lambdanis]

@weizhoublue yeah, the CI fail seems completely unrelated, it shouldn't block the merge I think

[lambdanis]

/test

[weizhoublue]

some connectivity case failed, I try to rebase again

[lambdanis]

/test

[lambdanis]

@weizhoublue It was probably a flake, don't worry about it. The checks relevant to your change passed, so once there is an approve from contributing the PR can be merged.

[weizhoublue]

@weizhoublue It was probably a flake, don't worry about it. The checks relevant to your change passed, so once there is an approve from contributing the PR can be merged.

thanks

[giorio94]

@weizhoublue It looks like this PR needs to be rebased to pick the latest CI changes

[weizhoublue]

@weizhoublue It looks like this PR needs to be rebased to pick the latest CI changes

ok

[lambdanis]

/test