Hey everyone, I'm currently trying to set up a VXLAN on my EKS cluster following the operator installation instructions from the Calico documentation. I've run through the steps to delete the existing AWS-node daemon set and create the necessary Calico resources, but I'm facing a couple of issues.
First, the Pods are being assigned IP addresses in the 172.x.x.x range. I thought Calico defaults to a 192.168.0.0/16 range according to the documentation, so I'm puzzled about why this is happening.
Secondly, I want to create a custom network with a CIDR of 10.100.0.0/16, and I've tried adding this to my installation spec, but it's not taking effect. It seems that Calico has a lot of different YAML references in their docs, and I'm not sure why only the quick start instructions are working for me. Can anyone help explain why I'm seeing those 172 addresses and how I can successfully set my desired CIDR?
2 Answers
You can solve your issue by updating your installation resource like this:
ipPools:
- name: default-ipv4-ippool
blockSize: 26
cidr: 10.100.0.0/16
encapsulation: VXLAN
natOutgoing: Enabled
nodeSelector: all()
As for the Pods getting 172 addresses, it's likely because without a defined IP pool, Calico defaults to that range for safety, even when you think it should be using 192.168.x.x. The current behavior can be a bit counterintuitive, and it might be worth submitting an issue on GitHub to clarify this point to the maintainers.
Just remember, always define your IP pools if you want specific ranges!
I totally feel your pain. I tried setting up a dual-stack cluster today with RKE2, and as soon as I deviated from the defaults, everything fell apart. The Tigera Operator couldn't reach the API server, and I ran into issues with calico-node being stuck. It feels like the docs are all over the place—lots of repetition but missing critical info. I had to give up before losing my mind!
I get that. The syntax for managing Calico isn’t just about changing the CIDR; you'll also need to tweak how services route traffic and consider the ingress settings. And yeah, using webhooks requires going with hostNetwork. It's not overly complex, but it adds layers you need to figure out. If you’re using EKS, I found this AWS-specific guide helpful: https://repost.aws/articles/ARL44xuau6TG2t-JoJ3mJ5Mw/unpacking-the-cluster-networking-for-amazon-eks-hybrid-nodes.
Thanks, that definitely works! I figured the 172.16 IP assignment happens because it uses the out-of-the-box internal network when no IP pool is declared explicitly. I'll stick with your suggestion since I need that /16 block size and can’t use the VPC network IPs.