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
Note, there maybe no steps required here before going live as keto could just orchestrate new master / compute nodes.
This ticket is more an issue of:
handling upgrades in place without restarting rebuilding nodes
upgrading k8 objects
At the moment keto-k8 shares the manifests using etcd to provide "pre-self hosted" multi-master. At the moment, before self hosted clusters, we would need to introduce k8 version detection on master start (re-share using etcd). - Only some cluster unique pki resources are shared.
This will NOT upgrade essential deployments (proxy or dns) or node configuration which will come after this has been completed:
Steps required:
Detect k8 version change from cloud provider
Re-write the master manifests and re-share between the masters
Note, there maybe no steps required here before going live as keto could just orchestrate new master / compute nodes.
This ticket is more an issue of:
At the moment keto-k8 shares the manifests using etcd to provide "pre-self hosted" multi-master. At the moment, before self hosted clusters, we would need to introduce k8 version detection on master start (re-share using etcd).- Only some cluster unique pki resources are shared.This will NOT upgrade essential deployments (proxy or dns) or node configuration which will come after this has been completed:
Steps required:
and re-share between the masterskubeadm
when steps become idempotent, see Make all kubeadm post-install tasks idempotent kubernetes/kubeadm#288The text was updated successfully, but these errors were encountered: