在发布新版本时,建议升级kubernetes集群的方法是什么?
我在这里听到它可能是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相关?
我在这里也听说过,我们应该创建一个新的集群,将pod,复制控制器和服务从第一个集群复制/移动到新集群,然后关闭第一个集群.
如果相关,我在aws上运行我的集群.
您引用的第二个脚本(gce/upgrade.sh)仅在您的群集在GCE上运行时才有效.还没有(还)AWS的等效脚本,但是您可以查看脚本并按照步骤(或将它们写入脚本)来获得相同的行为.
upgrade.sh和kube-push.sh之间的主要区别在于前者执行替换升级(删除节点,创建新节点以替换它),而后者执行"就地"升级.
删除和替换主节点仅在持久数据(etcd数据库,服务器证书,授权承载令牌等)驻留在与主控制器的引导磁盘不同的永久磁盘上时才有效(这是默认情况下在GCE中配置的方式) .在AWS上删除和替换节点应该没问题(但请记住,任何不在复制控制器下的pod都不会重新启动).
执行就地升级不需要任何特殊配置,但该代码路径没有像删除和替换选项那样经过全面测试.
升级到新版本时,您不需要完全替换群集,除非您使用的是预发布版本(例如alpha或beta版本),它们之间有时会发生重大变化.
| 归档时间: |
|
| 查看次数: |
3342 次 |
| 最近记录: |