我注意到 kubeadm升级计划和version skew support policy之间存在一些矛盾。
例如，我想将k8s集群从1.17升级到1.18。 因此我需要在一个控制平面节点上执行kubeadm升级计划，并且kubeadm将同时升级API Server，Controller Manager，Scheduler和其他组件。
但是根据policy，我应该首先将所有API服务器升级到1.18。
与这些组件通信的kube-apiserver实例位于 1.18（在这些控制平面组件可以与集群中的任何kube-apiserver实例进行通信的HA集群中，所有 在升级这些实例之前，必须先升级kube-apiserver实例 组件）
因此，kubeadm是按错误的顺序执行升级计划的，还是此顺序是政策和易用性（或实施问题）之间的折衷。
答案 0 :(得分：1)
在文档上方指定了
” kube-controller-manager，kube-scheduler和cloud-controller-manager不得比与其通信的kube-apiserver实例新。它们应与kube-apiserver次要版本匹配， ，但可能要早于一个次要版本（以便进行实时升级）。”
L.E .：哦，我知道了，问题在于，升级后的控制平面节点上的控制平面组件比尚未升级的节点上的kube-apiserver要新。我个人从未遇到过此问题，因为我始终将控制平面组件配置为连接到同一节点上的kube-apiserver。我猜这是您建议的kubeadm折衷方案。