我已经和许多不同人进行了不同形式的对话，到目前为止，我们一直在努力使服务器端应用相同的命令，但这两种方法都有优点和缺点。我想对此进行更正式的讨论。
我将尝试中立地描述这个问题，但我认为我倾向于拥有一个单独的命令。
为什么我们应该有一个新的kubectl命令：
- 我们不太可能破坏任何人的工作流程（标志不能按预期工作，以前用于
kubectl apply的某些功能不再工作），我们已经有了一些这样的功能，可能还有很多我们没有看到： --force标志不适用于服务器端应用- 缺少的协议在部署端口上不起作用。
- 冲突将开始导致以前不会出现的故障
- 我们不支持应用API服务
- 这些标志有点混乱，因为一些标志明显适用于客户端，而另一些标志明显适用于服务器端，这是一般工程师的渎职行为，将这两件事混为一谈（
--overwrite，客户端模拟运行，--openapi-patch，--validate）。 - 由于上面的两点，我们失去了做出我们想要做出的改变的自由，因为我们必须保持兼容性（C++综合症）。
- 从根本上说，抽象在很坏的方面存在漏洞。
另一方面，重复使用相同的名称是很好的，因为：
- 显然，没有比
apply更好的命令名称了，因此我们不得不使用一个不太好的名称 - 如果我们想要重新声明
apply名称，我们需要一个长期的计划来弃用现有的apply并最终重命名 - 人们会立即开始使用它。新命令的风险在于人们从未开始使用它，或者不知道它的存在
7条答案
按热度按时间zsbz8rwp1#
抄送：kubernetes/sig-cli-维护者
/wg api表达式
/签名客户端
/签名api-机械
2mbi3lxu2#
缺少的协议在部署端口上不起作用
我们很快就能解决这个问题，不是吗？在移交指挥权之前？
冲突将开始导致以前不会出现的故障
我觉得这是一件好事，它没有做用户认为它是以前。
--force标志不适用于服务器端应用应该删除/重命名
--force标志。（但是没有理由它不能用于SSA，只需删除，然后执行应用操作。）这些标志有点混乱，因为一些标志明显适用于客户端，而另一些标志明显适用于服务器端，这是一般工程师的渎职行为，将这两件事混为一谈。
一个标志列表有助于评估情况有多糟糕;这句话同样适用于严重性差别很大的问题：）
由于上面的两点，我们失去了做出我们想要做出的改变的自由，因为我们必须保持兼容性（C++综合症）。
我们可以让现有用户崩溃一次，也可以让未来用户的生活变得悲惨。
如果我们做了一个突破，我认为总的来说是净好的。如果我们一直做突破，总的来说肯定是净坏的。
ujv3wf0j3#
我个人对改变apply的行为持谨慎态度，即使我们认为新的行为更好。
如果我们要这样做，我想一个不同行为的列表（包括证明改变是正确的好行为）会很有帮助。
例如，我相信当我们从源yaml中删除一个字段并重新应用时，会有不同的行为。
mzsu5hc04#
@迈克·斯普雷策
olmpazwi5#
/抄送：利Git珍妮巴克利
qyyhg6bp6#
/生命周期冻结
o8x7eapl7#
我相信这方面的利益相关者是@kubernetes/sig-cli-maintainers。例如@seans3，@pwittrock，@soltysh，你们中的一个能参与进来吗？
我想尽快弄清楚。
我个人认为，不要给用户提供过多的应用选择是非常重要的，这会让人非常困惑。
如果我们要这样做，我想一个不同行为的列表（包括证明改变是正确的好行为）会很有帮助。
我同意。
例如，我相信当我们从源yaml中删除一个字段并重新应用时，会有不同的行为。
这里有几个不同之处，一个是IMO是一个bug，我们不能在不修复它的情况下默认运行，另一个是阿威，修复CSA bug。