随着kubernetes的倒退，大数据体系拥抱k8s成为了必经之路。
从Spark 2.4 版本开始，Spark 实验性反对 Kubernetes 作为资源管理器。不过尽管是试验性质，然而曾经有很多单位将之用于生产环境了，并获得很好的成果，在可移植性，可扩展性，老本等方面都获得了收益。
本文次要解读一下Spark 3.0 对于kubernetes的加强。
本文共分为5个局部，每个局部都有一个性能类别。你将首先看到配置更改，而后是运行时环境和安全性加强。之后，将理解Kubernetes的次要倒退之一-pod模板。到文章开端，将理解到从贡献者的角度来看产生了什么变动。
配置
此类别的第一个重要更改是配置验证。从Apache Spark 3.0开始，与模式_[-._a-zA-Z][-._a-zA-Z0-9]*_不匹配的Kubernetes属性（带有spark.executorEnv前缀）将被疏忽并显示正告音讯如下：
Invalid key: ... a valid environment variable name must consist of alphabetic characters, digits, '_', '-', or '.', and must not start with a digit.在3.0版本中，能够应用spark.kubernetes.driver.request.cores属性为 driver 申请特定数量的CPU核。而 executor 的属性（spark.kubernetes.executor.request.cores）自Spark 2.4.0起可用。
除此之外，还增加了一些工夫管制属性。应用spark.kubernetes.submission.connectionTimeout和spark.kubernetes.submission.requestTimeout，能够管制连贯和申请超时，以在客户端模式下启动 executor 程序。还存在两个相似的属性来解决申请 driver 的雷同超时（spark.kubernetes.driver.requestTimeout，spark.kubernetes.driver.connectionTimeout）。
运行时环境
另一类性能与运行时环境无关。首先，对于PySpark的用户，Python 3是Docker镜像中的默认绑定（仍反对版本2）
// Default change in the config val PYSPARK_MAJOR_PYTHON_VERSION = ConfigBuilder("spark.kubernetes.pyspark.pythonVersion") .doc("This sets the major Python version. Either 2 or 3. (Python2 or Python3)") .version("2.4.0") .stringConf .checkValue(pv => List("2", "3").contains(pv), "Ensure that major Python version is either Python2 or Python3") .createWithDefault("3") // was "2" in Spark 2.4.0如果对绑定感到好奇，能够认真钻研以下的代码：
# /resource-managers/kubernetes/docker/src/main/dockerfiles/spark/entrypoint.shif [ "$PYSPARK_MAJOR_PYTHON_VERSION" == "2" ]; then pyv="$(python -V 2>&1)" export PYTHON_VERSION="${pyv:7}" export PYSPARK_PYTHON="python" export PYSPARK_DRIVER_PYTHON="python"elif [ "$PYSPARK_MAJOR_PYTHON_VERSION" == "3" ]; then pyv3="$(python3 -V 2>&1)" export PYTHON_VERSION="${pyv3:7}" export PYSPARK_PYTHON="python3" export PYSPARK_DRIVER_PYTHON="python3"fi 对于Scala-Spark API，第一个运行时演进波及JDK版本。你可能曾经晓得，Apache Spark 3.0间接跳过了版本9和10的兼容性工作之后，增加了对JDK版本11（SPARK-24417）的反对。在Kubernetes局部中实现了这一反对，并提供了一个示例，该示例应用来自 docker-image-tool.sh 的Java 11标记构建的Spark Docker镜像：
$0 -r docker.io/myrepo -t v3.0.0 -b java_image_tag=11-jre-slim build最初，为了优化测试执行，Apache Spark 3.0测试镜像应用JRE而不是JDK。
平安加强
在下一类别中，能够找到所有重要的平安加强性能。对于容器，最佳实际之一是不在镜像中应用root用户。在以前的版本中，从我的项目的docker-image-tool.sh构建的镜像应用根目录。它在3.0中进行了更改，因为该脚本设置了能够用-u参数笼罩的默认用户。
第二个重要演变是对于secret编辑。在Apache Spark 3.0之前，UI和日志中仅显示带有“ secret”或“ password”之类的配置属性的值。在3.0中，针对该Kubernetes服务器身份验证中应用的spark.kubernetes.authenticate.submission.oauthToken属性，向该列表增加了一个新配置“令牌”。
最初，Apache Spark 3.0还增加了在集群和客户端模式下对Kerberos的反对。回忆一下，Kerberos是一种基于票证的网络身份验证协定，用于解决非平安网络中的身份问题。在Apache Spark上下文中，此性能有助于与HDFS或任何其余kerberized服务进行平安通信。
可扩展性
下一个重要性能是可扩展性。 Kubernetes附带了一个称为Pod模板的YAML标准，可用于创立和运行新Pod。 社区抉择它作为定制申请的代替办法。在此之前，必须将任何新的Kubernetes选项增加到Apache Spark配置文件中。从久远来看，这可能会减少Kubernetes和Spark之间的差距，并使该我的项目难以保护。
扩大在Kubernetes上执行的Apache Spark Pod的一种灵便办法是应用这些属性中的Pod模板，即 driver 的spark.kubernetes.driver.podTemplateFile和 executor 的spark.kubernetes.executor.podTemplateFile。重要的是要留神，某些模板属性永远不会笼罩Apache Spark配置管理的值，例如，用于命名空间或pod重启策略的属性。
随着Kubernetes的倒退，Pod的参数会逐渐减少，单纯依附命令行参数，会变得越来越简单。对于Pod模板的反对，一是能够升高spark 对于k8s版本的耦合，二是表达力更加丰盛。
测试优化
新版本的Apache Spark测试中用更加轻量级更弱小的Minio取代了Ceph。
此外，还为secret测试增加了更好的谬误音讯解决。同样，具备不可预测的Thread.sleep的并发控件也被侦听器和基于CountDownLatch的编排所代替（无关Java类的更多信息，请参见CountDownLatch）。
除此之外，还为Apache Spark 2.4中引入的性能增加了一些额定的集成测试。其中之一波及长久卷。
论断
依照社区规划，从Apache Spark 3.1.0开始，Kubernetes资源管理器的状态将从试验性变为个别可用性，并会减少很多新性能。在翻译本文的时候，Apache Spark 3.1.0 曾经release，是时候将咱们的spark 运行到 k8s 中了。