This message was deleted.
# rke2
a
This message was deleted.
c
RKE2 and K3s do not use any of the ssh/docker stuff that RKE1 does. Basically all it does it create an instance on the cloud provider, passing through cloud-init data that runs an install script to pull things down from Rancher.
If your node driver doesn’t support pass-through of cloud-init userdata, it won’t work.
g
Are there any references or direction you can point me in to support this? Im new to RKE2 and want to build upon the current node driver and support RKE2.
I appreicate your reply
c
What do you mean “to support this”? It is what it does. You could look at the built-in node drivers if you need a reference point.
This isn’t so much an RKE2 thing as it is a rancher thing and I only work on K3s and RKE2.
Long term Rancher will deprecate the node drivers in favor of capi machine providers, but this is a ways out as the current capi machine providers make a LOT of assumptions, for example the EC2 capi provider assumes you’re using EKS and are going to set everything up for that. Same with CAPA and CAPG for Azure and Google.
👍 1
https://github.com/rancher/machine/commit/d312d3d97950546856eaeb2c8434883152db5362 for the change that added support for custom install script, which is what RKE2 and K3s (v2prov in Rancher-speak) rely on.
g
Thanks for that, Brandon. i will look into the built-in providers to see how they are handling RKE2 with node drivers..Moving forward, what is the best way for infrastructure providers to offer RKE2 via Rancher? Do providers need to create a built-in solution in Rancher? Thanks for your explanation
c
Right now the answer is still node driver with cloud-init userdata support, but be looking at CAPI.