主要差异在哪里？
Kubernetes几乎是从一个干净的平板开发的，用于扩展Docker容器内核以成为一个平台。 Kubernetes开发采用自下而上的方法。它在指定每个容器/ pod资源需求方面具有良好的优化，但缺少可以将资源划分为逻辑分组的有效全局调度程序。 Kubernetes设计允许多个调度程序在集群中运行。每个调度程序管理其自己的pod中的资源。但是，当应用程序需要比物理系统可处理的更多资源时，Kubernetes集群可能会受到不稳定性的影响。它在超出应用程序需求的基础架构容量方面效Kubernetes调度程序将尝试使用传入的应用程序请求填充空闲节点，并终止低优先级和饥饿容器以提高资源利用率。 Kubernetes容器可以与S3等外部存储系统集成，以提供数据弹性。 Kubernetes框架使用etcd来存储集群数据。 Etcd集群节点和Hadoop Namenode都是Kubernetes或Hadoop平台中的单点故障。 Etcd可以拥有比Namenode更多的复制品，因此，从可靠性的角度来看似乎有利于Kubernetes的理论。但是，Kubernetes安全性是默认打开的，除非RBAC定义为细粒度的角色绑定。已为pod正确设置安全上下文。如果省略，则pod的主要组将默认为root，这对于尝试保护基础结构的系统管理员来说可能会有问题。
Apache Hadoop YARN的开发是为了运行孤立的Java进程来处理大数据工作负载，然后进行改进以支持Docker容器。 YARN提供全局级资源管理，如容量队列，用于将物理资源划分为逻辑单元。可以为每个业务单位分配群集资源的百分比。容量资源共享系统的设计有利于企业优先级的保证资源可用性，而不是压缩每个可用的物理资源。 YARN确实在安全方面得分更高。 Kerberos中有更多安全特性，特权/非特权容器的访问控制，可信的docker镜像和放置策略约束。大多数与docker相关的安全性默认为关闭，系统管理员需要手动打开标志以向容器授予更多权力。大型企业倾向于运行Hadoop而不是Kubernetes，因为确保系统成本更低。在YARN之上构建了更多分布式SQL引擎，包括Hive，Impala，SparkSQL和IBM BigSQL。数据库选项使YARN成为一种吸引人的选择，因为它能够在容器中运行在线事务处理，并使用批处理工作负载进行在线分析处理。 Hadoop开发人员工具链可能令人难以招架。 Mapreduce，Hive，Pig，Spark等都有自己的开发风格。用户体验不一致，需要一段时间才能全面学习。相比之下，Kubernetes感觉阻力较小，因为它只部署了泊坞容器。通过引入YARN服务来运行Docker容器工作负载，YARN可以感觉不像Kubernetes那么冗长。
如果您的计划是将IT运营部署到公共云，请选择Kubernetes。如果您的计划是构建私有/混合/多云，请选择Apache YARN。
虽然this question and answer并不是你所要求的，但它确实触及了许多相同的观点。
最后我看到，Yarn只是一种资源共享机制，而Kubernetes是一个完整的平台，包括ConfigMaps，声明性环境管理，秘密管理，Volume Mounts，一个超级精心设计的API，用于与所有这些事物进行交互，基于角色的访问控制，和Kubernetes广泛使用，这意味着可以很容易地找到雇用的候选人和购买工具。
我发现blog post引用了一个master's thesis，它描述了不同调度程序对世界的看法之间的一些有趣的权衡。这是很多的话，所以如果你正在寻找答案，那么这个链接可能不是，但如果你正在寻找关于这个话题的实际研究，那似乎是合理的。