Kubernetes मा Apache Spark चलाउँदै

प्रिय पाठकहरू, शुभ दिउँसो। आज हामी Apache Spark र यसको विकास सम्भावनाहरूको बारेमा थोरै कुरा गर्नेछौं।

बिग डाटाको आधुनिक संसारमा, Apache Spark ब्याच डेटा प्रशोधन कार्यहरू विकास गर्नको लागि वास्तविक मानक हो। थप रूपमा, यो स्ट्रिमिङ अनुप्रयोगहरू सिर्जना गर्न पनि प्रयोग गरिन्छ जुन माइक्रो ब्याच अवधारणा, प्रशोधन र ढुवानी डाटा साना भागहरूमा काम गर्दछ (स्पार्क स्ट्रक्चर्ड स्ट्रिमिङ)। र परम्परागत रूपमा यो समग्र Hadoop स्ट्याकको भाग भएको छ, स्रोत प्रबन्धकको रूपमा YARN (वा केहि अवस्थामा Apache Mesos) प्रयोग गरी। 2020 सम्म, सभ्य Hadoop वितरणको कमीको कारणले यसको परम्परागत रूपमा यसको प्रयोग धेरै कम्पनीहरूको लागि प्रश्नमा छ - HDP र CDH को विकास रोकिएको छ, CDH राम्रोसँग विकसित भएको छैन र उच्च लागत छ, र बाँकी Hadoop आपूर्तिकर्ताहरू छन्। कि त अस्तित्व समाप्त भयो वा अन्धकार भविष्य छ। तसर्थ, Kubernetes को प्रयोग गरेर Apache Spark को प्रक्षेपण समुदाय र ठूला कम्पनीहरु माझ बढ्दो चासोको विषय हो - निजी र सार्वजनिक क्लाउडहरुमा कन्टेनर अर्केस्ट्रेसन र संसाधन व्यवस्थापन मा एक मानक बनेको छ, यसले YARN मा स्पार्क कार्यहरु को असुविधाजनक संसाधन तालिका संग समस्या समाधान गर्दछ र प्रदान गर्दछ। सबै आकार र स्ट्राइपका कम्पनीहरूको लागि धेरै व्यावसायिक र खुला वितरणको साथ स्थिर रूपमा विकास भइरहेको प्लेटफर्म। थप रूपमा, लोकप्रियताको आधारमा, धेरैले पहिले नै आफ्नै स्थापनाहरूको एक जोडी प्राप्त गर्न व्यवस्थित गरिसकेका छन् र यसको प्रयोगमा आफ्नो विशेषज्ञता बढाएका छन्, जसले चाललाई सरल बनाउँछ।

संस्करण 2.3.0 बाट सुरु गर्दै, Apache Spark ले Kubernetes क्लस्टरमा चलिरहेको कार्यहरूको लागि आधिकारिक समर्थन प्राप्त गर्यो र आज, हामी यस दृष्टिकोणको हालको परिपक्वता, यसको प्रयोगका लागि विभिन्न विकल्पहरू र कार्यान्वयनको क्रममा सामना गर्ने समस्याहरूको बारेमा कुरा गर्नेछौं।

सबैभन्दा पहिले, Apache Spark मा आधारित कार्यहरू र अनुप्रयोगहरू विकास गर्ने प्रक्रियालाई हेरौं र विशिष्ट केसहरूलाई हाइलाइट गरौं जसमा तपाईंले Kubernetes क्लस्टरमा कार्य चलाउन आवश्यक छ। यो पोस्ट तयार गर्दा, OpenShift लाई वितरणको रूपमा प्रयोग गरिन्छ र यसको कमाण्ड लाइन उपयोगिता (oc) सँग सम्बन्धित आदेशहरू दिइनेछ। अन्य Kubernetes वितरणहरूको लागि, मानक Kubernetes आदेश लाइन उपयोगिता (kubectl) वा तिनीहरूका एनालॉगहरू (उदाहरणका लागि, oc adm नीतिको लागि) बाट सम्बन्धित आदेशहरू प्रयोग गर्न सकिन्छ।

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

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

• विकासकर्ताले स्ट्यान्डअलोन मोडमा स्थानीय रूपमा स्पार्क कार्य चलाउँछ;

  

• एक विकासकर्ताले परीक्षण लुपमा Kubernetes क्लस्टरमा स्पार्क कार्य चलाउँछ।

  

पहिलो विकल्पको अस्तित्वको अधिकार छ, तर यसले धेरै बेफाइदाहरू समावेश गर्दछ:

• प्रत्येक विकासकर्तालाई कार्यस्थलबाट उसलाई आवश्यक पर्ने अन्तिम प्रणालीहरूको सबै उदाहरणहरूमा पहुँच प्रदान गरिनुपर्छ।
• विकास भइरहेको कार्य चलाउनको लागि काम गर्ने मेसिनमा पर्याप्त मात्रामा स्रोतहरू आवश्यक पर्दछ।

दोस्रो विकल्पमा यी बेफाइदाहरू छैनन्, किनकि Kubernetes क्लस्टरको प्रयोगले तपाईंलाई कार्यहरू चलाउनको लागि आवश्यक स्रोत पोखरी आवंटित गर्न र यसलाई अन्तिम प्रणाली उदाहरणहरूमा आवश्यक पहुँच प्रदान गर्न अनुमति दिन्छ, लचिलो रूपमा Kubernetes रोल मोडेल प्रयोग गरेर यसमा पहुँच प्रदान गर्दछ। विकास टोलीका सबै सदस्यहरू। यसलाई पहिलो प्रयोग केसको रूपमा हाइलाइट गरौं - एक स्थानीय विकासकर्ता मेसिनबाट कुबर्नेट्स क्लस्टरमा परीक्षण लुपमा स्पार्क कार्यहरू सुरु गर्दै।

स्थानीय रूपमा चलाउन स्पार्क स्थापना गर्ने प्रक्रियाको बारेमा थप कुरा गरौं। स्पार्क प्रयोग गर्न सुरु गर्न तपाईंले यसलाई स्थापना गर्न आवश्यक छ:

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

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

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

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

• उत्पन्न डकर छविमा कार्यान्वयन योग्य स्पार्क कार्य कोड समावेश छ;
• सिर्जना गरिएको छविले स्पार्क र आवश्यक निर्भरताहरू मात्र समावेश गर्दछ, कार्यान्वयन योग्य कोड टाढाबाट होस्ट गरिएको छ (उदाहरणका लागि, HDFS मा)।

पहिले, स्पार्क कार्यको परीक्षण उदाहरण सहितको डकर छवि निर्माण गरौं। डकर छविहरू सिर्जना गर्न, स्पार्कसँग "डकर-छवि-उपकरण" भनिने उपयोगिता छ। यसमा मद्दत अध्ययन गरौं:

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

यसको मद्दतले, तपाइँ डकर छविहरू सिर्जना गर्न सक्नुहुन्छ र तिनीहरूलाई रिमोट रेजिस्ट्रीहरूमा अपलोड गर्न सक्नुहुन्छ, तर पूर्वनिर्धारित रूपमा यसमा धेरै बेफाइदाहरू छन्:

• बिना असफलताले एकैचोटि 3 डकर छविहरू सिर्जना गर्दछ - स्पार्क, 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

यसको मद्दतले, हामी स्पार्क प्रयोग गरेर Pi गणना गर्नको लागि परीक्षण कार्य सहितको आधारभूत स्पार्क छविलाई भेला गर्छौं (यहाँ {docker-registry-url} तपाईंको डकर छवि रजिस्ट्रीको 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}

डकर रजिस्ट्रीमा प्राधिकरणको लागि हालको प्रयोगकर्ताको टोकन प्राप्त गरौं:

oc whoami -t

OKD क्लस्टरको आन्तरिक डकर रजिस्ट्रीमा लग इन गर्नुहोस् (हामी पासवर्डको रूपमा अघिल्लो आदेश प्रयोग गरेर प्राप्त टोकन प्रयोग गर्दछौं):

docker login {docker-registry-url}

डकर रजिस्ट्री 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}।

कार्यहरू चलाउनको लागि, रुटको रूपमा पोडहरू चलाउनको लागि विशेषाधिकारहरूसँग सेवा खाता सिर्जना गर्नुपर्छ (हामी यस बिन्दुलाई पछि छलफल गर्नेछौं):

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

OKD क्लस्टरमा स्पार्क कार्य प्रकाशित गर्न स्पार्क-सबमिट आदेश चलाउनुहोस्, सिर्जना गरिएको सेवा खाता र डकर छवि निर्दिष्ट गर्नुहोस्:

 /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 - डकर छवि पोडहरू सुरु गर्न प्रयोग गरियो;

spark.master — Kubernetes API URL (बाह्य निर्दिष्ट गरिएको छ त्यसैले पहुँच स्थानीय मेसिनबाट हुन्छ);

local:// डकर छवि भित्र स्पार्क कार्यान्वयनयोग्य मार्ग हो।

हामी सम्बन्धित OKD परियोजनामा ​​जान्छौं र सिर्जना गरिएका पोडहरू अध्ययन गर्छौं - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods।

विकास प्रक्रियालाई सरल बनाउन, अर्को विकल्प प्रयोग गर्न सकिन्छ, जसमा स्पार्कको साझा आधार छवि बनाइन्छ, चलाउनका लागि सबै कार्यहरूद्वारा प्रयोग गरिन्छ, र कार्यान्वयनयोग्य फाइलहरूको स्न्यापसटहरू बाह्य भण्डारणमा प्रकाशित गरिन्छ (उदाहरणका लागि, Hadoop) र कल गर्दा निर्दिष्ट गरिन्छ। स्पार्क-लिंकको रूपमा पेश गर्नुहोस्। यस अवस्थामा, तपाईंले डकर छविहरू पुन: निर्माण नगरी स्पार्क कार्यहरूको विभिन्न संस्करणहरू चलाउन सक्नुहुन्छ, उदाहरणका लागि, छविहरू प्रकाशित गर्न 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

स्पार्क कार्यान्वयनयोग्य फाइललाई HDFS मा लोड गर्नुहोस् (यहाँ {path-to-local-file} हालको होस्टमा स्पार्क कार्यान्वयनयोग्य फाइलको मार्ग हो):

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

यसपछि, हामी HDFS मा अपलोड गरिएको स्पार्क फाइल प्रयोग गरेर स्पार्क-सबमिट गर्न सक्छौं (यहाँ {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 स्क्रिप्ट परिवर्तन गर्न आवश्यक पर्दछ - /opt/spark/jars डाइरेक्टरीमा निर्भर पुस्तकालयहरू प्रतिलिपि गर्न Dockerfile मा निर्देशन थप्नुहोस् र HDFS कन्फिगरेसन फाइल SPARK_CLASSPATH मा प्रविष्टि बिन्दुमा समावेश गर्नुहोस्।

दोस्रो प्रयोग केस - Apache Livy

यसबाहेक, जब कुनै कार्यको विकास हुन्छ र परिणाम परीक्षण गर्न आवश्यक हुन्छ, प्रश्न उठ्छ CI/CD प्रक्रियाको एक भागको रूपमा सुरू गर्ने र यसको कार्यान्वयनको स्थिति ट्र्याक गर्ने। अवश्य पनि, तपाइँ यसलाई स्थानीय स्पार्क-सबमिट कल प्रयोग गरेर चलाउन सक्नुहुन्छ, तर यसले CI/CD पूर्वाधारलाई जटिल बनाउँछ किनकि यसले CI सर्भर एजेन्टहरू/धावकहरूमा स्पार्क स्थापना र कन्फिगर गर्न र Kubernetes API मा पहुँच सेटअप गर्न आवश्यक छ। यस अवस्थामा, लक्ष्य कार्यान्वयनले कुबेरनेट क्लस्टर भित्र होस्ट गरिएका स्पार्क कार्यहरू चलाउनको लागि REST API को रूपमा Apache Livy प्रयोग गर्न रोजेको छ। यसको मद्दतले, तपाइँ नियमित कर्ल अनुरोधहरू प्रयोग गरेर कुबर्नेट्स क्लस्टरमा स्पार्क कार्यहरू चलाउन सक्नुहुन्छ, जुन सजिलैसँग कुनै पनि CI समाधानको आधारमा लागू हुन्छ, र Kubernetes क्लस्टर भित्र यसको प्लेसमेन्टले Kubernetes API सँग अन्तरक्रिया गर्दा प्रमाणीकरणको समस्या समाधान गर्दछ।

यसलाई दोस्रो प्रयोग केसको रूपमा हाइलाइट गरौं - एक परीक्षण लुपमा कुबर्नेट्स क्लस्टरमा CI/CD प्रक्रियाको भागको रूपमा स्पार्क कार्यहरू चलाउँदै।

Apache Livy को बारेमा थोरै - यसले HTTP सर्भरको रूपमा काम गर्दछ जसले वेब इन्टरफेस र RESTful API प्रदान गर्दछ जसले तपाईंलाई आवश्यक प्यारामिटरहरू पार गरेर टाढाबाट स्पार्क-सबमिट सुरु गर्न अनुमति दिन्छ। परम्परागत रूपमा यो HDP वितरणको भागको रूपमा पठाइएको छ, तर उपयुक्त manifest र डकर छविहरूको सेट प्रयोग गरेर OKD वा कुनै अन्य Kubernetes स्थापनामा पनि प्रयोग गर्न सकिन्छ, जस्तै यो - 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"]

उत्पन्न छवि निर्माण गर्न सकिन्छ र तपाईंको अवस्थित डकर रिपोजिटरीमा अपलोड गर्न सकिन्छ, जस्तै आन्तरिक OKD भण्डार। यसलाई प्रयोग गर्नको लागि, निम्न manifest प्रयोग गर्नुहोस् ({registry-url} - डकर छवि रजिस्ट्रीको URL, {image-name} - डकर छवि नाम, {tag} - Docker छवि ट्याग, {livy-url} - इच्छित URL जहाँ सर्भर पहुँचयोग्य Livy हुनेछ; यदि Red Hat OpenShift Kubernetes वितरणको रूपमा प्रयोग गरिन्छ भने "Route" manifest प्रयोग गरिन्छ, अन्यथा NodePort प्रकारको सम्बन्धित Ingress वा Service manifest प्रयोग गरिन्छ):

---
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 सँग, हामी हाम्रो स्पार्क कार्यलाई REST अनुरोध प्रयोग गरेर प्रकाशित गर्न सक्छौं, उदाहरणका लागि, पोस्टम्यान। अनुरोधहरू सहितको सङ्कलनको एउटा उदाहरण तल प्रस्तुत गरिएको छ (सुरु गरिएको कार्यको सञ्चालनका लागि आवश्यक चरहरूसँग कन्फिगरेसन तर्कहरू "args" array मा पास गर्न सकिन्छ):

{
    "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 सर्भरको साथ पोड भित्र Livy कन्टेनरको लगहरू जाँच गरौं - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods/{livy-pod-name }?tab=logs। तिनीहरूबाट हामीले देख्न सक्छौं कि Livy REST API लाई "livy" नामको कन्टेनरमा कल गर्दा, हामीले माथि प्रयोग गरेको जस्तै स्पार्क-सबमिट कार्यान्वयन गरिन्छ (यहाँ {livy-pod-name} सिर्जना गरिएको पोडको नाम हो। Livy सर्भर संग)। सङ्कलनले दोस्रो क्वेरी पनि प्रस्तुत गर्दछ जसले तपाईंलाई टास्कहरू चलाउन अनुमति दिन्छ जसले Livy सर्भर प्रयोग गरेर टाढाबाट एक स्पार्क कार्यान्वयनयोग्य होस्ट गर्दछ।

तेस्रो प्रयोग केस - स्पार्क अपरेटर

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

यसलाई तेस्रो प्रयोग केसको रूपमा हाइलाइट गरौं - उत्पादन लुपमा Kubernetes क्लस्टरमा स्पार्क कार्यहरू नियमित रूपमा चलिरहेको छ।

स्पार्क अपरेटर खुला स्रोत हो र गुगल क्लाउड प्लेटफर्म भित्र विकसित गरिएको छ - 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. आधिकारिक भण्डारबाट manifests प्रयोग गर्दै (https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/tree/master/manifest)। यो निम्नलाई ध्यान दिन लायक छ - Cloudflow मा API संस्करण v1beta1 संग एक अपरेटर समावेश छ। यदि यस प्रकारको स्थापना प्रयोग गरिन्छ भने, स्पार्क एप्लिकेसन म्यानिफेस्ट विवरणहरू उपयुक्त API संस्करणको साथ Git मा उदाहरण ट्यागहरूमा आधारित हुनुपर्छ, उदाहरणका लागि, "v1beta1-0.9.0-2.4.0"। अपरेटरको संस्करण "संस्करण" शब्दकोशमा अपरेटरमा समावेश गरिएको CRD को विवरणमा फेला पार्न सकिन्छ:

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

यदि अपरेटर सही तरिकाले स्थापना गरिएको छ भने, स्पार्क अपरेटरसँगको सक्रिय पोड सम्बन्धित परियोजनामा ​​देखा पर्नेछ (उदाहरणका लागि, क्लाउडफ्लो स्थापनाको लागि क्लाउडफ्लो स्पेसमा क्लाउडफ्लो-एफडीपी-स्पार्कअपरेटर) र "स्पार्क अनुप्रयोगहरू" नामक सम्बन्धित Kubernetes स्रोत प्रकार देखा पर्नेछ। । तपाइँ निम्न आदेशको साथ उपलब्ध स्पार्क अनुप्रयोगहरू अन्वेषण गर्न सक्नुहुन्छ:

oc get sparkapplications -n {project}

स्पार्क अपरेटर प्रयोग गरेर कार्यहरू चलाउन तपाईंले 3 चीजहरू गर्न आवश्यक छ:

• डकर छवि सिर्जना गर्नुहोस् जसमा सबै आवश्यक पुस्तकालयहरू, साथै कन्फिगरेसन र कार्यान्वयनयोग्य फाइलहरू समावेश छन्। लक्षित चित्रमा, यो CI/CD चरणमा सिर्जना गरिएको र परीक्षण क्लस्टरमा परीक्षण गरिएको छवि हो;
• Kubernetes क्लस्टरबाट पहुँचयोग्य रजिस्ट्रीमा डकर छवि प्रकाशित गर्नुहोस्;
• "SparkApplication" प्रकार र सुरु गरिने कार्यको विवरणको साथ एक manifest उत्पन्न गर्नुहोस्। उदाहरण म्यानिफेस्टहरू आधिकारिक भण्डारमा उपलब्ध छन् (जस्तै। 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" शब्दकोशले पहुँचयोग्य रजिस्ट्रीमा सिर्जना गरिएको डकर छविको ठेगाना समावेश गर्नुपर्छ;
  4. "spec.mainClass" शब्दकोशमा Spark टास्क क्लास हुनु पर्छ जुन प्रक्रिया सुरु हुँदा चलाउन आवश्यक छ;
  5. "spec.mainApplicationFile" शब्दकोशमा कार्यान्वयन योग्य जार फाइलको मार्ग समावेश हुनुपर्छ;
  6. "spec.sparkVersion" शब्दकोषले प्रयोग भइरहेको Spark को संस्करण संकेत गर्नुपर्छ;
  7. "spec.driver.serviceAccount" शब्दकोशले अनुप्रयोग चलाउन प्रयोग गरिने सम्बन्धित Kubernetes नेमस्पेस भित्र सेवा खाता निर्दिष्ट गर्नुपर्छ;
  8. "spec.executor" शब्दकोशले एप्लिकेसनमा आवंटित स्रोतहरूको संख्यालाई संकेत गर्नुपर्छ;
  9. "spec.volumeMounts" शब्दकोशले स्थानीय डाइरेक्टरी निर्दिष्ट गर्नुपर्छ जसमा स्थानीय Spark कार्य फाइलहरू सिर्जना गरिनेछ।

manifest उत्पन्न गर्ने एउटा उदाहरण (यहाँ {spark-service-account} Spark कार्यहरू चलाउनको लागि Kubernetes क्लस्टर भित्रको सेवा खाता हो):

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"

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

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

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

त्यस पछि, हामी हाम्रो manifest spark-pi.yaml फाइलमा बचत गर्छौं र यसलाई हाम्रो Kubernetes क्लस्टरमा लागू गर्छौं:

oc apply -f spark-pi.yaml

यसले "sparkapplications" प्रकारको वस्तु सिर्जना गर्नेछ:

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

यस अवस्थामा, एउटा अनुप्रयोगको साथ पोड सिर्जना गरिनेछ, जसको स्थिति सिर्जना गरिएको "स्पार्क अनुप्रयोगहरू" मा प्रदर्शित हुनेछ। तपाइँ यसलाई निम्न आदेश संग हेर्न सक्नुहुन्छ:

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

कार्य पूरा भएपछि, POD "समाप्त" स्थितिमा जान्छ, जुन "sparkapplications" मा पनि अद्यावधिक हुनेछ। एप्लिकेसन लगहरू ब्राउजरमा वा निम्न आदेश प्रयोग गरेर हेर्न सकिन्छ (यहाँ {sparkapplications-pod-name} चलिरहेको कार्यको पोडको नाम हो):

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

स्पार्क कार्यहरू पनि विशेष 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

चलो स्पार्क कार्यहरूको सूची जाँच गरौं:

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}

निष्कर्षमा, म Kubernetes मा स्पार्क (2.4.5) को हालको स्थिर संस्करण प्रयोग गर्दा पत्ता लगाएका हानिहरू विचार गर्न चाहन्छु:

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

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

Fin।

स्रोत: www.habr.com