You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently EIB deploys Edge components and user workloads using the same approach, creating addon files for RKE2 on the /var/lib/rancher/rke2/server/manifests/.
This means that the files are the source of truth, not the k8s object itself and in the event of a modification is required (either a upgrade or a parameter tweak), the change needs to be done on the files themselves... and in HA scenarios, keep them synced (EIB currently creates the manifest files on the initializer node only).
For Edge workloads we will manage this by the upgrade mechanism somehow but for user workloads they need to be aware of this or maybe we can just deploy the thing and then use the .skip mechanism to let the users treat them as k8s objects.
The text was updated successfully, but these errors were encountered:
Currently EIB deploys Edge components and user workloads using the same approach, creating addon files for RKE2 on the /var/lib/rancher/rke2/server/manifests/.
This means that the files are the source of truth, not the k8s object itself and in the event of a modification is required (either a upgrade or a parameter tweak), the change needs to be done on the files themselves... and in HA scenarios, keep them synced (EIB currently creates the manifest files on the initializer node only).
For Edge workloads we will manage this by the upgrade mechanism somehow but for user workloads they need to be aware of this or maybe we can just deploy the thing and then use the .skip mechanism to let the users treat them as k8s objects.
The text was updated successfully, but these errors were encountered: