使用kubernetes进行dockerizing+集群可以提供许多好处，比如自动修复、自动水平缩放。
自动修复：在spring应用程序崩溃的情况下，kubernetes将自动运行另一个示例，并确保所需数量的容器始终处于运行状态。
自动水平伸缩：如果你收到大量的消息，你可以调整spring应用程序，使用hpa自动上下伸缩，hpa也可以使用定制的度量。

对我来说，docker和non docker的区别归结为“你的运营团队或组织支持什么？”
停靠的应用程序有一个优点，它们的外观/行为都相同：您 docker run 和你一样的java应用程序 docker run 一个ruby应用程序。其中，与使用systemd运行程序的方法一样，通常没有围绕“如何运行这个东西”的通用抽象层
停靠的应用程序也可能抽象出一些小的操作细节，例如端口管理——即确保所有应用程序 management.port 我们不要互相冲突。docker容器中的应用程序将作为容器中的一个端口运行，您可以 expose 那个端口和外面的其他号码一样(或者是随机的，或者是你自己选择的）。
根据基础设施的支持，正常的docker调度器可能会在服务达到一定容量时自动扩展服务。但是，在kafka streams应用程序中，并发性受到kafka主题中分区数量的限制，因此扩展只会意味着用户组中的一些用户处于空闲状态（如果分区的数量超过了分区的数量）。
但这也增加了复杂性：如果您使用rocksdb作为本地存储，您可能希望将其保留在外部（一次性的，可能是只读的！）容器。因此，您需要弄清楚如何在操作/组织上实现卷持久性。用普通的jar和系统。。。嗯，你总是有硬盘驱动器，如果服务器崩溃，要么它会重新启动（物理机），要么希望它能被某个示例块存储恢复。
我的意思是说：kstream应用程序不是无状态的，web应用程序的自动伸缩总是会给你一些更强大的功能，而且它服务于http流量。在组织或运营层面上做出这些决策的人可能并不完全了解这一点。再说一次，如果每个人都写docker的东西，那么组织/运营团队“只”有一些docker调度器集群（比如kubernetes集群或amazonecs集群）需要管理，而不必再直接管理vm了。