Join local and remote clusters #3772
Comments
|
cc @chaosi-zju for help |
OK，let me try~ |
|
@asierzd Hello, it's my honor to help you to solve this problem. Firstly, can you add this steps to your previous operation for a trial and provide the result info to me? 1、*** LOCAL:
after that, execute: $ docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "localcluster-control-plane"
$ kubectl config set-cluster "kind-localcluster" --server="https://xx.xx.xx.xx:6443"
2、*** REMOTE:
after that, execute: $ docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "remotecluster-control-plane"
$ kubectl config set-cluster "kind-remotecluster" --server="https://xx.xx.xx.xx:6443"
feel free to provide feedback on any unclear areas |
|
In addition, can you provider the logs of karmada-controller-manager you can do like this: # First, check the pod name of karmada-controller-manager
kubectl --kubeconfig=${kubeconfig of host cluster} get po -o wide -n karmada-system
# Then, check the logs of karmada-controller-manager
kubectl --kubeconfig=${kubeconfig of host cluster} logs -f ${pod name of karmada-controller-manager} -n karmada-system |
|
Hello @chaosi-zju thank you very much for your help. After performing the config set-cluster for each cluster, I can do the ssh tunnels correctly, but I can't access any of the clusters, for example in local I obtain a timeout, and therefore I can't execute the Karmada join: *** LOCAL: *** REMOTE:
By the way, I have discovered this error in the second log for the Join: It could be related to the ip or port used for the clusters. Let me know if you discover the problem. Thank you very much. |
|
I have tried again changing the apiserver ip and port as specified in another local machine and now it returns outputs of kubectl as expected (The issue with this must have been with WSL2 Ubuntu22, which is where I was testing the local cluster). I have executed again the same steps specified at the beginning of this issue, it says it has been joined succesfully, but when I execute the |
|
@asierzd According to your description, I understand that the network between the remote kind cluster container and the local cluster is disconnected. I understand that the tunnel you opened can only interwork between the port of the local and remote machines, but the Karmada component accesses the member cluster in the kind container. So, I understand you can check the remote container to the local cluster network again, hopefully to help you =>remote cluster docker ps -a | grep remote-control-plane
docker exec containerdID curl http://127.0.0.1:5252 -H "Bear xxxxx" -kContainer in direct access to port 5252, I understand must be network unreachable |
|
Hello @Fish-pro, thank you for your help. I have executed your commands with the remote cluster, and this is the result: If I execute the curl request from the remote EC2 outside the docker container of the remote cluster, it is able to reach the api-server of the local cluster: I have also seen the same behavior doing the requests from the local cluster and the local machine to the remote cluster. Could this connection refused be something related to the permissions of the Kubernetes clusters or Karmada, or is it a problem of the network with the tunnelling? Thank you very much. |
|
@asierzd kind: Cluster
apiVersion: "kind.x-k8s.io/v1alpha4"
networking:
apiServerAddress: "0.0.0.0"
nodes:
- role: control-plane |
|
@Fish-pro Thank you very much. |
@asierzd kind: Cluster
apiVersion: "kind.x-k8s.io/v1alpha4"
networking:
apiServerAddress: "0.0.0.0"
nodes:
- role: control-planeFollow-up problems only need to ensure that the cluster where karmada resides can access this ip address Regarding the latter two questions, I understand that if karmada is running in a kubernetes cluster, if karmada is running in a node and the local cluster is tunnelled, then I understand that the above approach is accessible in this case. However, it will bring new problems, if the karmada pod drifts to a new node, then the new node needs to ensure that the node tunnel is opened. |
|
Hello @Fish-pro, I'm sorry for the delay, I had some trouble setting up this configuration and with other projects at work. In order to be able to do curl requests to the api-server I had to create the cluster with this kind-config: And then change the api-server to the IP of the control plane docker container: With this configuration I can do the curl requests, however when I try to access the cluster via kubectl, I get a I now also suspect that I might have 6443 port closed in the new local machine I am testing. So hopefully tomorrow I can ask for them to check the port and test it directly. By your last response I suppose that setting the service could create more issues than facilitating the problem right? Thank you very much for your help. |
I am trying to join two kind clusters using Karmada Push mode, a kind cluster in my local PC (which is in the private network of my organization), and a kind cluster in an AWS EC2 instance.
After I set up a bidirectional SSH tunnel, I try to join the local cluster to the remote cluster using Push mode (from the EC2), it says that it has been joined succesfully, but the Ready state is in False.
I am going to describe the steps followed in order to reproduce the issue (LOCAL is my local machine and REMOTE is the EC2 instance).
*** LOCAL:
=> OK!
*** REMOTE:
=> OK!
// I copy the kubeconfig of localcluster to the remote EC2 (.kube/config-local)
// I copy the kubeconfig of remotecluster and karmada-apiserver to local machine
// In order to be able to access the clusters in both directions, ssh tunnels are opened in the following way
// In local config:
cluster:
certificate-authority-data: ***
server: http://127.0.0.1:8765
name: karmada-apiserver
// In remote config:
cluster:
certificate-authority-data: ***
server: http://127.0.0.1:5252
name: kind-localcluster
*** LOCAL:
*** REMOTE:
*** LOCAL:
=> OK!
*** REMOTE:
=> OK!
*** LOCAL:
=> OK!
*** REMOTE:
In conclusion, it says that the cluster is not reachable, but I can access both clusters from each sides.
Is it a bug, or how can I solve this issue?
Thank you very much.
Environment:
kubectl karmada version
kubectl karmada version: version.Info{GitVersion:"v1.6.0", GitCommit:"6eb79b38949e480cf7a2e12cfa56fef47bda81ea", GitTreeState:"clean", BuildDate:"2023-06-02T08:04:58Z", GoVersion:"go1.20.4", Compiler:"gc", Platform:"linux/amd64"}
karmadactl version
karmadactl version: version.Info{GitVersion:"v1.6.0", GitCommit:"6eb79b38949e480cf7a2e12cfa56fef47bda81ea", GitTreeState:"clean", BuildDate:"2023-05-31T09:55:29Z", GoVersion:"go1.20.4", Compiler:"gc", Platform:"linux/amd64"}
kind version // The same in local and remote
kind v0.17.0 go1.19.2 linux/amd64
KIND CLUSTERS config file:
*kind-config.yaml:
$ kubectl version // (Local machine)
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"b46a3f887ca979b1a5d14fd39cb1af43e7e5d12d", GitTreeState:"clean", BuildDate:"2022-12-08T19:58:30Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.4", GitCommit:"f89670c3aa4059d6999cb42e23ccb4f0b9a03979", GitTreeState:"clean", BuildDate:"2023-05-17T00:01:22Z", GoVersion:"go1.19.8", Compiler:"gc", Platform:"linux/amd64"}
kubectl version // (Remote EC2)
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.3", GitCommit:"9e644106593f3f4aa98f8a84b23db5fa378900bd", GitTreeState:"clean", BuildDate:"2023-03-15T13:40:17Z", GoVersion:"go1.19.7", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.4", GitCommit:"872a965c6c6526caa949f0c6ac028ef7aff3fb78", GitTreeState:"clean", BuildDate:"2022-11-09T13:29:58Z", GoVersion:"go1.19.3", Compiler:"gc", Platform:"linux/amd64"}
The text was updated successfully, but these errors were encountered: