etcd 3.4计划于2019年6月底发布。它包括对Kubernetes的API的新增内容，只有当kube-apiserver知道它正在向etcd 3.4+集群发出请求时，Kubernetes才能利用这些新增内容。
kube-apiserver的--storage-backend标志可用于设置etcd的主要版本("etcd3")。是否可以引入此标志的次要版本选项，例如"etcd3.4"?
另一种选择是让kube-apiserver在开始确定"集群版本"时向etcd发出请求，然后根据该信息启用功能。
我们可能会利用的功能示例：etcd-io/etcd#9869
cc @wojtek-t
5条答案
按热度按时间jtoj6r0c1#
/sig api-machinery
sg3maiej2#
看起来获取"集群版本"更加灵活：与用户输入相比，etcd集群返回的版本更可信。
h43kikqp3#
看起来获取"集群版本"更加灵活：与用户输入相比，etcd集群返回的版本更可信。
+1
我认为我们应该使其动态化，而不是为该标志引入一个新值，因为这意味着许多不同的提供者必须开始以不同的方式设置它。
此外，依赖于etcd的请求使得我们可以实现动态(例如，如果在那一刻没有发生变化，我们可以每隔一分钟检查一次)。
oxcyiej74#
问题在90天不活跃后过期。
使用
/remove-lifecycle stale将问题标记为新鲜。过期的问题在30天不活跃后开始腐烂并最终关闭。
如果现在可以安全地关闭此问题，请使用
/close进行操作。向 sig-testing, kubernetes/test-infra 和/或 fejta 发送反馈。
生命周期：过期
z8dt9xmd5#