我一直在倾听Kubernetes（k8s）各种讨论，并试图找出反复出现的主题，这些主题是关于它是一个“好”还是“坏”想法的辩论。
Kubernetes是构建系统的“通用语言”和“声明性”（而不是命令式）方式。
架构师
Kubernetes的企业/架构师视图是跨多个云的通用标准，加上私有数据中心，意味着Kubernetes“很好”。我在理论上同意。
这种观点是因为“通用”是一个好的信念
这有时是真的。然而（在我看来）实际实现这一目标所需的努力规模，特别是在多个云中，就像是说核聚变是清洁能源的最佳来源。我在理论上同意。但我不认为有人建造了一个能够可靠且持续产生更多功率的反应堆。
开发者
开发团队的观点以两种信念为特征。
我与之交谈的一组人认为，拥有一个通用，可靠的平台来部署软件是“好”的。他们没有错。他们看到了潜力，而且很诱人。但是这个“阳”有一个“阴”。
另一种信念，也许是那些必须处理生产问题的人（特别是他们自己制造的，没有其他人可以责备的人）认为简单是可行性的主要指示。引用Baz Luhrman的话：
你生活中真正的麻烦往往是那些从未超越你忧心忡忡的事物; 在星期二的某个空闲时间下午4点让你失明的那种。
这很接近我自己的直觉：这种并发症本质上是一种杀手 - 本身就是你成功机会的指数风险。从这个角度来看，k8s是“糟糕的”，因为复杂性会吸收超过你所有的能量。除非你拥有雄厚的资金和专门的平台团队，否则在提供有意义的价值之前，时间，预算和利益相关者的耐心都将耗尽。
运营团队
我觉得运维视图可能是最基础的。毕竟，这些人往往是在愚蠢的时候，处理架构和交付团队在高级利益相关者的压力下急于求成，将压力延迟到运营中。
在这种情况下，保持工作负载与基础架构的健康分离的通用平台“很好”，因为它可以更清晰地分离根本原因并有助于防止推迟。标准化我们打包，运行和监控工作负载的方式可以减轻痛苦。与此同时，人们已经认识到复杂的系统是“糟糕的”：它们是一个经常性的噩梦，继续前进，并且批判性地创造了模糊的，多层次的不明智的巢穴，可以在不确定的时期内轻松掩盖雷鸣般的安全风险。
集群正在运行时，感觉就像魔术一样
当集群没有按预期运行时，问题是可理解性。复杂，冗长，交错的yaml，有各种陷阱，当然它是声明性的，但感觉像一个谜，具体怎么执行无法知晓。
集成
很明显，Kubernetes 很大。它既复杂又复杂。这是每个人都同意的一件事。如果您的团队能够理解并管理它，那么它可能会对您“好”。
如果你有一个由十几个人组成的全职平台团队致力于运行Kubernetes你会做得很好。但事情就是这样：运行通用平台和服务不会增加任何特定价值。这是一种外部性，因此最终将被外部化。我们知道这一点，因为这正是云计算是：外部化运行可靠，容错的通用基础设施的难题。
消失
建设基础设施太难，太慢，太复杂。受到办公室和数据中心空间基本物理学的限制，以及购买，货架，网络和趋向机器的机制，同时优雅地处理故障。
这就是我认为Kubernetes会消失的原因。它是如此通用，没有理由自己做。
商品
最后，正是因为它是通用的，并且因为运行部署平台是一个无差别的难题，它可以并且将会商品化。Fargate和Cloud Run（Knative）已经开始沿着这条道路前进。如果你还记得Maven为Java世界所做的事情，你就会明白接受一点点意见会带来很多生产力。
总会有例外情况，但我认为他们将证明这一规则：如果Kubernetes能够成功征服主流，那么对于大多数软件交付组织来说，它只是一个可以购买的商品，不值得自己做。