Hi, Does anyone know where are the images stored in the node or cluster? In my windows node, I tried to find it by tying docker image ls or ctr image ls; none of them can find any; also in the Linux node, please? Because I tried to delete some images but in vain. Many thanks!
Thanks for your reply always. I saw some daemonset images in the Linux nodes but I canāt find any in the windows nodesā¦by trying both docker image ls or ctr image ls.
This is giving error:
Failed to auto detect backend type. IPIP is not supported on Windows nodes but found IP pools with IPIP enabled. Rerun
install script with the CalicoBackend param provided
At C:\k\install-calico-windows.ps1:179 char:16
ā¦ throw "Failed to auto detect backend type. IPIP is not su ā¦
CategoryInfo : OperationStopped: (Failed to auto ā¦ param provided:String) , RuntimeException
FullyQualifiedErrorId : Failed to auto detect backend type. IPIP is not supported on Windows nodes but found IP
pools with IPIP enabled. Rerun install script with the CalicoBackend param provided
Kindl provide complete latest steps for adding windows node to linux master node
Hi @Karthik_Medam, looks like the Windows node is having trouble contact the Kubernetes API server. Can you share some more details here (or perhaps in a GitHub issue)?
I think I am running into this same problem connecting a windows server 2022 Standard to a microk8s cluster running 1.27.2. I follow the steps outlined but when I query for nodes in the cluster after copying the kube config over and starting the kubelet service, but still no windows node. Is there any troubleshooting forum/slack/email that I can request help through?
I get an error trying to get logs from the pod running in the windows server node
PS C:\Windows\system32> kubectl logs test-pod
Error from server: Get āhttps://192.168.1.51:10250/containerLogs/default/test-pod/test-podā: tls: failed to verify certificate: x509: cannot validate certificate for 192.168.1.51 because it doesnāt contain any IP SANs
Hi @rafedecuba , Iāve found that on the new cluster version 1.28 and 1.29 kubelet on linux hosts (port 10250) has its IP address added to certificate subject alternative name, but that not happen on windows hosts, but i don\t know if it is the problem with microk8s or kubernetes itself. If you upgrade existing 1.27 cluster to 1.28, certificates that was generated without IP SANs in the previous version are used and it also does not check IP SANs and you can show logs from windows contianers, so there must be some internal check that is enabled only on new cluster.