一、Native 简介
现在，Docker、Kubernetes等容器技术已发展为一项通用技术。
Kubernetes 的核心难点无外乎这几个方面：
- 容器内抓包定位网络问题
- 容器进程主动退出、只能运行一个参数
- JVM 参数在容器中突然失效
说白了， Kubernetes 的核心理念并不复杂，但涉及的维度的确很多。比如，微服务架构理念、分布式原理、网络、存储等各个层级的知识体系都会覆盖，非运维出身理解起来会比较困难。
以 Flink 和 Spark 为代表的分布式流批计算框架的下层资源管理平台逐渐从 Hadoop 生态的 YARN 转向 Kubernetes生态的K8s原生scheduler以及周边资源调度器，比如 Volcano 和 Yunikorn 等。
这篇文章简单比较一下两种计算框架在 Native Kubernetes 的支持和实现上的异同，以及对于应用到生产环境我们还需要做些什么。
这里的 native 其实就是计算框架直接向 Kubernetes 申请资源。比如很多跑在 YARN 上面的计算框架，需要自己实现一个 AppMaster 来想 YARN 的 ResourceManager 来申请资源。Native K8s 相当于计算框架自己实现一个类似 AppMaster 的角色向 k8s 去申请资源，当然和 AppMaster 还是有差异的 （AppMaster 需要按 YARN 的标准进行实现）。
二、Spark on K8s 1、提交作业向 k8s 集群提交作业和往 YARN 上面提交很类似，命令如下，主要区别包括：
- --master 参数指定 k8s 集群的 ApiServer
- 需要通过参数 spark.kubernetes.contain
