共计 3368 个字符，预计需要花费 9 分钟才能阅读完成。
随着 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.sh
if ["$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 中了。