calicoctl | This repository is the home of calicoctl | Continuous Deployment library

While the official documentation claims:

1. Calico looks for the config in the default user location ~/.kube/config
2. It will also look at KUBERNETES_MASTER (the error output states this)
3. It will also look at KUBECONFIG

It does NOT! None of the above works on Windows. (On Ubuntu, I did not have to do anything special and it found my config)

The only solution I found was to do the following:

1. Create a config file
2. Pass the config file in every calicoctl call

calico.cfg.yaml

I had been playing around with multiple config files. Whereas kubectl will recognize multiple config files for testing purposes, calicoctl will not. I merged my config files using instructions found here:

How to merge kubectl config file with ~/.kube/config?

Fixed!

As nodes had different network interfaces, calico-node autodetected different networks on nodes. To fix this I added IP_AUTODETECTION_METHOD env var to calico-node DaemonSet. In my case I used these env var values:

The calico file default disable ipip and vxlan, which causes the network failure. When I enable ipip and set the correct veth_mtu everything works well.

I have solved this by updating all the masters at the same time, without validation

Looks like you have an RBAC issue where your pod cannot read the Kubernetes the IPAMConfig CRD.

I looked at the manifests from https://docs.projectcalico.org/manifests/canal.yaml and I see that it's missing ipamconfigs from a couple of the RBAC ClusterRoles. So you can go ahead and try to add them.

The question is: why the master 192.168.31.29 calico nodes are not found?

Sounds like Calico wasn't able to retrieve your NODENAME for the master. I see that it's defined as localhost.localdomain in the output of your command.

If you see the docs, Calico needs to be able to determine your NODENAME to add the calico/node resource and consider it to be part of the 'mesh'.

The calico/node must know the name of the node on which it is running. The node name is used to retrieve the Node resource configured for this node if it exists, or to create a new node resource representing the node if it does not. It is also used to associate the node with per-node BGP configuration, felix configuration, and endpoints.

Another question would be, are you planning to run workloads on your Kubernetes master? If you don't then your setup is fine now. If you do, then yes, you will have to make sure that Calico (the overlay) works so that your workloads have network connectivity.

Changing a cluster CIDR isn't a simple task. I managed to reproduce your scenario and I managed to change it using the following steps.

Changing an IP pool

The process is as follows :

1. Install calicoctl as a Kubernetes pod (Source)
2. Add a new IP pool (Source).
3. Disable the old IP pool. This prevents new IPAM allocations from the old IP pool without affecting the networking of existing workloads.
4. Change nodes podCIDR parameter (Source)
5. Change --cluster-cidr on kube-controller-manager.yaml on master node. (Credits to OP on that)
6. Recreate all existing workloads that were assigned an address from the old IP pool.
7. Remove the old IP pool.

Let’s get started.

In this example, we are going to replace 192.168.0.0/16 to 10.0.0.0/8.

1. Installing calicoctl as a Kubernetes pod