გაშვებული Apache Spark Kubernetes-ზე

ძვირფასო მკითხველებო, შუადღე მშვიდობისა. დღეს ჩვენ ცოტას ვისაუბრებთ Apache Spark-ზე და მისი განვითარების პერსპექტივებზე.

Big Data-ის თანამედროვე სამყაროში Apache Spark არის დე ფაქტო სტანდარტი მონაცემთა პარტიული დამუშავების ამოცანების შემუშავებისთვის. გარდა ამისა, იგი ასევე გამოიყენება ნაკადის აპლიკაციების შესაქმნელად, რომლებიც მუშაობენ მიკრო პარტიული კონცეფციით, ამუშავებენ და აგზავნიან მონაცემებს მცირე ნაწილებში (Spark Structured Streaming). და ტრადიციულად ის იყო საერთო Hadoop სტეკის ნაწილი, იყენებდა YARN-ს (ან ზოგიერთ შემთხვევაში Apache Mesos-ს), როგორც რესურსების მენეჯერს. 2020 წლისთვის მისი ტრადიციული ფორმით გამოყენება კითხვის ნიშნის ქვეშ დგას კომპანიების უმეტესობისთვის Hadoop-ის წესიერი დისტრიბუციის არარსებობის გამო - HDP და CDH განვითარება შეჩერებულია, CDH არ არის კარგად განვითარებული და აქვს მაღალი ღირებულება, ხოლო Hadoop-ის დანარჩენ მომწოდებლებს აქვთ. ან შეწყვიტა არსებობა ან ბუნდოვანი მომავალი აქვს. ამიტომ, Kubernetes-ის გამოყენებით Apache Spark-ის გაშვება მზარდ ინტერესს იწვევს საზოგადოებასა და მსხვილ კომპანიებში - ხდება სტანდარტი კონტეინერების ორკესტრირებისა და რესურსების მენეჯმენტში კერძო და საჯარო ღრუბლებში, ის აგვარებს პრობლემას Spark ამოცანების არასასიამოვნო რესურსების დაგეგმვისას YARN-ზე და უზრუნველყოფს. სტაბილურად განვითარებადი პლატფორმა მრავალი კომერციული და ღია დისტრიბუციით ყველა ზომისა და ზოლის კომპანიებისთვის. გარდა ამისა, პოპულარობის კვალდაკვალ, უმეტესობამ უკვე მოახერხა რამდენიმე საკუთარი ინსტალაციის შეძენა და გაზარდა მათი გამოცდილება მის გამოყენებაში, რაც ამარტივებს ნაბიჯს.

2.3.0 ვერსიით დაწყებული, Apache Spark-მა მიიღო ოფიციალური მხარდაჭერა Kubernetes კლასტერში ამოცანების შესრულებისთვის და დღეს ჩვენ ვისაუბრებთ ამ მიდგომის ამჟამინდელ სიმწიფეზე, მისი გამოყენების სხვადასხვა ვარიანტებზე და ხარვეზებზე, რომლებიც შეგვხვდება განხორციელების დროს.

უპირველეს ყოვლისა, მოდით შევხედოთ Apache Spark-ზე დაფუძნებული ამოცანებისა და აპლიკაციების შემუშავების პროცესს და გამოვყოთ ტიპიური შემთხვევები, როდესაც საჭიროა დავალების შესრულება Kubernetes კლასტერზე. ამ პოსტის მომზადებისას, OpenShift გამოიყენება როგორც დისტრიბუცია და მიცემული იქნება ბრძანებები, რომლებიც შეესაბამება მის ბრძანების ხაზს (oc). Kubernetes-ის სხვა დისტრიბუციებისთვის შეიძლება გამოყენებულ იქნას შესაბამისი ბრძანებები Kubernetes-ის სტანდარტული ბრძანების ხაზიდან (kubectl) ან მათი ანალოგები (მაგალითად, oc adm პოლიტიკისთვის).

პირველი გამოყენების შემთხვევა - spark-submit

ამოცანებისა და აპლიკაციების შემუშავებისას, დეველოპერმა უნდა შეასრულოს ამოცანები მონაცემთა ტრანსფორმაციის გამართვის მიზნით. თეორიულად, ნაკერების გამოყენება შესაძლებელია ამ მიზნებისათვის, მაგრამ საბოლოო სისტემების რეალური (თუმცა სატესტო) ინსტანციების მონაწილეობით დამუშავება უფრო სწრაფი და უკეთესი აღმოჩნდა ამ კლასში. იმ შემთხვევაში, როდესაც ჩვენ ვასწორებთ საბოლოო სისტემების რეალურ მაგალითებს, შესაძლებელია ორი სცენარი:

• დეველოპერი აწარმოებს Spark ამოცანას ადგილობრივად დამოუკიდებელ რეჟიმში;

  

• დეველოპერი აწარმოებს Spark ამოცანას Kubernetes კლასტერზე სატესტო ციკლში.

  

პირველ ვარიანტს აქვს არსებობის უფლება, მაგრამ შეიცავს უამრავ მინუსს:

• თითოეულ დეველოპერს უნდა ჰქონდეს წვდომა სამუშაო ადგილიდან საბოლოო სისტემების ყველა ინსტანციაზე, რომელიც მას სჭირდება;
• შემუშავებული დავალების შესასრულებლად სამუშაო მანქანაზე საჭიროა საკმარისი რესურსი.

მეორე ვარიანტს არ აქვს ეს ნაკლოვანებები, რადგან კუბერნეტის კლასტერის გამოყენება საშუალებას გაძლევთ გამოყოთ საჭირო რესურსების ფონდი ამოცანების შესასრულებლად და მიაწოდოთ მას საჭირო წვდომა სისტემის ბოლო ინსტანციებზე, მოქნილად უზრუნველყოთ მასზე წვდომა Kubernetes-ის როლური მოდელის გამოყენებით. განვითარების გუნდის ყველა წევრი. მოდი ხაზგასმით აღვნიშნოთ ის, როგორც გამოყენების პირველი შემთხვევა - Spark ამოცანების გაშვება ადგილობრივი დეველოპერული მანქანიდან Kubernetes კლასტერზე სატესტო ციკლში.

მოდით ვისაუბროთ უფრო მეტი Spark-ის დაყენების პროცესზე ადგილობრივად გასაშვებად. Spark-ის გამოყენების დასაწყებად, თქვენ უნდა დააინსტალიროთ იგი:

mkdir /opt/spark
cd /opt/spark
wget http://mirror.linux-ia64.org/apache/spark/spark-2.4.5/spark-2.4.5.tgz
tar zxvf spark-2.4.5.tgz
rm -f spark-2.4.5.tgz

ჩვენ ვაგროვებთ აუცილებელ პაკეტებს Kubernetes-თან მუშაობისთვის:

cd spark-2.4.5/
./build/mvn -Pkubernetes -DskipTests clean package

სრულ აწყობას დიდი დრო სჭირდება და დოკერის სურათების შესაქმნელად და კუბერნეტის კლასტერზე გასაშვებად, თქვენ ნამდვილად გჭირდებათ მხოლოდ jar ფაილები "assembly/" დირექტორიადან, ასე რომ თქვენ შეგიძლიათ შექმნათ მხოლოდ ეს ქვეპროექტი:

./build/mvn -f ./assembly/pom.xml -Pkubernetes -DskipTests clean package

Kubernetes-ზე Spark-ის სამუშაოების გასაშვებად, თქვენ უნდა შექმნათ Docker სურათი, რომელიც გამოიყენებთ როგორც საბაზისო სურათს. აქ არის 2 შესაძლო მიდგომა:

• გენერირებული Docker გამოსახულება მოიცავს შესრულებად Spark დავალების კოდს;
• შექმნილი სურათი მოიცავს მხოლოდ Spark-ს და აუცილებელ დამოკიდებულებებს, შესრულებადი კოდი დისტანციურად არის განთავსებული (მაგალითად, HDFS-ში).

პირველი, მოდით ავაშენოთ Docker სურათი, რომელიც შეიცავს Spark დავალების სატესტო მაგალითს. Docker სურათების შესაქმნელად Spark-ს აქვს პროგრამა სახელწოდებით "docker-image-tool". მოდით შევისწავლოთ დახმარება მასზე:

./bin/docker-image-tool.sh --help

მისი დახმარებით შეგიძლიათ შექმნათ Docker სურათები და ატვირთოთ ისინი დისტანციურ რეესტრებში, მაგრამ სტანდარტულად მას აქვს მთელი რიგი უარყოფითი მხარეები:

• უშეცდომოდ ქმნის 3 Docker სურათს ერთდროულად - Spark-ისთვის, PySpark-ისთვის და R-ისთვის;
• არ გაძლევთ საშუალებას მიუთითოთ სურათის სახელი.

ამიტომ, ჩვენ გამოვიყენებთ ამ პროგრამის შეცვლილ ვერსიას, რომელიც მოცემულია ქვემოთ:

vi bin/docker-image-tool-upd.sh

#!/usr/bin/env bash

function error {
  echo "$@" 1>&2
  exit 1
}

if [ -z "${SPARK_HOME}" ]; then
  SPARK_HOME="$(cd "`dirname "$0"`"/..; pwd)"
fi
. "${SPARK_HOME}/bin/load-spark-env.sh"

function image_ref {
  local image="$1"
  local add_repo="${2:-1}"
  if [ $add_repo = 1 ] && [ -n "$REPO" ]; then
    image="$REPO/$image"
  fi
  if [ -n "$TAG" ]; then
    image="$image:$TAG"
  fi
  echo "$image"
}

function build {
  local BUILD_ARGS
  local IMG_PATH

  if [ ! -f "$SPARK_HOME/RELEASE" ]; then
    IMG_PATH=$BASEDOCKERFILE
    BUILD_ARGS=(
      ${BUILD_PARAMS}
      --build-arg
      img_path=$IMG_PATH
      --build-arg
      datagram_jars=datagram/runtimelibs
      --build-arg
      spark_jars=assembly/target/scala-$SPARK_SCALA_VERSION/jars
    )
  else
    IMG_PATH="kubernetes/dockerfiles"
    BUILD_ARGS=(${BUILD_PARAMS})
  fi

  if [ -z "$IMG_PATH" ]; then
    error "Cannot find docker image. This script must be run from a runnable distribution of Apache Spark."
  fi

  if [ -z "$IMAGE_REF" ]; then
    error "Cannot find docker image reference. Please add -i arg."
  fi

  local BINDING_BUILD_ARGS=(
    ${BUILD_PARAMS}
    --build-arg
    base_img=$(image_ref $IMAGE_REF)
  )
  local BASEDOCKERFILE=${BASEDOCKERFILE:-"$IMG_PATH/spark/docker/Dockerfile"}

  docker build $NOCACHEARG "${BUILD_ARGS[@]}" 
    -t $(image_ref $IMAGE_REF) 
    -f "$BASEDOCKERFILE" .
}

function push {
  docker push "$(image_ref $IMAGE_REF)"
}

function usage {
  cat <<EOF
Usage: $0 [options] [command]
Builds or pushes the built-in Spark Docker image.

Commands:
  build       Build image. Requires a repository address to be provided if the image will be
              pushed to a different registry.
  push        Push a pre-built image to a registry. Requires a repository address to be provided.

Options:
  -f file               Dockerfile to build for JVM based Jobs. By default builds the Dockerfile shipped with Spark.
  -p file               Dockerfile to build for PySpark Jobs. Builds Python dependencies and ships with Spark.
  -R file               Dockerfile to build for SparkR Jobs. Builds R dependencies and ships with Spark.
  -r repo               Repository address.
  -i name               Image name to apply to the built image, or to identify the image to be pushed.  
  -t tag                Tag to apply to the built image, or to identify the image to be pushed.
  -m                    Use minikube's Docker daemon.
  -n                    Build docker image with --no-cache
  -b arg      Build arg to build or push the image. For multiple build args, this option needs to
              be used separately for each build arg.

Using minikube when building images will do so directly into minikube's Docker daemon.
There is no need to push the images into minikube in that case, they'll be automatically
available when running applications inside the minikube cluster.

Check the following documentation for more information on using the minikube Docker daemon:

  https://kubernetes.io/docs/getting-started-guides/minikube/#reusing-the-docker-daemon

Examples:
  - Build image in minikube with tag "testing"
    $0 -m -t testing build

  - Build and push image with tag "v2.3.0" to docker.io/myrepo
    $0 -r docker.io/myrepo -t v2.3.0 build
    $0 -r docker.io/myrepo -t v2.3.0 push
EOF
}

if [[ "$@" = *--help ]] || [[ "$@" = *-h ]]; then
  usage
  exit 0
fi

REPO=
TAG=
BASEDOCKERFILE=
NOCACHEARG=
BUILD_PARAMS=
IMAGE_REF=
while getopts f:mr:t:nb:i: option
do
 case "${option}"
 in
 f) BASEDOCKERFILE=${OPTARG};;
 r) REPO=${OPTARG};;
 t) TAG=${OPTARG};;
 n) NOCACHEARG="--no-cache";;
 i) IMAGE_REF=${OPTARG};;
 b) BUILD_PARAMS=${BUILD_PARAMS}" --build-arg "${OPTARG};;
 esac
done

case "${@: -1}" in
  build)
    build
    ;;
  push)
    if [ -z "$REPO" ]; then
      usage
      exit 1
    fi
    push
    ;;
  *)
    usage
    exit 1
    ;;
esac

მისი დახმარებით ჩვენ ვაგროვებთ Spark-ის ძირითად სურათს, რომელიც შეიცავს სატესტო დავალებას Pi-ს გამოსათვლელად Spark-ის გამოყენებით (აქ {docker-registry-url} არის თქვენი Docker გამოსახულების რეესტრის URL, {repo} არის რეესტრის შიგნით არსებული საცავის სახელი, რომელიც ემთხვევა პროექტს OpenShift-ში, {image-name} - სურათის სახელი (თუ გამოყენებულია სურათების სამდონიანი გამოყოფა, მაგალითად, როგორც Red Hat OpenShift სურათების ინტეგრირებულ რეესტრში), {tag} - ამის ტეგი სურათის ვერსია):

./bin/docker-image-tool-upd.sh -f resource-managers/kubernetes/docker/src/main/dockerfiles/spark/Dockerfile -r {docker-registry-url}/{repo} -i {image-name} -t {tag} build

შედით OKD კლასტერში კონსოლის უტილიტის გამოყენებით (აქ {OKD-API-URL} არის OKD კლასტერის API URL):

oc login {OKD-API-URL}

მოდით მივიღოთ ამჟამინდელი მომხმარებლის ჟეტონი ავტორიზაციისთვის Docker Registry-ში:

oc whoami -t

შედით OKD კლასტერის შიდა Docker Registry-ში (პაროლად ვიყენებთ წინა ბრძანების გამოყენებით მიღებულ ჟეტონს):

docker login {docker-registry-url}

მოდით ავტვირთოთ აწყობილი Docker სურათი Docker Registry OKD-ში:

./bin/docker-image-tool-upd.sh -r {docker-registry-url}/{repo} -i {image-name} -t {tag} push

მოდით შევამოწმოთ, რომ აწყობილი სურათი ხელმისაწვდომია OKD-ში. ამისათვის გახსენით URL ბრაუზერში შესაბამისი პროექტის სურათების სიით (აქ {project} არის პროექტის სახელი OpenShift კლასტერში, {OKD-WEBUI-URL} არის OpenShift ვებ კონსოლის URL. ) - https://{OKD-WEBUI-URL}/console /project/{project}/browse/images/{image-name}.

ამოცანების გასაშვებად, სერვისის ანგარიში უნდა შეიქმნას პრივილეგიებით, რომ გაუშვათ pods როგორც root (ამ საკითხს მოგვიანებით განვიხილავთ):

oc create sa spark -n {project}
oc adm policy add-scc-to-user anyuid -z spark -n {project}

მოდით გავუშვათ spark-submit ბრძანება, რომ გამოვაქვეყნოთ Spark დავალება OKD კლასტერში, სადაც მითითებულია შექმნილი სერვისის ანგარიში და Docker სურათი:

 /opt/spark/bin/spark-submit --name spark-test --class org.apache.spark.examples.SparkPi --conf spark.executor.instances=3 --conf spark.kubernetes.authenticate.driver.serviceAccountName=spark --conf spark.kubernetes.namespace={project} --conf spark.submit.deployMode=cluster --conf spark.kubernetes.container.image={docker-registry-url}/{repo}/{image-name}:{tag} --conf spark.master=k8s://https://{OKD-API-URL}  local:///opt/spark/examples/target/scala-2.11/jars/spark-examples_2.11-2.4.5.jar

Здесь:

— სახელი - დავალების დასახელება, რომელიც მიიღებს მონაწილეობას Kubernetes pods-ის სახელის ფორმირებაში;

—class — შესრულებადი ფაილის კლასი, რომელიც გამოიძახება დავალების დაწყებისას;

—conf — Spark-ის კონფიგურაციის პარამეტრები;

spark.executor.instances — გასაშვები Spark შემსრულებლების რაოდენობა;

spark.kubernetes.authenticate.driver.serviceAccountName - Kubernetes-ის სერვისის ანგარიშის სახელი, რომელიც გამოიყენება პოდების გაშვებისას (უსაფრთხოების კონტექსტისა და შესაძლებლობების დასადგენად Kubernetes API-სთან ურთიერთობისას);

spark.kubernetes.namespace — Kubernetes სახელთა სივრცე, რომელშიც გაშვებული იქნება დრაივერის და შემსრულებელი pods;

spark.submit.deployMode — Spark-ის გაშვების მეთოდი (სტანდარტული spark-submit-ისთვის გამოიყენება „კლასტერი“, Spark ოპერატორისთვის და Spark „კლიენტის“ შემდგომი ვერსიებისთვის);

spark.kubernetes.container.image - დოკერის სურათი, რომელიც გამოიყენება პოდების გასაშვებად;

spark.master — Kubernetes API URL (გარეგანი მითითებულია ისე, რომ წვდომა ხდება ადგილობრივი აპარატიდან);

local:// არის გზა Spark-ის შესასრულებელი Docker გამოსახულების შიგნით.

მივდივართ შესაბამის OKD პროექტზე და ვსწავლობთ შექმნილ პოდებს - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods.

განვითარების პროცესის გასამარტივებლად შეიძლება გამოყენებულ იქნას სხვა ვარიანტი, რომელშიც იქმნება Spark-ის საერთო საბაზისო სურათი, რომელიც გამოიყენება ყველა ამოცანის გასაშვებად, ხოლო შესრულებადი ფაილების სნეპშოტები გამოქვეყნდება გარე მეხსიერებაში (მაგალითად, Hadoop) და მითითებულია დარეკვისას. spark-submit როგორც ლინკი. ამ შემთხვევაში, თქვენ შეგიძლიათ გაუშვათ Spark ამოცანების სხვადასხვა ვერსიები Docker სურათების აღდგენის გარეშე, მაგალითად, WebHDFS-ის გამოყენებით სურათების გამოსაქვეყნებლად. ჩვენ ვაგზავნით მოთხოვნას ფაილის შესაქმნელად (აქ {host} არის WebHDFS სერვისის ჰოსტი, {port} არის WebHDFS სერვისის პორტი, {path-to-file-on-hdfs} არის ფაილის სასურველი გზა HDFS-ზე):

curl -i -X PUT "http://{host}:{port}/webhdfs/v1/{path-to-file-on-hdfs}?op=CREATE

თქვენ მიიღებთ ასეთ პასუხს (აქ {location} არის URL, რომელიც უნდა იქნას გამოყენებული ფაილის ჩამოსატვირთად):

HTTP/1.1 307 TEMPORARY_REDIRECT
Location: {location}
Content-Length: 0

ჩატვირთეთ Spark შესრულებადი ფაილი HDFS-ში (აქ {path-to-local-file} არის გზა Spark შესრულებადი ფაილის მიმდინარე ჰოსტზე):

curl -i -X PUT -T {path-to-local-file} "{location}"

ამის შემდეგ, ჩვენ შეგვიძლია გავაკეთოთ spark-submit HDFS-ში ატვირთული Spark ფაილის გამოყენებით (აქ {class-name} არის კლასის სახელი, რომელიც უნდა გაიხსნას დავალების შესასრულებლად):

/opt/spark/bin/spark-submit --name spark-test --class {class-name} --conf spark.executor.instances=3 --conf spark.kubernetes.authenticate.driver.serviceAccountName=spark --conf spark.kubernetes.namespace={project} --conf spark.submit.deployMode=cluster --conf spark.kubernetes.container.image={docker-registry-url}/{repo}/{image-name}:{tag} --conf spark.master=k8s://https://{OKD-API-URL}  hdfs://{host}:{port}/{path-to-file-on-hdfs}

უნდა აღინიშნოს, რომ HDFS-ზე წვდომისთვის და დავალების მუშაობის უზრუნველსაყოფად, შეიძლება დაგჭირდეთ Dockerfile და entrypoint.sh სკრიპტის შეცვლა - დაამატეთ დირექტივა Dockerfile-ში, რომ დააკოპიროთ დამოკიდებული ბიბლიოთეკები /opt/spark/jars დირექტორიაში და ჩართეთ HDFS კონფიგურაციის ფაილი SPARK_CLASSPATH-ში შესასვლელ წერტილში.

მეორე გამოყენების შემთხვევა - Apache Livy

გარდა ამისა, როდესაც ამოცანა შემუშავებულია და საჭიროა შედეგის ტესტირება, ჩნდება კითხვა მისი გაშვების, როგორც CI/CD პროცესის ნაწილისა და მისი შესრულების სტატუსის თვალყურის დევნების შესახებ. რა თქმა უნდა, შეგიძლიათ მისი გაშვება ადგილობრივი spark-submit ზარის გამოყენებით, მაგრამ ეს ართულებს CI/CD ინფრასტრუქტურას, რადგან ის მოითხოვს Spark-ის ინსტალაციას და კონფიგურაციას CI სერვერის აგენტებზე/გამშვებებზე და წვდომის დაყენებას Kubernetes API-ზე. ამ შემთხვევისთვის, სამიზნე იმპლემენტაციამ აირჩია Apache Livy-ის გამოყენება, როგორც REST API, Spark ამოცანების შესასრულებლად, რომლებიც განთავსებულია Kubernetes კლასტერში. მისი დახმარებით შეგიძლიათ აწარმოოთ Spark ამოცანები Kubernetes კლასტერზე რეგულარული cURL მოთხოვნების გამოყენებით, რომელიც ადვილად განხორციელდება ნებისმიერი CI გადაწყვეტის საფუძველზე და მისი განთავსება Kubernetes კლასტერში წყვეტს ავტორიზაციის საკითხს Kubernetes API-სთან ურთიერთობისას.

მოდი ხაზგასმით აღვნიშნოთ, როგორც მეორე გამოყენების შემთხვევა - Spark ამოცანების გაშვება, როგორც CI/CD პროცესის ნაწილი Kubernetes კლასტერზე ტესტის ციკლში.

ცოტა Apache Livy-ის შესახებ - ის მუშაობს როგორც HTTP სერვერი, რომელიც უზრუნველყოფს ვებ ინტერფეისს და RESTful API-ს, რომელიც საშუალებას გაძლევთ დისტანციურად გაუშვათ spark-submit საჭირო პარამეტრების გავლის გზით. ტრადიციულად, ის იგზავნება როგორც HDP დისტრიბუციის ნაწილი, მაგრამ ასევე შეიძლება განთავსდეს OKD-ზე ან Kubernetes-ის ნებისმიერ სხვა ინსტალაციაზე შესაბამისი მანიფესტის და Docker სურათების ნაკრების გამოყენებით, როგორიცაა ეს - github.com/ttauveron/k8s-big-data-experiments/tree/master/livy-spark-2.3. ჩვენს შემთხვევაში, მსგავსი Docker სურათი აშენდა, მათ შორის Spark ვერსია 2.4.5 შემდეგი Dockerfile-დან:

FROM java:8-alpine

ENV SPARK_HOME=/opt/spark
ENV LIVY_HOME=/opt/livy
ENV HADOOP_CONF_DIR=/etc/hadoop/conf
ENV SPARK_USER=spark

WORKDIR /opt

RUN apk add --update openssl wget bash && 
    wget -P /opt https://downloads.apache.org/spark/spark-2.4.5/spark-2.4.5-bin-hadoop2.7.tgz && 
    tar xvzf spark-2.4.5-bin-hadoop2.7.tgz && 
    rm spark-2.4.5-bin-hadoop2.7.tgz && 
    ln -s /opt/spark-2.4.5-bin-hadoop2.7 /opt/spark

RUN wget http://mirror.its.dal.ca/apache/incubator/livy/0.7.0-incubating/apache-livy-0.7.0-incubating-bin.zip && 
    unzip apache-livy-0.7.0-incubating-bin.zip && 
    rm apache-livy-0.7.0-incubating-bin.zip && 
    ln -s /opt/apache-livy-0.7.0-incubating-bin /opt/livy && 
    mkdir /var/log/livy && 
    ln -s /var/log/livy /opt/livy/logs && 
    cp /opt/livy/conf/log4j.properties.template /opt/livy/conf/log4j.properties

ADD livy.conf /opt/livy/conf
ADD spark-defaults.conf /opt/spark/conf/spark-defaults.conf
ADD entrypoint.sh /entrypoint.sh

ENV PATH="/opt/livy/bin:${PATH}"

EXPOSE 8998

ENTRYPOINT ["/entrypoint.sh"]
CMD ["livy-server"]

გენერირებული სურათი შეიძლება აშენდეს და აიტვირთოს თქვენს არსებულ Docker საცავში, როგორიცაა შიდა OKD საცავი. მის გამოსაყენებლად გამოიყენეთ შემდეგი მანიფესტი ({registry-url} - Docker image რეესტრის URL, {image-name} - Docker image name, {tag} - Docker image tag, {livy-url} - სასურველი URL, სადაც სერვერზე ხელმისაწვდომი იქნება Livy; „მარშრუტის“ მანიფესტი გამოიყენება, თუ Red Hat OpenShift გამოიყენება Kubernetes დისტრიბუციად, წინააღმდეგ შემთხვევაში გამოყენებული იქნება შესაბამისი Ingress ან Service მანიფესტი NodePort ტიპის):

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    component: livy
  name: livy
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      component: livy
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        component: livy
    spec:
      containers:
        - command:
            - livy-server
          env:
            - name: K8S_API_HOST
              value: localhost
            - name: SPARK_KUBERNETES_IMAGE
              value: 'gnut3ll4/spark:v1.0.14'
          image: '{registry-url}/{image-name}:{tag}'
          imagePullPolicy: Always
          name: livy
          ports:
            - containerPort: 8998
              name: livy-rest
              protocol: TCP
          resources: {}
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          volumeMounts:
            - mountPath: /var/log/livy
              name: livy-log
            - mountPath: /opt/.livy-sessions/
              name: livy-sessions
            - mountPath: /opt/livy/conf/livy.conf
              name: livy-config
              subPath: livy.conf
            - mountPath: /opt/spark/conf/spark-defaults.conf
              name: spark-config
              subPath: spark-defaults.conf
        - command:
            - /usr/local/bin/kubectl
            - proxy
            - '--port'
            - '8443'
          image: 'gnut3ll4/kubectl-sidecar:latest'
          imagePullPolicy: Always
          name: kubectl
          ports:
            - containerPort: 8443
              name: k8s-api
              protocol: TCP
          resources: {}
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      serviceAccount: spark
      serviceAccountName: spark
      terminationGracePeriodSeconds: 30
      volumes:
        - emptyDir: {}
          name: livy-log
        - emptyDir: {}
          name: livy-sessions
        - configMap:
            defaultMode: 420
            items:
              - key: livy.conf
                path: livy.conf
            name: livy-config
          name: livy-config
        - configMap:
            defaultMode: 420
            items:
              - key: spark-defaults.conf
                path: spark-defaults.conf
            name: livy-config
          name: spark-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: livy-config
data:
  livy.conf: |-
    livy.spark.deploy-mode=cluster
    livy.file.local-dir-whitelist=/opt/.livy-sessions/
    livy.spark.master=k8s://http://localhost:8443
    livy.server.session.state-retain.sec = 8h
  spark-defaults.conf: 'spark.kubernetes.container.image        "gnut3ll4/spark:v1.0.14"'
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: livy
  name: livy
spec:
  ports:
    - name: livy-rest
      port: 8998
      protocol: TCP
      targetPort: 8998
  selector:
    component: livy
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    app: livy
  name: livy
spec:
  host: {livy-url}
  port:
    targetPort: livy-rest
  to:
    kind: Service
    name: livy
    weight: 100
  wildcardPolicy: None

მისი გამოყენებისა და პოდის წარმატებით გაშვების შემდეგ, Livy გრაფიკული ინტერფეისი ხელმისაწვდომია ბმულზე: http://{livy-url}/ui. Livy-თან ერთად ჩვენ შეგვიძლია გამოვაქვეყნოთ ჩვენი Spark დავალება REST მოთხოვნის გამოყენებით, მაგალითად, ფოსტალიონისგან. მოთხოვნით კოლექციის მაგალითი წარმოდგენილია ქვემოთ (კონფიგურაციის არგუმენტები დაწყებული დავალების ფუნქციონირებისთვის აუცილებელი ცვლადებით შეიძლება გადავიდეს "args" მასივში):

{
    "info": {
        "_postman_id": "be135198-d2ff-47b6-a33e-0d27b9dba4c8",
        "name": "Spark Livy",
        "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
    },
    "item": [
        {
            "name": "1 Submit job with jar",
            "request": {
                "method": "POST",
                "header": [
                    {
                        "key": "Content-Type",
                        "value": "application/json"
                    }
                ],
                "body": {
                    "mode": "raw",
                    "raw": "{nt"file": "local:///opt/spark/examples/target/scala-2.11/jars/spark-examples_2.11-2.4.5.jar", nt"className": "org.apache.spark.examples.SparkPi",nt"numExecutors":1,nt"name": "spark-test-1",nt"conf": {ntt"spark.jars.ivy": "/tmp/.ivy",ntt"spark.kubernetes.authenticate.driver.serviceAccountName": "spark",ntt"spark.kubernetes.namespace": "{project}",ntt"spark.kubernetes.container.image": "{docker-registry-url}/{repo}/{image-name}:{tag}"nt}n}"
                },
                "url": {
                    "raw": "http://{livy-url}/batches",
                    "protocol": "http",
                    "host": [
                        "{livy-url}"
                    ],
                    "path": [
                        "batches"
                    ]
                }
            },
            "response": []
        },
        {
            "name": "2 Submit job without jar",
            "request": {
                "method": "POST",
                "header": [
                    {
                        "key": "Content-Type",
                        "value": "application/json"
                    }
                ],
                "body": {
                    "mode": "raw",
                    "raw": "{nt"file": "hdfs://{host}:{port}/{path-to-file-on-hdfs}", nt"className": "{class-name}",nt"numExecutors":1,nt"name": "spark-test-2",nt"proxyUser": "0",nt"conf": {ntt"spark.jars.ivy": "/tmp/.ivy",ntt"spark.kubernetes.authenticate.driver.serviceAccountName": "spark",ntt"spark.kubernetes.namespace": "{project}",ntt"spark.kubernetes.container.image": "{docker-registry-url}/{repo}/{image-name}:{tag}"nt},nt"args": [ntt"HADOOP_CONF_DIR=/opt/spark/hadoop-conf",ntt"MASTER=k8s://https://kubernetes.default.svc:8443"nt]n}"
                },
                "url": {
                    "raw": "http://{livy-url}/batches",
                    "protocol": "http",
                    "host": [
                        "{livy-url}"
                    ],
                    "path": [
                        "batches"
                    ]
                }
            },
            "response": []
        }
    ],
    "event": [
        {
            "listen": "prerequest",
            "script": {
                "id": "41bea1d0-278c-40c9-ad42-bf2e6268897d",
                "type": "text/javascript",
                "exec": [
                    ""
                ]
            }
        },
        {
            "listen": "test",
            "script": {
                "id": "3cdd7736-a885-4a2d-9668-bd75798f4560",
                "type": "text/javascript",
                "exec": [
                    ""
                ]
            }
        }
    ],
    "protocolProfileBehavior": {}
}

მოდით შევასრულოთ პირველი მოთხოვნა კოლექციიდან, გადავიდეთ OKD ინტერფეისში და შევამოწმოთ, რომ ამოცანა წარმატებით არის გაშვებული - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods. ამავდროულად, სესია გამოჩნდება Livy ინტერფეისში (http://{livy-url}/ui), რომლის ფარგლებშიც, Livy API-ის ან გრაფიკული ინტერფეისის გამოყენებით, შეგიძლიათ თვალყური ადევნოთ დავალების პროგრესს და შეისწავლოთ სესია. მორები.

ახლა ვაჩვენოთ როგორ მუშაობს ლივი. ამისათვის, მოდით შევამოწმოთ Livy კონტეინერის ჟურნალები პოდის შიგნით Livy სერვერით - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods/{livy-pod-name }?tab= ჟურნალები. მათგან შეგვიძლია დავინახოთ, რომ Livy REST API-ს გამოძახებისას კონტეინერში სახელად „livy“, შესრულებულია spark-submit, მსგავსი, რაც ჩვენ ზემოთ გამოვიყენეთ (აქ {livy-pod-name} არის შექმნილი პოდის სახელი. Livy სერვერთან). კოლექცია ასევე წარმოგიდგენთ მეორე მოთხოვნას, რომელიც საშუალებას გაძლევთ გაუშვათ ამოცანები, რომლებიც დისტანციურად მასპინძლობს Spark შესრულებადს Livy სერვერის გამოყენებით.

მესამე გამოყენების შემთხვევა - Spark Operator

ახლა, როდესაც დავალება შემოწმებულია, ჩნდება მისი რეგულარულად გაშვების საკითხი. Kubernetes კლასტერში ამოცანების რეგულარულად გაშვების მშობლიური გზა არის CronJob ერთეული და შეგიძლიათ გამოიყენოთ იგი, მაგრამ ამ დროისთვის ოპერატორების გამოყენება აპლიკაციების მართვისთვის Kubernetes-ში ძალიან პოპულარულია და Spark-ისთვის არის საკმაოდ მომწიფებული ოპერატორი, რომელიც ასევე არის გამოიყენება Enterprise-ის დონის გადაწყვეტილებებში (მაგალითად, Lightbend FastData Platform). ჩვენ გირჩევთ მის გამოყენებას - Spark-ის ამჟამინდელ სტაბილურ ვერსიას (2.4.5) აქვს საკმაოდ შეზღუდული კონფიგურაციის ვარიანტები Spark ამოცანების შესასრულებლად Kubernetes-ში, ხოლო შემდეგი ძირითადი ვერსია (3.0.0) აცხადებს სრულ მხარდაჭერას Kubernetes-ისთვის, მაგრამ მისი გამოშვების თარიღი უცნობია. . Spark Operator ანაზღაურებს ამ ხარვეზს მნიშვნელოვანი კონფიგურაციის ვარიანტების დამატებით (მაგალითად, ConfigMap-ის დამონტაჟება Hadoop წვდომის კონფიგურაციით Spark pods-ზე) და რეგულარულად დაგეგმილი დავალების შესრულების შესაძლებლობით.

მოდით გამოვყოთ ის, როგორც მესამე გამოყენების შემთხვევა - რეგულარულად გაშვებული Spark ამოცანები Kubernetes კლასტერზე საწარმოო ციკლში.

Spark Operator არის ღია წყარო და განვითარებულია Google Cloud Platform-ში - github.com/GoogleCloudPlatform/spark-on-k8s-operator. მისი ინსტალაცია შეიძლება განხორციელდეს 3 გზით:

1. როგორც Lightbend FastData პლატფორმის/Cloudflow ინსტალაციის ნაწილი;
2. ჩაფხუტის გამოყენება:

   helm repo add incubator http://storage.googleapis.com/kubernetes-charts-incubator
   helm install incubator/sparkoperator --namespace spark-operator
   	

3. მანიფესტების გამოყენება ოფიციალური საცავიდან (https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/tree/master/manifest). აღსანიშნავია შემდეგი - Cloudflow მოიცავს ოპერატორს API ვერსიით v1beta1. თუ ამ ტიპის ინსტალაცია გამოიყენება, Spark აპლიკაციის მანიფესტის აღწერილობები უნდა ეფუძნებოდეს Git-ის მაგალითებს API-ის შესაბამისი ვერსიით, მაგალითად, "v1beta1-0.9.0-2.4.0". ოპერატორის ვერსია შეგიძლიათ იხილოთ CRD-ის აღწერაში, რომელიც შედის ოპერატორში "ვერსიების" ლექსიკონში:

   oc get crd sparkapplications.sparkoperator.k8s.io -o yaml
   	

თუ ოპერატორი სწორად არის დაინსტალირებული, Spark ოპერატორის აქტიური პოდი გამოჩნდება შესაბამის პროექტში (მაგალითად, cloudflow-fdp-sparkoperator Cloudflow სივრცეში Cloudflow-ის ინსტალაციისთვის) და გამოჩნდება შესაბამისი Kubernetes რესურსის ტიპი სახელად „sparkapplications“ . თქვენ შეგიძლიათ შეისწავლოთ ხელმისაწვდომი Spark აპლიკაციები შემდეგი ბრძანებით:

oc get sparkapplications -n {project}

Spark Operator-ის გამოყენებით ამოცანების შესასრულებლად საჭიროა 3 რამის გაკეთება:

• შექმენით დოკერის სურათი, რომელიც მოიცავს ყველა საჭირო ბიბლიოთეკას, ასევე კონფიგურაციას და შესრულებად ფაილებს. სამიზნე სურათში ეს არის სურათი, რომელიც შექმნილია CI/CD ეტაპზე და ტესტირებულია სატესტო კლასტერზე;
• Docker სურათის გამოქვეყნება რეესტრში, რომელიც ხელმისაწვდომია Kubernetes კლასტერიდან;
• შექმენით მანიფესტი „SparkApplication“ ტიპისა და გასაშვები ამოცანის აღწერილობით. მანიფესტების მაგალითები ხელმისაწვდომია ოფიციალურ საცავში (მაგ. github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/v1beta1-0.9.0-2.4.0/examples/spark-pi.yaml). მანიფესტის შესახებ უნდა აღინიშნოს მნიშვნელოვანი პუნქტები:
  1. „apiVersion“ ლექსიკონში უნდა იყოს მითითებული ოპერატორის ვერსიის შესაბამისი API ვერსია;
  2. ლექსიკონში „metadata.namespace“ უნდა იყოს მითითებული სახელთა სივრცე, რომელშიც აპლიკაციის გაშვება მოხდება;
  3. ლექსიკონი „spec.image“ უნდა შეიცავდეს შექმნილი Docker სურათის მისამართს ხელმისაწვდომ რეესტრში;
  4. ლექსიკონი „spec.mainClass“ უნდა შეიცავდეს Spark ამოცანების კლასს, რომელიც უნდა გაუშვათ პროცესის დაწყებისას;
  5. ლექსიკონი „spec.mainApplicationFile“ უნდა შეიცავდეს შესრულებადი jar ფაილის გზას;
  6. ლექსიკონში „spec.sparkVersion“ უნდა მიუთითებდეს გამოყენებული Spark-ის ვერსია;
  7. „spec.driver.serviceAccount“ ლექსიკონში უნდა იყოს მითითებული სერვისის ანგარიში შესაბამის Kubernetes სახელთა სივრცეში, რომელიც გამოყენებული იქნება აპლიკაციის გასაშვებად;
  8. „spec.executor“ ლექსიკონში უნდა იყოს მითითებული აპლიკაციისთვის გამოყოფილი რესურსების რაოდენობა;
  9. "spec.volumeMounts" ლექსიკონში უნდა იყოს მითითებული ლოკალური დირექტორია, რომელშიც შეიქმნება ლოკალური Spark ამოცანების ფაილები.

მანიფესტის გენერირების მაგალითი (აქ {spark-service-account} არის სერვისის ანგარიში Kubernetes კლასტერში Spark ამოცანების შესასრულებლად):

apiVersion: "sparkoperator.k8s.io/v1beta1"
kind: SparkApplication
metadata:
  name: spark-pi
  namespace: {project}
spec:
  type: Scala
  mode: cluster
  image: "gcr.io/spark-operator/spark:v2.4.0"
  imagePullPolicy: Always
  mainClass: org.apache.spark.examples.SparkPi
  mainApplicationFile: "local:///opt/spark/examples/jars/spark-examples_2.11-2.4.0.jar"
  sparkVersion: "2.4.0"
  restartPolicy:
    type: Never
  volumes:
    - name: "test-volume"
      hostPath:
        path: "/tmp"
        type: Directory
  driver:
    cores: 0.1
    coreLimit: "200m"
    memory: "512m"
    labels:
      version: 2.4.0
    serviceAccount: {spark-service-account}
    volumeMounts:
      - name: "test-volume"
        mountPath: "/tmp"
  executor:
    cores: 1
    instances: 1
    memory: "512m"
    labels:
      version: 2.4.0
    volumeMounts:
      - name: "test-volume"
        mountPath: "/tmp"

ეს მანიფესტი განსაზღვრავს სერვისის ანგარიშს, რომლისთვისაც, მანიფესტის გამოქვეყნებამდე, თქვენ უნდა შექმნათ აუცილებელი როლური შეკვრა, რომელიც უზრუნველყოფს Spark აპლიკაციის წვდომის აუცილებელ უფლებებს Kubernetes API-სთან ურთიერთობისთვის (საჭიროების შემთხვევაში). ჩვენს შემთხვევაში, აპლიკაციას სჭირდება უფლებები Pods-ის შესაქმნელად. მოდით შევქმნათ აუცილებელი როლის შემკვრელი:

oc adm policy add-role-to-user edit system:serviceaccount:{project}:{spark-service-account} -n {project}

ასევე აღსანიშნავია, რომ მანიფესტის ეს სპეციფიკაცია შეიძლება შეიცავდეს "hadoopConfigMap" პარამეტრს, რომელიც საშუალებას გაძლევთ მიუთითოთ ConfigMap Hadoop-ის კონფიგურაციით, შესაბამისი ფაილის Docker სურათში ჯერ განთავსების გარეშე. ის ასევე შესაფერისია დავალებების რეგულარულად შესასრულებლად - "განრიგის" პარამეტრის გამოყენებით, შეიძლება დაზუსტდეს მოცემული დავალების შესრულების გრაფიკი.

ამის შემდეგ, ჩვენ ვინახავთ ჩვენს მანიფესტს spark-pi.yaml ფაილში და ვიყენებთ მას ჩვენს Kubernetes კლასტერში:

oc apply -f spark-pi.yaml

ეს შექმნის "sparkapplications" ტიპის ობიექტს:

oc get sparkapplications -n {project}
> NAME       AGE
> spark-pi   22h

ამ შემთხვევაში შეიქმნება პოდი აპლიკაციით, რომლის სტატუსი ნაჩვენები იქნება შექმნილ „sparkapplications“-ში. მისი ნახვა შეგიძლიათ შემდეგი ბრძანებით:

oc get sparkapplications spark-pi -o yaml -n {project}

დავალების შესრულების შემდეგ, POD გადავა "დასრულებული" სტატუსზე, რომელიც ასევე განახლდება "sparkapplications"-ში. აპლიკაციის ჟურნალის ნახვა შესაძლებელია ბრაუზერში ან შემდეგი ბრძანების გამოყენებით (აქ {sparkapplications-pod-name} არის გაშვებული ამოცანის pod-ის სახელი):

oc logs {sparkapplications-pod-name} -n {project}

Spark ამოცანების მართვა ასევე შესაძლებელია სპეციალიზებული sparkctl უტილიტის გამოყენებით. მის დასაინსტალირებლად, კლონირეთ საცავი მისი წყაროს კოდით, დააინსტალირეთ Go და შექმენით ეს პროგრამა:

git clone https://github.com/GoogleCloudPlatform/spark-on-k8s-operator.git
cd spark-on-k8s-operator/
wget https://dl.google.com/go/go1.13.3.linux-amd64.tar.gz
tar -xzf go1.13.3.linux-amd64.tar.gz
sudo mv go /usr/local
mkdir $HOME/Projects
export GOROOT=/usr/local/go
export GOPATH=$HOME/Projects
export PATH=$GOPATH/bin:$GOROOT/bin:$PATH
go -version
cd sparkctl
go build -o sparkctl
sudo mv sparkctl /usr/local/bin

მოდით განვიხილოთ Spark-ის გაშვებული ამოცანების სია:

sparkctl list -n {project}

მოდით შევქმნათ აღწერა Spark ამოცანისთვის:

vi spark-app.yaml

apiVersion: "sparkoperator.k8s.io/v1beta1"
kind: SparkApplication
metadata:
  name: spark-pi
  namespace: {project}
spec:
  type: Scala
  mode: cluster
  image: "gcr.io/spark-operator/spark:v2.4.0"
  imagePullPolicy: Always
  mainClass: org.apache.spark.examples.SparkPi
  mainApplicationFile: "local:///opt/spark/examples/jars/spark-examples_2.11-2.4.0.jar"
  sparkVersion: "2.4.0"
  restartPolicy:
    type: Never
  volumes:
    - name: "test-volume"
      hostPath:
        path: "/tmp"
        type: Directory
  driver:
    cores: 1
    coreLimit: "1000m"
    memory: "512m"
    labels:
      version: 2.4.0
    serviceAccount: spark
    volumeMounts:
      - name: "test-volume"
        mountPath: "/tmp"
  executor:
    cores: 1
    instances: 1
    memory: "512m"
    labels:
      version: 2.4.0
    volumeMounts:
      - name: "test-volume"
        mountPath: "/tmp"

მოდით შევასრულოთ აღწერილი დავალება sparkctl-ის გამოყენებით:

sparkctl create spark-app.yaml -n {project}

მოდით განვიხილოთ Spark-ის გაშვებული ამოცანების სია:

sparkctl list -n {project}

მოდით განვიხილოთ Spark-ის გაშვებული დავალების მოვლენების სია:

sparkctl event spark-pi -n {project} -f

მოდით შევხედოთ გაშვებული Spark ამოცანის სტატუსს:

sparkctl status spark-pi -n {project}

დასასრულს, მსურს განვიხილო კუბერნეტში Spark-ის (2.4.5) მიმდინარე სტაბილური ვერსიის გამოყენების აღმოჩენილი უარყოფითი მხარეები:

1. პირველი და, ალბათ, მთავარი მინუსი არის მონაცემთა ლოკალურობის ნაკლებობა. YARN-ის ყველა ნაკლოვანების მიუხედავად, მის გამოყენებას უპირატესობებიც ჰქონდა, მაგალითად, კოდის მონაცემებზე მიწოდების პრინციპი (და არა მონაცემთა კოდისთვის). მისი წყალობით Spark-ის ამოცანები შესრულდა იმ კვანძებზე, სადაც მდებარეობდა გამოთვლებში ჩართული მონაცემები და მნიშვნელოვნად შემცირდა ქსელში მონაცემების მიწოდების დრო. Kubernetes-ის გამოყენებისას, ჩვენ ვაწყდებით ამოცანაში ჩართული მონაცემების ქსელში გადატანის აუცილებლობას. თუ ისინი საკმარისად დიდია, დავალების შესრულების დრო შეიძლება მნიშვნელოვნად გაიზარდოს და ასევე მოითხოვოს საკმაოდ დიდი ადგილი დისკზე, რომელიც გამოყოფილია Spark დავალების ინსტანციებზე მათი დროებითი შენახვისთვის. ეს მინუსი შეიძლება შემცირდეს სპეციალიზებული პროგრამული უზრუნველყოფის გამოყენებით, რომელიც უზრუნველყოფს მონაცემთა ლოკალიზაციას Kubernetes-ში (მაგალითად, Alluxio), მაგრამ ეს რეალურად ნიშნავს მონაცემთა სრული ასლის შენახვის აუცილებლობას Kubernetes კლასტერის კვანძებზე.
2. მეორე მნიშვნელოვანი მინუსი არის უსაფრთხოება. ნაგულისხმევად, Spark ამოცანების გაშვებასთან დაკავშირებით უსაფრთხოებასთან დაკავშირებული ფუნქციები გამორთულია, Kerberos-ის გამოყენება არ არის დაფარული ოფიციალურ დოკუმენტაციაში (თუმცა შესაბამისი ვარიანტები დაინერგა 3.0.0 ვერსიაში, რომელიც დამატებით სამუშაოს მოითხოვს) და უსაფრთხოების დოკუმენტაცია Spark-ის გამოყენებით (https ://spark.apache.org/docs/2.4.5/security.html) მხოლოდ YARN, Mesos და Standalone Cluster გამოჩნდება გასაღების მაღაზიებად. ამავდროულად, მომხმარებლის, რომლის ფარგლებშიც Spark ამოცანები იხსნება, არ შეიძლება პირდაპირ დაზუსტდეს - ჩვენ მხოლოდ განვსაზღვრავთ სერვისის ანგარიშს, რომლითაც ის იმუშავებს, ხოლო მომხმარებელი შეირჩევა კონფიგურირებული უსაფრთხოების პოლიტიკის საფუძველზე. ამასთან დაკავშირებით, გამოიყენება ან root მომხმარებელი, რომელიც არ არის უსაფრთხო პროდუქტიულ გარემოში, ან შემთხვევითი UID-ის მომხმარებელი, რომელიც არასასიამოვნოა მონაცემებზე წვდომის უფლებების განაწილებისას (ამის მოგვარება შესაძლებელია PodSecurityPolicies-ის შექმნით და მათთან დაკავშირებით. შესაბამისი მომსახურების ანგარიშები). ამჟამად, გამოსავალი არის ან განათავსოთ ყველა საჭირო ფაილი პირდაპირ Docker სურათში, ან შეცვალოთ Spark გაშვების სკრიპტი, რათა გამოიყენოს თქვენს ორგანიზაციაში მიღებული საიდუმლოების შენახვისა და ამოღების მექანიზმი.
3. Spark სამუშაოების გაშვება Kubernetes-ის გამოყენებით ოფიციალურად ჯერ კიდევ ექსპერიმენტულ რეჟიმშია და მომავალში შესაძლოა მნიშვნელოვანი ცვლილებები მოხდეს გამოყენებულ არტეფაქტებში (კონფიგურაციის ფაილები, Docker-ის ბაზის სურათები და გაშვების სკრიპტები). და მართლაც, მასალის მომზადებისას, 2.3.0 და 2.4.5 ვერსიები შემოწმდა, ქცევა მნიშვნელოვნად განსხვავდებოდა.

მოდით დაველოდოთ განახლებებს - ახლახან გამოვიდა Spark-ის ახალი ვერსია (3.0.0), რომელმაც მნიშვნელოვანი ცვლილებები შეიტანა Spark-ის მუშაობაში Kubernetes-ზე, მაგრამ შეინარჩუნა ამ რესურს მენეჯერის მხარდაჭერის ექსპერიმენტული სტატუსი. შესაძლოა, შემდეგი განახლებები საშუალებას მოგცემთ სრულად გირჩიოთ YARN-ის მიტოვება და Spark ამოცანების გაშვება Kubernetes-ზე თქვენი სისტემის უსაფრთხოების შიშის გარეშე და ფუნქციური კომპონენტების დამოუკიდებლად შეცვლის აუცილებლობის გარეშე.

ბოლო

წყარო: www.habr.com