在发布新版本时，建议升级kubernetes群集的方法是什么？
我听说here可能是https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-push.sh。如果是这种情况，kube-push.sh如何与https://github.com/GoogleCloudPlatform/kubernetes/blob/master/cluster/gce/upgrade.sh相关？
我还听说here我们应该创建一个新群集，将pod，复制控制器和服务从第一个群集复制/移动到新群集，然后关闭第一个群集
我在aws上运行我的集群，如果这是相关的。
答案 0 :(得分：9)
您引用的第二个脚本（gce / upgrade.sh）仅在您的群集在GCE上运行时才有效。还没有（还）AWS的等效脚本，但您可以查看脚本并按照步骤（或将它们写入脚本）来获得相同的行为。
upgrade.sh和kube-push.sh之间的主要区别在于前者执行替换升级（删除节点，创建新节点以替换它），而后者执行＆＃34;就位＃34 ;升级。
删除和替换主节点仅在持久数据（etcd数据库，服务器证书，授权承载令牌等）驻留在与主服务器的引导磁盘分开的永久磁盘上时才有效（默认情况下，这是如何配置的）在GCE）。在AWS上删除和替换节点应该没问题（但请记住，任何不在复制控制器下的pod都不会重新启动）。
进行就地升级并不需要任何特殊配置，但该代码路径不像删除和替换选项那样经过全面测试。
升级到新版本时，您不需要完全替换群集，除非您使用的是预发布版本（例如alpha或beta版本），它们之间有时会发生重大变化。