Init BUG

[IonBoleac]

What happened: When i start the init function to install the karmada's control plane all go write until he have to create the karmada-aggregated-apiserver.

The first line of the init command:

$ sudo kubectl karmada init --kubeconfig config
I1003 08:48:46.136781   52088 deploy.go:255] kubeconfig file: config, kubernetes: https://192.168.56.104:16443
W1003 08:48:46.208630   52088 node.go:52] The kubernetes cluster does not have a Master role.
I1003 08:48:46.208698   52088 node.go:60] Randomly select 3 Node IPs in the kubernetes cluster.
I1003 08:48:46.219448   52088 deploy.go:275] karmada apiserver ip: [10.0.2.15]
I1003 08:48:46.918412   52088 cert.go:247] Generate ca certificate success.

The karmada-aggregated-apiserver pod's log:

I1003 08:51:10.679776       1 options.go:112] karmada-aggregated-apiserver version: version.Info{GitVersion:"v1.11.1", GitCommit:"5efee1388a2f3d75bc4590348b776587e76e3527", GitTreeState:"clean", BuildDate:"2024-09-14T09:57:07Z", GoVersion:"go1.22.7", Compiler:"gc", Platform:"linux/amd64"}
E1003 08:51:11.201568       1 run.go:74] "command failed" err="unable to load configmap based request-header-client-ca-file: Get \"https://karmada-apiserver.karmada-system.svc.cluster.local:5443/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication\": dial tcp 127.0.0.1:5443: connect: connection refused"

What you expected to happen: Run the Karmada's control plane on the cluster

How to reproduce it (as minimally and precisely as possible): Run the command kubectl karmada init on the kubeconfig file:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: ***
    server: https://192.168.56.104:16443
  name: microk8s-cluster
contexts:
- context:
    cluster: microk8s-cluster
    user: admin
  name: microk8s
current-context: microk8s
kind: Config
preferences: {}
users:
- name: admin
  user:
    client-certificate-data: ***
    client-key-data: ***

Anything else we need to know?: I run the cluster with microk8s tool on a VM VirtualBox with ubuntu server. The VM use a only-host device network to interact with other VM and the host OS. In addition there is a Nat device network to enable the VM connect the internet.

Furthermore, I use a Kind cluster on Docker and have the same problem. In this case, the IP of the Armada API server is set to 172.0.18.3. Why did this happen?

$ sudo kubectl karmada init --kubeconfig liqo_kubeconf_florence
I1004 14:10:58.952504  441135 deploy.go:250] kubeconfig file: liqo_kubeconf_florence, kubernetes: https://127.0.0.1:33831
I1004 14:10:58.997934  441135 deploy.go:270] karmada apiserver ip: [172.18.0.3]
I1004 14:10:59.540915  441135 cert.go:246] Generate ca certificate success.
I1004 14:11:00.710949  441135 cert.go:246] Generate karmada certificate success.
I1004 14:11:01.231020  441135 cert.go:246] Generate apiserver certificate success.
I1004 14:11:01.767231  441135 cert.go:246] Generate front-proxy-ca certificate success.
I1004 14:11:02.490846  441135 cert.go:246] Generate front-proxy-client certificate success.
I1004 14:11:03.092517  441135 cert.go:246] Generate etcd-ca certificate success.
I1004 14:11:03.662452  441135 cert.go:246] Generate etcd-server certificate success.
I1004 14:11:04.161650  441135 cert.go:246] Generate etcd-client certificate success.
I1004 14:11:04.161923  441135 deploy.go:366] download crds file:https://github.com/karmada-io/karmada/releases/download/v1.10.2/crds.tar.gz
Downloading...[ 100.00% ]
Download complete.
I1004 14:11:04.946115  441135 deploy.go:608] Create karmada kubeconfig success.
I1004 14:11:04.970539  441135 idempotency.go:267] Namespace karmada-system has been created or updated.
I1004 14:11:05.024231  441135 idempotency.go:291] Service karmada-system/etcd has been created or updated.
I1004 14:11:05.024298  441135 deploy.go:432] Create etcd StatefulSets
I1004 14:11:08.043761  441135 deploy.go:441] Create karmada ApiServer Deployment
I1004 14:11:08.065656  441135 idempotency.go:291] Service karmada-system/karmada-apiserver has been created or updated.
I1004 14:11:37.875666  441135 deploy.go:453] Create karmada aggregated apiserver Deployment
I1004 14:11:37.904226  441135 idempotency.go:291] Service karmada-system/karmada-aggregated-apiserver has been created or updated.
F1004 14:12:09.727513  441135 deploy.go:74] unable to create Namespace: Post "https://172.18.0.3:32443/api/v1/namespaces": dial tcp 172.18.0.3:32443: i/o timeout

How can i resolve this problem? Is there some problem with the apiserver configuration? Can I custom the IP address that is assigned?

Environment:

• Karmada version: latest
• kubectl-karmada or karmadactl version (the result of kubectl-karmada version or karmadactl version): latest

[deitch]

Ah, I have been looking for this. I just came across the same issue.

The 172.18.0.3 is the IP address of the Kubernetes cluster from inside the docker environment.

From my desktop running docker:

$ ping 172.18.0.3
PING 172.18.0.3 (172.18.0.3): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- 172.18.0.3 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

My kubeconfig:

clusters:
- cluster:
    certificate-authority-data: 
****
    server: https://0.0.0.0:64495
  name: k3d-karmada-ctl

Looking at my k3d cluster:

$ kubectl get node -owide
NAME                       STATUS   ROLES                  AGE   VERSION        INTERNAL-IP   EXTERNAL-IP   OS-IMAGE   KERNEL-VERSION    CONTAINER-RUNTIME
k3d-karmada-ctl-server-0   Ready    control-plane,master   41m   v1.27.5+k3s1   172.18.0.3    <none>        K3s dev    6.10.4-linuxkit   containerd://1.7.3-k3s1

And from within a pod on the cluster:

/ # ping 172.18.0.3
PING 172.18.0.3 (172.18.0.3): 56 data bytes
64 bytes from 172.18.0.3: seq=0 ttl=64 time=2.190 ms
64 bytes from 172.18.0.3: seq=1 ttl=64 time=0.488 ms
^C
--- 172.18.0.3 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.488/1.339/2.190 ms

/ # curl -k https://172.18.0.3:32443/api/v1/namespaces
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "namespaces is forbidden: User \"system:anonymous\" cannot list resource \"namespaces\" in API group \"\" at the cluster scope",
  "reason": "Forbidden",
  "details": {
    "kind": "namespaces"
  },
  "code": 403
}

It looks like karmada (in my case, kubectl karmada init) client-side is reading the internal IP of the cluster as it sees itself and trying to reach it that way, rather than whatever is in the kubeconfig.

Can anyone from the karmada team confirm or reject this?