Hello! How difficult would it be change the pods' ...
# general
p
Hello! How difficult would it be change the pods' and services' subnets on RKE2 rancher?
h
not supported to change these post cluster creation
if you're creating a new cluster then add these two in config.yaml cluster-cidr: "your_prefered_IP_Subnet/16" service-cidr: "your_prefered_IP_Subnet/16"
p
Thanks. I guess I could create a new cluster with the new subnets and move the nodes one by one.
I've come across information where people claim have done it. Does 'not supported' just means that Rancher doesn't officially support it? Or that it's not doable at least in a reasonable way?
h
github.com/rancher/rke2/issues/2326 I am sure there are people that have done it - and could be successfully.. this is ultimately your decision ; especially if this is your production - mission critical environment and if you want to take that chance even so, I would probably spin up a new environment and experiment there before trying in prod
p
Yeah, testing it before goes without saying, of course.
I'll see what my options are, but thanks for the answer.
m
If you are addressing IP exhaustion... I know Amazon created a "work around" to deal with IP exhaustion (not sure if that is what you are solving for) aws.amazon.com/blogs/containers/addressing-ipv4-address-exhaustion-in-amazon-eks-clusters-using-private-nat-gateways I recalled that Cilium also had shared they had a solution - which is not EKS-specific isovalent.com/blog/post/overcoming-kubernetes-ip-address-exhaustion-with-cilium I think, generally, the advice is to deploy a new cluster and migrate stateful data.
p
No, it's about subnet overlapping.
πŸ‘ 1
m
that ^^^ was always a struggle, especially in the early days - I'd be talking with customers about the infra requirements and inevitably the CIDR for Pod/Security/Machines would come up and either the systems team, or the infra team would ask: what on earth do you need a /16 for (I was at Red Hat back then)
and when I would unpack what the networks were for, etc.. it became more clear - but also uncovered the potential for subnet overlap with their enterprise subnets that were internal/non-routable. Good times!
p
πŸ™‚ In my case the IT departament just chose the wrong subnet, because... well... this is what they are like. They generally manage the network, so they don't have much of an excuse. Anyway, in the meantime they said that they would change the subnet on the other end, so I won't be needing to change the subnet on the kubernetes cluster anymore. So I guess that's fine, although the process would have interested me – I would have liked to see if I could do it without having to set up a new cluster, even if it were offline.
But I'll probably start focussing on ther stuff.
m
sounds fortunate they were able to change on their side this time - and now they have an idea of how to collab to avoid in the future! πŸ˜‰
I chalk that one up as a win!
p
Yeah. Well, actually they were mostly responsible for this. But yeah πŸ™‚