https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# rke2
a
This message was deleted.
b
I'm a little confused by one thing you mention: You said "onprem bare metal" but then mention vCPU. Are these VMs, or are you actually running on bare metal?
As for the control plane vs worker nodes... There's nothing stopping you from using a CP node as a worker node. (outside of resources). RKE2 uses a lot more resources to run a cluster, so the required footprint is a lot higher. If you want to use nodes that are running both the CP and workloads, I'd suggest looking into #CGGQEHPPW as it's built a lot better for that type of design imho.
You still need to specify which boxes are the CP nodes and you need an odd amount of them. (3-5-7) but honestly there will be some diminishing returns when it comes to adding more resiliency (nodes) vs overhead.
imho, unless you have a really good reason to need 5 nodes for prod, just stick to 3. Good reasons might be something like you have 5 racks and want a node in each rack. But if you have single points of failure in your data center, 3 is likely going to be fine.
I'm gonna assume that these are VMs and not actual bare metal boxes because of the vCPU thing..... Your 4 UAT nodes are more closely sized to dedicated ControlPlane nodes. What I would do is lower the specs on those VMs and create more of them. Probably shoot for 32GB of Ram and 16 cores (you only need enough disk for the OS and some extra space so probably like 120 GiB). Use 3 for the control plane for each cluster. Use 1 of your 8 big nodes for the UAT cluster. You won't have HA, but it won't matter because it's just testing. Throw your other 7 nodes into prod with the smaller VM control plane nodes. This also gives you a setup where testing more closely matches prod and avoids anti-patterns.
Alternatively You could make 3 medium sized nodes for the UAT workers with a 1/2 the resources of your big prod nodes so any HA deployments (db clusters etc) would have room to spread out. That's probably a better idea, but I don't know what constraints you have around resource provisioning.
f
Thank you @bland-article-62755. Sorry for the confusion. I am not sure how best to word the statements. These are physical servers racked up someone in another country. I am not sure exactly how that is done in the datacenter except for the fact that I am provided VPN (app gate) and ssh access to these servers. Those servers have been created and cannot be increased or decreased as per business dealings Besides, the production approval is pending until UAT setup is complete and application start running on it. So I can only work on 4 servers at the moment. I thought about applying tolerations to nodes running CP and etcd but that will leave me with just one node for application pods which might not be sufficient for a couple of microservices.
b
In that case I'd set them up as #CGGQEHPPW nodes and let them rip. Plenty of people do that in prod. Btw, not always but generally etcd always run on the cp nodes.
f
Thanks. So if I get your point, I can safely: Install K3s instead of RKE2 Use all 4 nodes as control-plane + worker combined nodes Let Kubernetes schedule both system components and apps on the same servers this way I avoid “dedicated control planes only”
b
Do 3 nodes as control-plane + worker combined nodes. and the others as just worker nodes.
But otherwise, yep.
f
Thanks. Make sense. I was overly concerned about separating workloads from CP but the quorum calculations just made little sense to me.
b
You just need to be able to keep etcd running somewhere.
What are the chances you'd lose 1/2 the nodes and those 4 are all the etcd ones?
low probably.
Just spread them out between the racks (if they tell you they're running in different places)
👍 1
f
Yea. That's very low. Well that provides HA in addition. Make sense to me.
4 Views
Open in Slack
PreviousNext
Powered by