Can't deploy calico-3.29.1 from China #9585
Comments
This doesn't look like an image pull issue to me. I think there might be something wrong with the certificates you've used when creating your cluster? |
|
My planned control plane cluster is based on a two master nodes k8s with keep alive and haproxy. I below is my first step to deploy the first control plane node. Then deploy calico with tigera-operator.yaml and custom-resources.yaml. I confirm that from China we can't access docker.io related resources. So my idea is to replace docker.io with quay.io in all calico related yaml configration files. I download calico-3.29.1 tar ball and deploy based on its manifest folder. So is there a clear instruction that which patterns should be replaced, if I want to change image pull address? I use "kubeadm init --apiserver-advertise-address=192.168.31.111 --control-plane-endpoint "192.168.31.250:6553" --image-repository registry.aliyuncs.com/google_containers --upload-certs --service-cidr=192.1.0.0/12 --pod-network-cidr=192.2.0.0/16 --cri-socket=unix:///var/run/containerd/containerd.sock" to create a the cluster on the first node. |
|
|
From above screen copy, you can say I even pull v3.29.1 related images to local and make tag to link as docker.io. But in my local calico related pods deployment, it just can't hook with these images. That's why I'm considering to replace "docker.io" with "quay.io" directly in calico-3.29.1/manifests for the related yaml files. Question is which files should be replace and which patters should? |
|
Does this doc on using a custom registry help at all? https://docs.tigera.io/calico/latest/operations/image-options/alternate-registry#concepts You will need to tell the Calico operator to use quay.io/ images instead of docker.io. You should just be able to replace all instances of |
|
Thanks for the document, I refer to your shared KB and I prepared all resources in local registry docker hub. And I can deploy tigera-operator.yaml and custom-resources.yaml. From output it looks all pods are running. But when I check "calico-node-xxxx" pod events and it gives warning: "Warning Unhealthy 62s (x3 over 80s) kubelet Readiness probe failed: calico/node is not ready: BIRD is not ready: Error querying BIRD: unable to connect to BIRDv4 socket: dial unix /var/run/calico/bird.ctl: connect: connection refused". When I use "calicoctl node status" and it shows "No IPv4 peers found". And actually I met similar issue when I tried a previous calico version based on release-v3.28.0. So somewhere in my local environment should be configured to fix the issue? [root@k8sma manifests]# kubectl get pods --all-namespaces kubectl describe pod calico-node-249wg -n calico-system ...... Normal Scheduled 93s default-scheduler Successfully assigned calico-system/calico-node-249wg to k8sma [root@k8sma manifests]# calicoctl node status IPv4 BGP status IPv6 BGP status |
This tends to suggest a problem with calico/node startup that is preventing BIRD from launching. What does |
|
Hello, the error likes below. And I tried to adjust calico plugin auto-detection with my ens.* network adapters, so I added below configurations in custom-resources.yaml. Then re-deploy calico plugin. But looks same error. |
|
|
Could you run this without the |
|
Already test at china network environment. worked as expected |
Here I download calico-3.29.1 to my first k8s master node. Use below command to setup first control plane node. And then use "kubectl create -f tigera-operator.yaml" and "kubectl create -f custom-resources.yaml"[cidr: 192.168.0.0/16 is adjusted to match k8s --pod-network-cid] to deploy calico. But it reports related pods are in "ContainerCreating" status but it keeps always. I think it's caused by "docker.io" is not accessible from China. So which files should I replace with the standby registry download site, such as from "quay.io". Actually I try pull related version images to local, but looks calico doesn't read it from local. So is there an official way to realize? I tried calico 3.28 and 3.29.1, both version failed in my side.
The text was updated successfully, but these errors were encountered: