कुबेरनेट्स पर अपाचे स्पार्क चल रहा है

प्रिय पाठकों, शुभ दोपहर। आज हम अपाचे स्पार्क और इसकी विकास संभावनाओं के बारे में थोड़ी बात करेंगे।

बिग डेटा की आधुनिक दुनिया में, अपाचे स्पार्क बैच डेटा प्रोसेसिंग कार्यों को विकसित करने के लिए वास्तविक मानक है। इसके अलावा, इसका उपयोग स्ट्रीमिंग एप्लिकेशन बनाने के लिए भी किया जाता है जो माइक्रो बैच अवधारणा, प्रसंस्करण और छोटे भागों में डेटा शिपिंग (स्पार्क स्ट्रक्चर्ड स्ट्रीमिंग) में काम करते हैं। और परंपरागत रूप से यह संसाधन प्रबंधक के रूप में YARN (या कुछ मामलों में अपाचे मेसोस) का उपयोग करते हुए, समग्र Hadoop स्टैक का हिस्सा रहा है। 2020 तक, अपने पारंपरिक रूप में इसका उपयोग सभ्य Hadoop वितरण की कमी के कारण अधिकांश कंपनियों के लिए सवालों के घेरे में है - HDP और CDH का विकास रुक गया है, CDH अच्छी तरह से विकसित नहीं है और इसकी लागत अधिक है, और शेष Hadoop आपूर्तिकर्ताओं के पास है या तो अस्तित्व समाप्त हो गया या उसका भविष्य अंधकारमय हो गया। इसलिए, कुबेरनेट्स का उपयोग करके अपाचे स्पार्क का लॉन्च समुदाय और बड़ी कंपनियों के बीच रुचि बढ़ा रहा है - निजी और सार्वजनिक क्लाउड में कंटेनर ऑर्केस्ट्रेशन और संसाधन प्रबंधन में एक मानक बनकर, यह YARN पर स्पार्क कार्यों के असुविधाजनक संसाधन शेड्यूलिंग के साथ समस्या को हल करता है और प्रदान करता है सभी आकारों और धारियों की कंपनियों के लिए कई वाणिज्यिक और खुले वितरण के साथ एक लगातार विकसित होने वाला मंच। इसके अलावा, लोकप्रियता के मद्देनजर, अधिकांश पहले से ही अपने स्वयं के कुछ इंस्टॉलेशन हासिल करने में कामयाब रहे हैं और इसके उपयोग में अपनी विशेषज्ञता बढ़ा दी है, जो इस कदम को सरल बनाता है।

संस्करण 2.3.0 से शुरू करके, अपाचे स्पार्क ने कुबेरनेट्स क्लस्टर में कार्यों को चलाने के लिए आधिकारिक समर्थन प्राप्त किया और आज, हम इस दृष्टिकोण की वर्तमान परिपक्वता, इसके उपयोग के लिए विभिन्न विकल्पों और कार्यान्वयन के दौरान आने वाले नुकसान के बारे में बात करेंगे।

सबसे पहले, आइए अपाचे स्पार्क पर आधारित कार्यों और अनुप्रयोगों को विकसित करने की प्रक्रिया को देखें और उन विशिष्ट मामलों पर प्रकाश डालें जिनमें आपको कुबेरनेट्स क्लस्टर पर एक कार्य चलाने की आवश्यकता होती है। इस पोस्ट को तैयार करने में, ओपनशिफ्ट का उपयोग वितरण के रूप में किया जाता है और इसकी कमांड लाइन उपयोगिता (ओसी) से संबंधित कमांड दिए जाएंगे। अन्य Kubernetes वितरणों के लिए, मानक Kubernetes कमांड लाइन उपयोगिता (kubectl) या उनके एनालॉग्स (उदाहरण के लिए, oc adm नीति के लिए) से संबंधित कमांड का उपयोग किया जा सकता है।

पहला उपयोग मामला - स्पार्क-सबमिट

कार्यों और अनुप्रयोगों के विकास के दौरान, डेवलपर को डेटा परिवर्तन को डीबग करने के लिए कार्यों को चलाने की आवश्यकता होती है। सैद्धांतिक रूप से, इन उद्देश्यों के लिए स्टब्स का उपयोग किया जा सकता है, लेकिन अंत प्रणालियों के वास्तविक (यद्यपि परीक्षण) उदाहरणों की भागीदारी के साथ विकास कार्यों के इस वर्ग में तेज और बेहतर साबित हुआ है। ऐसे मामले में जब हम एंड सिस्टम के वास्तविक उदाहरणों पर डिबग करते हैं, तो दो परिदृश्य संभव होते हैं:

• डेवलपर स्थानीय रूप से स्टैंडअलोन मोड में स्पार्क कार्य चलाता है;

  

• एक डेवलपर परीक्षण लूप में कुबेरनेट्स क्लस्टर पर स्पार्क कार्य चलाता है।

  

पहले विकल्प में अस्तित्व का अधिकार है, लेकिन इसके कई नुकसान भी हैं:

• प्रत्येक डेवलपर को कार्यस्थल से उसके लिए आवश्यक अंतिम प्रणालियों के सभी उदाहरणों तक पहुंच प्रदान की जानी चाहिए;
• विकसित किए जा रहे कार्य को चलाने के लिए कार्यशील मशीन पर पर्याप्त मात्रा में संसाधनों की आवश्यकता होती है।

दूसरे विकल्प में ये नुकसान नहीं हैं, क्योंकि कुबेरनेट्स क्लस्टर का उपयोग आपको चल रहे कार्यों के लिए आवश्यक संसाधन पूल आवंटित करने और अंतिम सिस्टम उदाहरणों तक आवश्यक पहुंच प्रदान करने की अनुमति देता है, कुबेरनेट्स रोल मॉडल का उपयोग करके लचीले ढंग से उस तक पहुंच प्रदान करता है। विकास दल के सभी सदस्य। आइए इसे पहले उपयोग के मामले के रूप में उजागर करें - एक परीक्षण सर्किट में कुबेरनेट्स क्लस्टर पर एक स्थानीय डेवलपर मशीन से स्पार्क कार्यों को लॉन्च करना।

आइए स्थानीय स्तर पर चलाने के लिए स्पार्क को स्थापित करने की प्रक्रिया के बारे में अधिक बात करें। स्पार्क का उपयोग शुरू करने के लिए आपको इसे इंस्टॉल करना होगा:

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

हम कुबेरनेट्स के साथ काम करने के लिए आवश्यक पैकेज एकत्र करते हैं:

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

एक पूर्ण निर्माण में बहुत समय लगता है, और डॉकर छवियां बनाने और उन्हें कुबेरनेट्स क्लस्टर पर चलाने के लिए, आपको वास्तव में केवल "असेंबली /" निर्देशिका से जार फ़ाइलों की आवश्यकता होती है, इसलिए आप केवल इस उपप्रोजेक्ट का निर्माण कर सकते हैं:

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

कुबेरनेट्स पर स्पार्क जॉब चलाने के लिए, आपको आधार छवि के रूप में उपयोग करने के लिए एक डॉकर छवि बनाने की आवश्यकता है। यहां 2 संभावित दृष्टिकोण हैं:

• उत्पन्न डॉकर छवि में निष्पादन योग्य स्पार्क कार्य कोड शामिल है;
• बनाई गई छवि में केवल स्पार्क और आवश्यक निर्भरताएं शामिल हैं, निष्पादन योग्य कोड को दूरस्थ रूप से होस्ट किया गया है (उदाहरण के लिए, एचडीएफएस में)।

सबसे पहले, आइए एक डॉकर छवि बनाएं जिसमें स्पार्क कार्य का एक परीक्षण उदाहरण हो। डॉकर छवियां बनाने के लिए, स्पार्क के पास "डॉकर-इमेज-टूल" नामक एक उपयोगिता है। आइए इस पर सहायता का अध्ययन करें:

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

इसकी मदद से आप डॉकर इमेज बना सकते हैं और उन्हें रिमोट रजिस्ट्रियों पर अपलोड कर सकते हैं, लेकिन डिफ़ॉल्ट रूप से इसके कई नुकसान हैं:

• बिना किसी असफलता के एक साथ 3 डॉकर छवियां बनाता है - स्पार्क, पाइस्पार्क और आर के लिए;
• आपको छवि नाम निर्दिष्ट करने की अनुमति नहीं देता.

इसलिए, हम नीचे दिए गए इस उपयोगिता के एक संशोधित संस्करण का उपयोग करेंगे:

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

इसकी मदद से, हम एक बुनियादी स्पार्क छवि को इकट्ठा करते हैं जिसमें स्पार्क का उपयोग करके पाई की गणना करने के लिए एक परीक्षण कार्य होता है (यहां {docker-registry-url} आपकी डॉकर छवि रजिस्ट्री का URL है, {repo} रजिस्ट्री के अंदर रिपॉजिटरी का नाम है, जो ओपनशिफ्ट में प्रोजेक्ट से मेल खाता है, {छवि-नाम} - छवि का नाम (यदि छवियों के तीन-स्तरीय पृथक्करण का उपयोग किया जाता है, उदाहरण के लिए, जैसे कि रेड हैट ओपनशिफ्ट छवियों की एकीकृत रजिस्ट्री में), {टैग} - इसका टैग छवि का संस्करण):

./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

कंसोल उपयोगिता का उपयोग करके ओकेडी क्लस्टर में लॉग इन करें (यहां {ओकेडी-एपीआई-यूआरएल} ओकेडी क्लस्टर एपीआई यूआरएल है):

oc login {OKD-API-URL}

आइए डॉकर रजिस्ट्री में प्राधिकरण के लिए वर्तमान उपयोगकर्ता का टोकन प्राप्त करें:

oc whoami -t

ओकेडी क्लस्टर की आंतरिक डॉकर रजिस्ट्री में लॉग इन करें (हम पासवर्ड के रूप में पिछले कमांड का उपयोग करके प्राप्त टोकन का उपयोग करते हैं):

docker login {docker-registry-url}

आइए एकत्रित डॉकर छवि को डॉकर रजिस्ट्री ओकेडी पर अपलोड करें:

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

आइए जांचें कि एकत्रित छवि ओकेडी में उपलब्ध है या नहीं। ऐसा करने के लिए, संबंधित प्रोजेक्ट की छवियों की सूची के साथ ब्राउज़र में यूआरएल खोलें (यहां {प्रोजेक्ट} ओपनशिफ्ट क्लस्टर के अंदर प्रोजेक्ट का नाम है, {ओकेडी-वेबयूआई-यूआरएल} ओपनशिफ्ट वेब कंसोल का यूआरएल है ) - https://{OKD-WEBUI-URL}/कंसोल /प्रोजेक्ट/{प्रोजेक्ट}/ब्राउज/इमेजेज/{इमेज-नाम}।

कार्यों को चलाने के लिए, पॉड्स को रूट के रूप में चलाने के विशेषाधिकारों के साथ एक सेवा खाता बनाया जाना चाहिए (हम इस बिंदु पर बाद में चर्चा करेंगे):

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

आइए स्पार्क कार्य को ओकेडी क्लस्टर में प्रकाशित करने के लिए स्पार्क-सबमिट कमांड चलाएं, जो बनाए गए सेवा खाते और डॉकर छवि को निर्दिष्ट करता है:

 /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

Здесь:

—नाम — उस कार्य का नाम जो कुबेरनेट्स पॉड्स के नाम के निर्माण में भाग लेगा;

-वर्ग - निष्पादन योग्य फ़ाइल का वर्ग, जिसे कार्य शुरू होने पर कहा जाता है;

—conf — स्पार्क कॉन्फ़िगरेशन पैरामीटर;

spark.executor.instances - लॉन्च करने के लिए स्पार्क निष्पादकों की संख्या;

spark.kubernetes.authenticate.driver.serviceAccountName - पॉड्स लॉन्च करते समय उपयोग किए जाने वाले कुबेरनेट्स सेवा खाते का नाम (कुबेरनेट्स एपीआई के साथ इंटरैक्ट करते समय सुरक्षा संदर्भ और क्षमताओं को परिभाषित करने के लिए);

spark.kubernetes.namespace — Kubernetes नेमस्पेस जिसमें ड्राइवर और एक्ज़ीक्यूटर पॉड लॉन्च किए जाएंगे;

spark.submit.deployMode - स्पार्क लॉन्च करने की विधि (मानक स्पार्क-सबमिट के लिए "क्लस्टर" का उपयोग किया जाता है, स्पार्क ऑपरेटर और स्पार्क "क्लाइंट" के बाद के संस्करणों के लिए);

spark.kubernetes.container.image - पॉड्स लॉन्च करने के लिए डॉकर छवि का उपयोग किया जाता है;

स्पार्क.मास्टर - कुबेरनेट्स एपीआई यूआरएल (बाहरी निर्दिष्ट है इसलिए पहुंच स्थानीय मशीन से होती है);

local:// डॉकर छवि के अंदर निष्पादन योग्य स्पार्क का पथ है।

हम संबंधित ओकेडी प्रोजेक्ट पर जाते हैं और बनाए गए पॉड्स का अध्ययन करते हैं - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods।

विकास प्रक्रिया को सरल बनाने के लिए, एक अन्य विकल्प का उपयोग किया जा सकता है, जिसमें स्पार्क की एक सामान्य आधार छवि बनाई जाती है, जिसका उपयोग सभी कार्यों को चलाने के लिए किया जाता है, और निष्पादन योग्य फ़ाइलों के स्नैपशॉट को बाहरी भंडारण (उदाहरण के लिए, Hadoop) में प्रकाशित किया जाता है और कॉल करते समय निर्दिष्ट किया जाता है स्पार्क-एक लिंक के रूप में सबमिट करें। इस मामले में, आप डॉकर छवियों को पुनर्निर्माण किए बिना स्पार्क कार्यों के विभिन्न संस्करण चला सकते हैं, उदाहरण के लिए, छवियों को प्रकाशित करने के लिए WebHDFS का उपयोग कर सकते हैं। हम एक फ़ाइल बनाने के लिए एक अनुरोध भेजते हैं (यहां {host} WebHDFS सेवा का होस्ट है, {port} WebHDFS सेवा का पोर्ट है, {path-to-file-on-hdfs} फ़ाइल का वांछित पथ है एचडीएफएस पर):

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

आपको इस तरह की प्रतिक्रिया प्राप्त होगी (यहां {स्थान} वह यूआरएल है जिसका उपयोग फ़ाइल डाउनलोड करने के लिए किया जाना चाहिए):

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

स्पार्क निष्पादन योग्य फ़ाइल को HDFS में लोड करें (यहां {path-to-local-file} वर्तमान होस्ट पर स्पार्क निष्पादन योग्य फ़ाइल का पथ है):

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

इसके बाद, हम एचडीएफएस पर अपलोड की गई स्पार्क फ़ाइल का उपयोग करके स्पार्क-सबमिट कर सकते हैं (यहां {क्लास-नाम} उस क्लास का नाम है जिसे कार्य पूरा करने के लिए लॉन्च करने की आवश्यकता है):

/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}

यह ध्यान दिया जाना चाहिए कि एचडीएफएस तक पहुंचने और कार्य को सुनिश्चित करने के लिए, आपको डॉकरफाइल और एंट्रीपॉइंट.श स्क्रिप्ट को बदलने की आवश्यकता हो सकती है - आश्रित पुस्तकालयों को /opt/spark/jars निर्देशिका में कॉपी करने के लिए डॉकरफाइल में एक निर्देश जोड़ें और एंट्रीपॉइंट में SPARK_CLASSPATH में HDFS कॉन्फ़िगरेशन फ़ाइल शामिल करें।

दूसरा उपयोग मामला - अपाचे लिवी

इसके अलावा, जब कोई कार्य विकसित किया जाता है और परिणाम का परीक्षण करने की आवश्यकता होती है, तो इसे सीआई/सीडी प्रक्रिया के हिस्से के रूप में लॉन्च करने और इसके निष्पादन की स्थिति पर नज़र रखने का सवाल उठता है। बेशक, आप इसे स्थानीय स्पार्क-सबमिट कॉल का उपयोग करके चला सकते हैं, लेकिन यह सीआई/सीडी बुनियादी ढांचे को जटिल बनाता है क्योंकि इसमें सीआई सर्वर एजेंटों/रनर पर स्पार्क को स्थापित और कॉन्फ़िगर करने और कुबेरनेट्स एपीआई तक पहुंच स्थापित करने की आवश्यकता होती है। इस मामले के लिए, लक्ष्य कार्यान्वयन ने कुबेरनेट्स क्लस्टर के अंदर होस्ट किए गए स्पार्क कार्यों को चलाने के लिए REST API के रूप में अपाचे लिवी का उपयोग करना चुना है। इसकी मदद से, आप नियमित कर्ल अनुरोधों का उपयोग करके कुबेरनेट्स क्लस्टर पर स्पार्क कार्य चला सकते हैं, जिसे किसी भी सीआई समाधान के आधार पर आसानी से कार्यान्वित किया जाता है, और कुबेरनेट्स क्लस्टर के अंदर इसका प्लेसमेंट कुबेरनेट्स एपीआई के साथ बातचीत करते समय प्रमाणीकरण की समस्या को हल करता है।

आइए इसे दूसरे उपयोग के मामले के रूप में उजागर करें - एक परीक्षण लूप में कुबेरनेट्स क्लस्टर पर सीआई/सीडी प्रक्रिया के हिस्से के रूप में स्पार्क कार्यों को चलाना।

Apache Livy के बारे में थोड़ा - यह एक HTTP सर्वर के रूप में काम करता है जो एक वेब इंटरफ़ेस और एक RESTful API प्रदान करता है जो आपको आवश्यक मापदंडों को पारित करके स्पार्क-सबमिट को दूरस्थ रूप से लॉन्च करने की अनुमति देता है। परंपरागत रूप से इसे एचडीपी वितरण के हिस्से के रूप में भेजा गया है, लेकिन इसे उपयुक्त मेनिफेस्ट और डॉकर छवियों के एक सेट का उपयोग करके ओकेडी या किसी अन्य कुबेरनेट्स इंस्टॉलेशन पर भी तैनात किया जा सकता है, जैसे कि यह - github.com/ttauveron/k8s-big-data-experiments/tree/master/livy-spark-2.3. हमारे मामले के लिए, एक समान डॉकर छवि बनाई गई थी, जिसमें निम्नलिखित डॉकरफाइल से स्पार्क संस्करण 2.4.5 शामिल था:

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"]

उत्पन्न छवि को आपके मौजूदा डॉकर रिपॉजिटरी, जैसे आंतरिक ओकेडी रिपॉजिटरी, में बनाया और अपलोड किया जा सकता है। इसे तैनात करने के लिए, निम्नलिखित मेनिफेस्ट का उपयोग करें ({रजिस्ट्री-यूआरएल} - डॉकर छवि रजिस्ट्री का यूआरएल, {छवि-नाम} - डॉकर छवि का नाम, {टैग} - डॉकर छवि टैग, {लिवी-यूआरएल} - वांछित यूआरएल जहां सर्वर लिवी तक पहुंच योग्य होगा; यदि रेड हैट ओपनशिफ्ट को कुबेरनेट्स वितरण के रूप में उपयोग किया जाता है तो "रूट" मेनिफेस्ट का उपयोग किया जाता है, अन्यथा नोडपोर्ट प्रकार के संबंधित इनग्रेस या सर्विस मेनिफेस्ट का उपयोग किया जाता है):

---
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

इसे लागू करने और पॉड को सफलतापूर्वक लॉन्च करने के बाद, लिवी ग्राफिकल इंटरफ़ेस इस लिंक पर उपलब्ध है: http://{livy-url}/ui। लिवी के साथ, हम उदाहरण के लिए, पोस्टमैन से REST अनुरोध का उपयोग करके अपने स्पार्क कार्य को प्रकाशित कर सकते हैं। अनुरोधों के साथ संग्रह का एक उदाहरण नीचे प्रस्तुत किया गया है (लॉन्च किए गए कार्य के संचालन के लिए आवश्यक चर के साथ कॉन्फ़िगरेशन तर्क "आर्ग्स" सरणी में पारित किए जा सकते हैं):

{
    "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": {}
}

आइए संग्रह से पहला अनुरोध निष्पादित करें, ओकेडी इंटरफ़ेस पर जाएं और जांचें कि कार्य सफलतापूर्वक लॉन्च किया गया है - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods। उसी समय, लिवी इंटरफ़ेस (http://{livy-url}/ui) में एक सत्र दिखाई देगा, जिसके भीतर, लिवी एपीआई या ग्राफिकल इंटरफ़ेस का उपयोग करके, आप कार्य की प्रगति को ट्रैक कर सकते हैं और सत्र का अध्ययन कर सकते हैं लॉग.

अब आइए दिखाते हैं कि लिवी कैसे काम करती है। ऐसा करने के लिए, आइए लिवी सर्वर के साथ पॉड के अंदर लिवी कंटेनर के लॉग की जांच करें - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods/{livy-pod-name }?टैब=लॉग. उनसे हम देख सकते हैं कि "लिवी" नामक कंटेनर में लिवी रेस्ट एपीआई को कॉल करते समय, एक स्पार्क-सबमिट निष्पादित होता है, जैसा कि हमने ऊपर इस्तेमाल किया था (यहां {लिवी-पॉड-नाम} निर्मित पॉड का नाम है) लिवी सर्वर के साथ)। संग्रह एक दूसरी क्वेरी भी पेश करता है जो आपको उन कार्यों को चलाने की अनुमति देता है जो लिवी सर्वर का उपयोग करके स्पार्क निष्पादन योग्य को दूरस्थ रूप से होस्ट करते हैं।

तीसरा उपयोग मामला - स्पार्क ऑपरेटर

अब जबकि कार्य का परीक्षण हो चुका है तो इसे नियमित रूप से चलाने का प्रश्न उठता है। कुबेरनेट्स क्लस्टर में कार्यों को नियमित रूप से चलाने का मूल तरीका क्रोनजॉब इकाई है और आप इसका उपयोग कर सकते हैं, लेकिन फिलहाल कुबेरनेट्स में अनुप्रयोगों को प्रबंधित करने के लिए ऑपरेटरों का उपयोग बहुत लोकप्रिय है और स्पार्क के लिए एक काफी परिपक्व ऑपरेटर है, जो भी है एंटरप्राइज़-स्तरीय समाधानों में उपयोग किया जाता है (उदाहरण के लिए, लाइटबेंड फास्टडाटा प्लेटफ़ॉर्म)। हम इसका उपयोग करने की सलाह देते हैं - स्पार्क के वर्तमान स्थिर संस्करण (2.4.5) में कुबेरनेट्स में स्पार्क कार्यों को चलाने के लिए सीमित कॉन्फ़िगरेशन विकल्प हैं, जबकि अगला प्रमुख संस्करण (3.0.0) कुबेरनेट्स के लिए पूर्ण समर्थन की घोषणा करता है, लेकिन इसकी रिलीज की तारीख अज्ञात बनी हुई है . स्पार्क ऑपरेटर महत्वपूर्ण कॉन्फ़िगरेशन विकल्प जोड़कर इस कमी की भरपाई करता है (उदाहरण के लिए, स्पार्क पॉड्स में Hadoop एक्सेस कॉन्फ़िगरेशन के साथ कॉन्फ़िगमैप माउंट करना) और नियमित रूप से निर्धारित कार्य को चलाने की क्षमता।

आइए इसे तीसरे उपयोग के मामले के रूप में उजागर करें - उत्पादन लूप में कुबेरनेट्स क्लस्टर पर स्पार्क कार्यों को नियमित रूप से चलाना।

स्पार्क ऑपरेटर खुला स्रोत है और Google क्लाउड प्लेटफ़ॉर्म के भीतर विकसित किया गया है - github.com/GoogleCloudPlatform/spark-on-k8s-operator. इसकी स्थापना 3 तरीकों से की जा सकती है:

1. लाइटबेंड फास्टडाटा प्लेटफ़ॉर्म/क्लाउडफ़्लो इंस्टॉलेशन के भाग के रूप में;
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) से मैनिफ़ेस्ट का उपयोग करना। यह निम्नलिखित पर ध्यान देने योग्य है - क्लाउडफ्लो में एपीआई संस्करण v1beta1 वाला एक ऑपरेटर शामिल है। यदि इस प्रकार की स्थापना का उपयोग किया जाता है, तो स्पार्क एप्लिकेशन मेनिफेस्ट विवरण उपयुक्त एपीआई संस्करण के साथ Git में उदाहरण टैग पर आधारित होना चाहिए, उदाहरण के लिए, "v1beta1-0.9.0-2.4.0"। ऑपरेटर का संस्करण "संस्करण" शब्दकोश में ऑपरेटर में शामिल सीआरडी के विवरण में पाया जा सकता है:

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

यदि ऑपरेटर सही ढंग से स्थापित है, तो स्पार्क ऑपरेटर के साथ एक सक्रिय पॉड संबंधित प्रोजेक्ट में दिखाई देगा (उदाहरण के लिए, क्लाउडफ्लो इंस्टॉलेशन के लिए क्लाउडफ्लो स्पेस में क्लाउडफ्लो-एफडीपी-स्पार्कऑपरेटर) और "स्पार्कएप्लिकेशन" नामक संबंधित कुबेरनेट्स संसाधन प्रकार दिखाई देगा। . आप निम्नलिखित कमांड के साथ उपलब्ध स्पार्क एप्लिकेशन का पता लगा सकते हैं:

oc get sparkapplications -n {project}

स्पार्क ऑपरेटर का उपयोग करके कार्य चलाने के लिए आपको 3 चीजें करने की आवश्यकता है:

• एक डॉकर छवि बनाएं जिसमें सभी आवश्यक लाइब्रेरी, साथ ही कॉन्फ़िगरेशन और निष्पादन योग्य फ़ाइलें शामिल हों। लक्ष्य चित्र में, यह सीआई/सीडी चरण में बनाई गई एक छवि है और परीक्षण क्लस्टर पर परीक्षण किया गया है;
• कुबेरनेट्स क्लस्टर से पहुंच योग्य रजिस्ट्री में एक डॉकर छवि प्रकाशित करें;
• "स्पार्कएप्लिकेशन" प्रकार और लॉन्च किए जाने वाले कार्य के विवरण के साथ एक मैनिफ़ेस्ट तैयार करें। उदाहरण मैनिफ़ेस्ट आधिकारिक भंडार में उपलब्ध हैं (उदा. github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/v1beta1-0.9.0-2.4.0/examples/spark-pi.yaml). घोषणापत्र के बारे में ध्यान देने योग्य महत्वपूर्ण बिंदु हैं:
  1. "apiVersion" शब्दकोष में ऑपरेटर संस्करण के अनुरूप API संस्करण अवश्य दर्शाया जाना चाहिए;
  2. "मेटाडेटा.नेमस्पेस" शब्दकोश में उस नेमस्पेस को इंगित करना होगा जिसमें एप्लिकेशन लॉन्च किया जाएगा;
  3. "spec.image" शब्दकोश में एक सुलभ रजिस्ट्री में बनाई गई डॉकर छवि का पता होना चाहिए;
  4. "spec.mainClass" शब्दकोश में स्पार्क टास्क क्लास शामिल होना चाहिए जिसे प्रक्रिया शुरू होने पर चलाने की आवश्यकता होती है;
  5. "spec.mainApplicationFile" शब्दकोश में निष्पादन योग्य जार फ़ाइल का पथ होना चाहिए;
  6. "spec.sparkVersion" शब्दकोष में उपयोग किए जा रहे स्पार्क के संस्करण का संकेत होना चाहिए;
  7. "spec.driver.serviceAccount" शब्दकोश को संबंधित कुबेरनेट्स नेमस्पेस के भीतर सेवा खाता निर्दिष्ट करना होगा जिसका उपयोग एप्लिकेशन को चलाने के लिए किया जाएगा;
  8. "spec.executor" शब्दकोष में एप्लिकेशन को आवंटित संसाधनों की संख्या का संकेत होना चाहिए;
  9. "spec.volumeMounts" शब्दकोश को स्थानीय निर्देशिका निर्दिष्ट करनी होगी जिसमें स्थानीय स्पार्क कार्य फ़ाइलें बनाई जाएंगी।

मेनिफेस्ट जनरेट करने का एक उदाहरण (यहां {स्पार्क-सर्विस-अकाउंट} स्पार्क कार्यों को चलाने के लिए कुबेरनेट्स क्लस्टर के अंदर एक सेवा खाता है):

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"

यह मेनिफेस्ट एक सेवा खाता निर्दिष्ट करता है जिसके लिए, मेनिफेस्ट प्रकाशित करने से पहले, आपको आवश्यक भूमिका बाइंडिंग बनानी होगी जो कुबेरनेट्स एपीआई (यदि आवश्यक हो) के साथ बातचीत करने के लिए स्पार्क एप्लिकेशन के लिए आवश्यक पहुंच अधिकार प्रदान करती है। हमारे मामले में, एप्लिकेशन को पॉड्स बनाने के अधिकारों की आवश्यकता है। आइए आवश्यक भूमिका बंधन बनाएँ:

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

यह भी ध्यान देने योग्य है कि इस मैनिफ़ेस्ट विनिर्देश में एक "hadoopConfigMap" पैरामीटर शामिल हो सकता है, जो आपको डॉकर छवि में संबंधित फ़ाइल को पहले रखे बिना Hadoop कॉन्फ़िगरेशन के साथ एक कॉन्फ़िगमैप निर्दिष्ट करने की अनुमति देता है। यह कार्यों को नियमित रूप से चलाने के लिए भी उपयुक्त है - "शेड्यूल" पैरामीटर का उपयोग करके, किसी दिए गए कार्य को चलाने के लिए एक शेड्यूल निर्दिष्ट किया जा सकता है।

उसके बाद, हम अपने मेनिफेस्ट को spark-pi.yaml फ़ाइल में सहेजते हैं और इसे अपने Kubernetes क्लस्टर पर लागू करते हैं:

oc apply -f spark-pi.yaml

यह "स्पार्कएप्लिकेशन्स" प्रकार का एक ऑब्जेक्ट बनाएगा:

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

इस स्थिति में, एक एप्लिकेशन के साथ एक पॉड बनाया जाएगा, जिसकी स्थिति बनाए गए "स्पार्कएप्लिकेशन्स" में प्रदर्शित की जाएगी। आप इसे निम्न आदेश से देख सकते हैं:

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

कार्य पूरा होने पर, POD "पूर्ण" स्थिति में चला जाएगा, जो "स्पार्कएप्लिकेशन" में भी अपडेट हो जाएगा। एप्लिकेशन लॉग को ब्राउज़र में या निम्न कमांड का उपयोग करके देखा जा सकता है (यहां {sparkapplications-pod-name} चल रहे कार्य के पॉड का नाम है):

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

स्पार्क कार्यों को विशेष स्पार्कक्टल उपयोगिता का उपयोग करके भी प्रबंधित किया जा सकता है। इसे स्थापित करने के लिए, रिपॉजिटरी को उसके स्रोत कोड के साथ क्लोन करें, गो इंस्टॉल करें और इस उपयोगिता का निर्माण करें:

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

आइए चल रहे स्पार्क कार्यों की सूची की जाँच करें:

sparkctl list -n {project}

आइए स्पार्क कार्य के लिए एक विवरण बनाएं:

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}

आइए चल रहे स्पार्क कार्यों की सूची की जाँच करें:

sparkctl list -n {project}

आइए लॉन्च किए गए स्पार्क कार्य की घटनाओं की सूची की जांच करें:

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

आइए चल रहे स्पार्क कार्य की स्थिति की जाँच करें:

sparkctl status spark-pi -n {project}

अंत में, मैं कुबेरनेट्स में स्पार्क के वर्तमान स्थिर संस्करण (2.4.5) का उपयोग करने के खोजे गए नुकसानों पर विचार करना चाहूंगा:

1. पहला और, शायद, मुख्य नुकसान डेटा स्थानीयता की कमी है। YARN की सभी कमियों के बावजूद, इसका उपयोग करने के फायदे भी थे, उदाहरण के लिए, कोड को डेटा तक पहुंचाने का सिद्धांत (डेटा से कोड के बजाय)। इसके लिए धन्यवाद, स्पार्क कार्यों को उन नोड्स पर निष्पादित किया गया जहां गणना में शामिल डेटा स्थित था, और नेटवर्क पर डेटा वितरित करने में लगने वाला समय काफी कम हो गया था। कुबेरनेट्स का उपयोग करते समय, हमें किसी कार्य में शामिल डेटा को पूरे नेटवर्क में स्थानांतरित करने की आवश्यकता का सामना करना पड़ता है। यदि वे पर्याप्त बड़े हैं, तो कार्य निष्पादन समय में काफी वृद्धि हो सकती है, और उनके अस्थायी भंडारण के लिए स्पार्क कार्य उदाहरणों को आवंटित डिस्क स्थान की काफी बड़ी मात्रा की भी आवश्यकता होती है। इस नुकसान को विशेष सॉफ़्टवेयर का उपयोग करके कम किया जा सकता है जो कुबेरनेट्स (उदाहरण के लिए, ऑलक्सियो) में डेटा स्थानीयता सुनिश्चित करता है, लेकिन इसका वास्तव में मतलब कुबेरनेट्स क्लस्टर के नोड्स पर डेटा की एक पूरी प्रतिलिपि संग्रहीत करने की आवश्यकता है।
2. दूसरा महत्वपूर्ण नुकसान सुरक्षा है. डिफ़ॉल्ट रूप से, स्पार्क कार्यों को चलाने के संबंध में सुरक्षा-संबंधित सुविधाएं अक्षम हैं, केर्बरोस का उपयोग आधिकारिक दस्तावेज में शामिल नहीं है (हालांकि संबंधित विकल्प संस्करण 3.0.0 में पेश किए गए थे, जिसके लिए अतिरिक्त काम की आवश्यकता होगी), और सुरक्षा दस्तावेज के लिए स्पार्क (https://spark.apache.org/docs/2.4.5/security.html) का उपयोग करके केवल YARN, मेसोस और स्टैंडअलोन क्लस्टर प्रमुख स्टोर के रूप में दिखाई देते हैं। उसी समय, जिस उपयोगकर्ता के तहत स्पार्क कार्य लॉन्च किए गए हैं, उसे सीधे निर्दिष्ट नहीं किया जा सकता है - हम केवल उस सेवा खाते को निर्दिष्ट करते हैं जिसके तहत यह काम करेगा, और उपयोगकर्ता को कॉन्फ़िगर की गई सुरक्षा नीतियों के आधार पर चुना जाता है। इस संबंध में, या तो रूट उपयोगकर्ता का उपयोग किया जाता है, जो उत्पादक वातावरण में सुरक्षित नहीं है, या यादृच्छिक यूआईडी वाले उपयोगकर्ता का उपयोग किया जाता है, जो डेटा तक पहुंच अधिकार वितरित करते समय असुविधाजनक है (इसे PodSecurityPolicies बनाकर और उन्हें लिंक करके हल किया जा सकता है) संबंधित सेवा खाते)। वर्तमान में, समाधान या तो सभी आवश्यक फ़ाइलों को सीधे डॉकर छवि में रखना है, या आपके संगठन में अपनाए गए रहस्यों को संग्रहीत करने और पुनर्प्राप्त करने के लिए तंत्र का उपयोग करने के लिए स्पार्क लॉन्च स्क्रिप्ट को संशोधित करना है।
3. कुबेरनेट्स का उपयोग करके स्पार्क नौकरियां चलाना आधिकारिक तौर पर अभी भी प्रयोगात्मक मोड में है और भविष्य में उपयोग की जाने वाली कलाकृतियों (कॉन्फ़िगरेशन फ़ाइलें, डॉकर बेस छवियां और लॉन्च स्क्रिप्ट) में महत्वपूर्ण बदलाव हो सकते हैं। और वास्तव में, सामग्री तैयार करते समय, संस्करण 2.3.0 और 2.4.5 का परीक्षण किया गया, व्यवहार काफी भिन्न था।

आइए अपडेट की प्रतीक्षा करें - स्पार्क का एक नया संस्करण (3.0.0) हाल ही में जारी किया गया था, जिसने कुबेरनेट्स पर स्पार्क के काम में महत्वपूर्ण बदलाव लाए, लेकिन इस संसाधन प्रबंधक के लिए समर्थन की प्रयोगात्मक स्थिति बरकरार रखी। शायद अगला अपडेट आपके सिस्टम की सुरक्षा के डर के बिना और कार्यात्मक घटकों को स्वतंत्र रूप से संशोधित करने की आवश्यकता के बिना, YARN को छोड़ने और कुबेरनेट्स पर स्पार्क कार्यों को चलाने की पूरी तरह से अनुशंसा करना संभव बना देगा।

समाप्त।

स्रोत: www.habr.com