当Kubernetes API资源的存储版本发生变化时，是否仍然需要按照描述here来手动读写资源，或者apiserver现在是否可以自动进行处理？
例如，如果我想从群集中删除deprecated extensions/v1beta1版的部署并迁移到apps/v1，那么在apiserver上指定--storage-versions=extensions=apps/v1就足够了然后“等待一点”，然后再设置类似---runtime-config=api/all=true,extensions/v1beta1/deployments=false的内容？还是在设置--storage-versions=extensions=apps/v1之后必须使用update-storage-objects.sh脚本？
另外，如果指定--storage-versions=extensions=apps/v1会导致仍使用API版本extensions/v1beta1但未转换为apps/v1的入口资源引起任何问题？
答案 0 :(得分：0)
apiserver现在会自动处理吗？
否，api服务器不会自动执行此操作，您需要手动执行。
关于API版本之间的升级，所有必要步骤均在官方文档中进行了描述：
这是很少见的事件，但是需要仔细的管理。有
是升级到新API版本的一系列步骤。
打开新的API版本。
升级群集的存储以使用新版本。
升级所有配置文件。确定旧API版本端点的用户。
通过运行
cluster/update-storage-objects.sh将存储中的现有对象更新为新版本。关闭旧的API版本。
第4步不仅涉及存储，还涉及与集群中拥有的旧版本相关的所有资源。
另外，如果指定--storage-versions = extensions = apps / v1会导致仍使用API版本扩展/ v1beta1但无法转换为apps / v1的入口资源出现任何问题？
每种资源的版本化都是独立的。存储和入口是不同的资源，因此它们的版本之间没有关系，并且不同的版本不应以任何方式影响它们。
答案 1 :(得分：0)
推荐的方法仍然在不断变化。当前禁止删除API版本：https://github.com/kubernetes/kubernetes/issues/52185
答案 2 :(得分：-1)
我通常使用新的API版本升级群集，然后升级配置文件，但不删除旧的API。仅由于一次错误，我不得不删除旧的API版本。您可以通过运行kubectl get apiservice列出所有可用版本，然后kubectl delete apiservice some_api来做到这一点，而不必设置任何其他标志。