spark on k8s与spark on k8s operator的对比是怎样的
这期内容当中小编将会给大家带来有关spark on k8s与spark on k8s operator的对比是怎样的，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
对于目前基于k8s的的spark应用，主要采用两种方式运行
spark原生支持的 spark on k8s
基于k8s的operator的 spark on k8s operator
前者是spark社区支持k8s这种资源管理框架而引入的k8s client的实现
后者是k8s社区为了支持spark而开发的一种operator
| 区别 | spark on k8s | spark on k8s operator |
|---|---|---|
| 社区支持 | spark社区 | GoogleCloudPlatform非官方支持 |
| 版本要求 | spark>=2.3,Kubernetes>=1.6 | spark>2.3,Kubernetes>=1.13 |
| 安装 | 按照官网安装，需要k8s pod的create list edit delete权限，且需要自己编译源码进行镜像的构建，构建过程繁琐 | 需要k8s admin安装incubator/sparkoperator，需要pod create list edit delete的权限 |
| 使用 | 直接spark submit提交，如:下面code 1,支持client和cluster模式，spark on k8s | 通过yaml配置文件形式提交，支持client和cluster模式，提交如code2，具体参数参考spark operator configuration |
| 优点 | 符合sparker的方式进行任务提交，对于习惯了spark的使用者来说，使用起来更顺手 | k8s配置文件方式提交任务，复用性强 |
| 缺点 | 运行完后driver的资源不会自动释放 | 运行完后driver的资源不会自动释放 |
| 实现方式 | 对于spark提交方式来说，无论是client提交还是cluster提交，都是继承SparkApplication。以client提交，子类则是JavaMainApplication,该方式以反射运行,对于k8s任务来分析,clusterManager为KubernetesClusterManager,该方式和向yarn提交任务的方式没什么区别;以cluster方式提交,对于k8s任务来说,spark程序的入口为KubernetesClientApplication，client端会建立clusterIp为None的service，executor跟该service进行rpc，如任务的提交的交互，且会建立以driver-conf-map后缀的configMap，该configMap在建立spark driver pod的时候，以volumn挂载的形式被引用,而该文件的内容最终在driver提交任务的时候以--properties-file形式提交给spark driver，从而spark.driver.host等配置项就传输给了driver，与此同时也会建立以-hadoop-config为后缀的configMap，可是 k8s 镜像怎么区分是运行executor还是driver的呢？一切都在dockerfile(具体构建的时候根据hadoop和kerbeors环境的不一样进行区别配置)和entrypoint中,其中shell中是区分driver和executor的; | 采用k8s CRD Controller的机制，自定义CRD,根据operator SDK,监听对应的增删改查event，如监听到对应的CRD的创建事件，则根据对应yaml文件配置项，建立pod，进行spark任务的提交，具体的实现，可参考spark on k8s operator design,具体以cluster和client模式提交的原理和spark on k8s一致,因为镜像复用的是spark的官方镜像 |
code 1 --- bin/spark-submit \ --master k8s://https://192.168.202.231:6443 \ --deploy-mode cluster \ --name spark-pi \ --class org.apache.spark.examples.SparkPi \ --conf spark.executor.instances=2 \ --conf "spark.kubernetes.namespace=dev" \ --conf "spark.kubernetes.authenticate.driver.serviceAccountName=lijiahong" \ --conf "spark.kubernetes.container.image=harbor.k8s-test.uc.host.dxy/dev/spark-py:cdh-2.6.0-5.13.1" \ --conf "spark.kubernetes.container.image.pullSecrets=regsecret" \ --conf "spark.kubernetes.file.upload.path=hdfs:///tmp" \ --conf "spark.kubernetes.container.image.pullPolicy=Always" \ hdfs:///tmp/spark-examples_2.12-3.0.0.jar
code 2 --- apiVersion: "sparkoperator.k8s.io/v1beta2" kind: SparkApplication metadata: name: spark-pi namespace: dev spec: type: Scala mode: cluster image: "gcr.io/spark-operator/spark:v3.0.0" imagePullPolicy: Always mainClass: org.apache.spark.examples.SparkPi mainApplicationFile: "local:///opt/spark/examples/jars/spark-examples_2.12-3.0.0.jar" sparkVersion: "3.0.0" restartPolicy: type: Never volumes: - name: "test-volume" hostPath: path: "/tmp" type: Directory driver: cores: 1 coreLimit: "1200m" memory: "512m" labels: version: 3.0.0 serviceAccount: lijiahong volumeMounts: - name: "test-volume" mountPath: "/tmp" executor: cores: 1 instances: 1 memory: "512m" labels: version: 3.0.0 volumeMounts: - name: "test-volume" mountPath: "/tmp"
上述就是小编为大家分享的spark on k8s与spark on k8s operator的对比是怎样的了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注蜗牛博客行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：niceseo99@gmail.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
版权声明：如无特殊标注，文章均为本站原创，转载时请以链接形式注明文章出处。
评论