🥇குபெர்னெட்டஸில் இயங்கும் அப்பாச்சி ஸ்பார்க்

அன்புள்ள வாசகர்களே, நல்ல மதியம். இன்று நாம் அப்பாச்சி ஸ்பார்க் மற்றும் அதன் வளர்ச்சி வாய்ப்புகள் பற்றி கொஞ்சம் பேசுவோம்.

பிக் டேட்டாவின் நவீன உலகில், அப்பாச்சி ஸ்பார்க் என்பது தொகுதி தரவு செயலாக்க பணிகளை உருவாக்குவதற்கான நடைமுறை தரநிலையாகும். கூடுதலாக, மைக்ரோ பேட்ச் கான்செப்ட்டில் வேலை செய்யும் ஸ்ட்ரீமிங் அப்ளிகேஷன்களை உருவாக்கவும், தரவை செயலாக்கவும் சிறிய பகுதிகளாக அனுப்பவும் பயன்படுகிறது (ஸ்பார்க் ஸ்ட்ரக்ச்சர்டு ஸ்ட்ரீமிங்). பாரம்பரியமாக இது ஒட்டுமொத்த ஹடூப் அடுக்கின் ஒரு பகுதியாக இருந்து வருகிறது, YARN (அல்லது சில சந்தர்ப்பங்களில் Apache Mesos) ஐ ஆதார மேலாளராகப் பயன்படுத்துகிறது. 2020 வாக்கில், அதன் பாரம்பரிய வடிவத்தில் அதன் பயன்பாடு ஒழுக்கமான ஹடூப் விநியோகங்கள் இல்லாததால் பெரும்பாலான நிறுவனங்களுக்கு கேள்விக்குறியாக உள்ளது - HDP மற்றும் CDH இன் வளர்ச்சி நிறுத்தப்பட்டது, CDH நன்கு வளர்ச்சியடையவில்லை மற்றும் அதிக விலை உள்ளது, மேலும் மீதமுள்ள ஹடூப் சப்ளையர்கள் ஒன்று இருப்பதை நிறுத்தியது அல்லது மங்கலான எதிர்காலம் உள்ளது. எனவே, Kubernetes ஐப் பயன்படுத்தி Apache Spark இன் வெளியீடு சமூகம் மற்றும் பெரிய நிறுவனங்களிடையே ஆர்வத்தை அதிகரித்து வருகிறது - கொள்கலன் ஆர்கெஸ்ட்ரேஷன் மற்றும் தனியார் மற்றும் பொது மேகங்களில் வள மேலாண்மை ஆகியவற்றில் ஒரு தரநிலையாக மாறுகிறது, இது YARN இல் ஸ்பார்க் பணிகளின் சிரமமான வள திட்டமிடல் சிக்கலை தீர்க்கிறது மற்றும் வழங்குகிறது. அனைத்து அளவுகள் மற்றும் கோடுகள் கொண்ட நிறுவனங்களுக்கு பல வணிக மற்றும் திறந்த விநியோகங்களுடன் சீராக வளரும் தளம். கூடுதலாக, பிரபலமடைந்ததை அடுத்து, பெரும்பாலானவர்கள் ஏற்கனவே தங்களுடைய சொந்த நிறுவல்களைப் பெற முடிந்தது மற்றும் அதன் பயன்பாட்டில் தங்கள் நிபுணத்துவத்தை அதிகரித்துள்ளனர், இது நகர்வை எளிதாக்குகிறது.

பதிப்பு 2.3.0 இல் தொடங்கி, Apache Spark ஆனது Kubernetes கிளஸ்டரில் பணிகளை இயக்குவதற்கான உத்தியோகபூர்வ ஆதரவைப் பெற்றது மற்றும் இன்று, இந்த அணுகுமுறையின் தற்போதைய முதிர்ச்சி, அதன் பயன்பாட்டிற்கான பல்வேறு விருப்பங்கள் மற்றும் செயல்படுத்தும் போது எதிர்கொள்ளும் ஆபத்துகள் பற்றி பேசுவோம்.

முதலில், அப்பாச்சி ஸ்பார்க்கின் அடிப்படையில் பணிகள் மற்றும் பயன்பாடுகளை உருவாக்கும் செயல்முறையைப் பார்ப்போம் மற்றும் குபெர்னெட்டஸ் கிளஸ்டரில் நீங்கள் ஒரு பணியை இயக்க வேண்டிய வழக்கமான நிகழ்வுகளை முன்னிலைப்படுத்துவோம். இந்த இடுகையைத் தயாரிப்பதில், OpenShift ஒரு விநியோகமாகப் பயன்படுத்தப்படுகிறது மற்றும் அதன் கட்டளை வரி பயன்பாட்டுடன் தொடர்புடைய கட்டளைகள் (oc) வழங்கப்படும். பிற குபெர்னெட்டஸ் விநியோகங்களுக்கு, நிலையான குபெர்னெட்ஸ் கட்டளை வரி பயன்பாட்டு (kubectl) அல்லது அவற்றின் ஒப்புமைகளில் இருந்து தொடர்புடைய கட்டளைகள் (எடுத்துக்காட்டாக, oc adm கொள்கைக்கு) பயன்படுத்தப்படலாம்.

முதல் பயன்பாட்டு வழக்கு - தீப்பொறி-சமர்ப்பி

பணிகள் மற்றும் பயன்பாடுகளின் வளர்ச்சியின் போது, டெவலப்பர் தரவு மாற்றத்தை பிழைத்திருத்த பணிகளை இயக்க வேண்டும். கோட்பாட்டளவில், ஸ்டப்களை இந்த நோக்கங்களுக்காகப் பயன்படுத்தலாம், ஆனால் இறுதி அமைப்புகளின் உண்மையான (சோதனை என்றாலும்) நிகழ்வுகளின் பங்கேற்புடன் மேம்பாடு இந்த வகை பணிகளில் வேகமாகவும் சிறப்பாகவும் நிரூபிக்கப்பட்டுள்ளது. இறுதி அமைப்புகளின் உண்மையான நிகழ்வுகளில் பிழைத்திருத்தம் செய்யும் போது, இரண்டு காட்சிகள் சாத்தியமாகும்:

டெவலப்பர் ஒரு ஸ்பார்க் பணியை உள்நாட்டில் தனித்த முறையில் இயக்குகிறார்;
ஒரு டெவலப்பர் ஒரு சோதனை வளையத்தில் ஒரு குபெர்னெட்ஸ் கிளஸ்டரில் ஸ்பார்க் பணியை இயக்குகிறார்.

முதல் விருப்பத்திற்கு இருப்பதற்கான உரிமை உள்ளது, ஆனால் பல குறைபாடுகள் உள்ளன:

ஒவ்வொரு டெவலப்பருக்கும் பணியிடத்தில் இருந்து அவருக்குத் தேவையான இறுதி அமைப்புகளின் அனைத்து நிகழ்வுகளுக்கும் அணுகல் வழங்கப்பட வேண்டும்;
உருவாக்கப்படும் பணியை இயக்க, வேலை செய்யும் இயந்திரத்தில் போதுமான அளவு வளங்கள் தேவை.

இரண்டாவது விருப்பத்தில் இந்த குறைபாடுகள் இல்லை, ஏனெனில் குபெர்னெட்ஸ் கிளஸ்டரின் பயன்பாடு, பணிகளுக்கு தேவையான ஆதாரக் குளத்தை ஒதுக்கவும், இறுதி கணினி நிகழ்வுகளுக்கு தேவையான அணுகலை வழங்கவும் அனுமதிக்கிறது, குபெர்னெட்ஸ் முன்மாதிரியைப் பயன்படுத்தி நெகிழ்வாக அணுகலை வழங்குகிறது. மேம்பாட்டுக் குழுவின் அனைத்து உறுப்பினர்களும். சோதனைச் சுற்றில் உள்ள குபெர்னெட்ஸ் கிளஸ்டரில் உள்ளூர் டெவலப்பர் மெஷினிலிருந்து ஸ்பார்க் பணிகளைத் தொடங்குதல் - முதல் பயன்பாட்டு நிகழ்வாக இதை முன்னிலைப்படுத்துவோம்.

உள்நாட்டில் இயங்க ஸ்பார்க் அமைக்கும் செயல்முறை பற்றி மேலும் பேசலாம். 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

ஒரு முழு உருவாக்கம் நிறைய நேரம் எடுக்கும், மேலும் டோக்கர் படங்களை உருவாக்கி அவற்றை குபெர்னெட்டஸ் கிளஸ்டரில் இயக்க, உங்களுக்கு உண்மையில் “அசெம்பிளி/” கோப்பகத்திலிருந்து ஜார் கோப்புகள் தேவை, எனவே நீங்கள் இந்த துணைத் திட்டத்தை மட்டுமே உருவாக்க முடியும்:

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

குபெர்னெட்டஸில் ஸ்பார்க் வேலைகளை இயக்க, அடிப்படைப் படமாகப் பயன்படுத்த, நீங்கள் டோக்கர் படத்தை உருவாக்க வேண்டும். இங்கே 2 சாத்தியமான அணுகுமுறைகள் உள்ளன:

உருவாக்கப்பட்ட டோக்கர் படத்தில் இயங்கக்கூடிய ஸ்பார்க் டாஸ்க் குறியீடு உள்ளது;
உருவாக்கப்பட்ட படத்தில் ஸ்பார்க் மற்றும் தேவையான சார்புகள் மட்டுமே உள்ளன, இயங்கக்கூடிய குறியீடு தொலைவிலிருந்து ஹோஸ்ட் செய்யப்படுகிறது (எடுத்துக்காட்டாக, HDFS இல்).

முதலில், ஸ்பார்க் பணியின் சோதனை உதாரணம் கொண்ட டோக்கர் படத்தை உருவாக்குவோம். டோக்கர் படங்களை உருவாக்க, ஸ்பார்க்கில் "டாக்கர்-இமேஜ்-டூல்" எனப்படும் ஒரு பயன்பாடு உள்ளது. அதற்கான உதவியைப் படிப்போம்:

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

அதன் உதவியுடன், நீங்கள் டோக்கர் படங்களை உருவாக்கலாம் மற்றும் தொலைநிலைப் பதிவேட்டில் பதிவேற்றலாம், ஆனால் முன்னிருப்பாக இது பல குறைபாடுகளைக் கொண்டுள்ளது:

தவறாமல் ஒரே நேரத்தில் 3 டோக்கர் படங்களை உருவாக்குகிறது - 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} — URL вашего реестра образов Docker, {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 கிளஸ்டரில் ஸ்பார்க் பணியை வெளியிட, spark-submit கட்டளையை இயக்குவோம்:

 /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 - காய்களைத் தொடங்கும் போது பயன்படுத்தப்படும் குபெர்னெட்ஸ் சேவைக் கணக்கின் பெயர் (குபெர்னெட்ஸ் API உடன் தொடர்பு கொள்ளும்போது பாதுகாப்பு சூழல் மற்றும் திறன்களை வரையறுக்க);

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.

வளர்ச்சி செயல்முறையை எளிதாக்க, மற்றொரு விருப்பத்தைப் பயன்படுத்தலாம், இதில் ஸ்பார்க்கின் பொதுவான அடிப்படைப் படம் உருவாக்கப்பட்டு, எல்லாப் பணிகளும் இயங்குவதற்குப் பயன்படுத்தப்படுகின்றன, மேலும் இயங்கக்கூடிய கோப்புகளின் ஸ்னாப்ஷாட்கள் வெளிப்புற சேமிப்பகத்தில் வெளியிடப்படும் (உதாரணமாக, ஹடூப்) மற்றும் அழைக்கும் போது குறிப்பிடப்படும். spark-submit as a link. இந்த வழக்கில், நீங்கள் டோக்கர் படங்களை மறுகட்டமைக்காமல் ஸ்பார்க் பணிகளின் வெவ்வேறு பதிப்புகளை இயக்கலாம், எடுத்துக்காட்டாக, படங்களை வெளியிட 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

இது போன்ற பதிலைப் பெறுவீர்கள் (கோப்பைப் பதிவிறக்கப் பயன்படுத்த வேண்டிய URL இங்கே {location} ஆகும்):

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

ஸ்பார்க் இயங்கக்கூடிய கோப்பை HDFS இல் ஏற்றவும் (இங்கே {path-to-local-file} என்பது தற்போதைய ஹோஸ்டில் உள்ள Spark இயங்கக்கூடிய கோப்பிற்கான பாதையாகும்):

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

இதற்குப் பிறகு, HDFS இல் பதிவேற்றப்பட்ட Spark கோப்பைப் பயன்படுத்தி நாம் spark-submit செய்யலாம் (இங்கே {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 க்கு ஒரு கட்டளையைச் சேர்க்கவும். SPARK_CLASSPATH இல் HDFS உள்ளமைவு கோப்பை நுழைவு புள்ளியில் உள்ளிடவும்.

இரண்டாவது பயன்பாட்டு வழக்கு - அப்பாச்சி லிவி

மேலும், ஒரு பணி உருவாக்கப்பட்டு அதன் முடிவைச் சோதிக்க வேண்டியிருக்கும் போது, அதை CI/CD செயல்முறையின் ஒரு பகுதியாகத் தொடங்குவது மற்றும் அதன் செயல்பாட்டின் நிலையைக் கண்காணிப்பது பற்றிய கேள்வி எழுகிறது. நிச்சயமாக, உள்ளூர் ஸ்பார்க்-சமர்ப்பிப்பு அழைப்பைப் பயன்படுத்தி நீங்கள் அதை இயக்கலாம், ஆனால் இது CI/CD உள்கட்டமைப்பை சிக்கலாக்குகிறது, ஏனெனில் CI சேவையக முகவர்கள்/ரன்னர்களில் Spark ஐ நிறுவி உள்ளமைக்க வேண்டும் மற்றும் Kubernetes APIக்கான அணுகலை அமைக்க வேண்டும். இந்த வழக்கில், குபெர்னெட்டஸ் கிளஸ்டருக்குள் ஹோஸ்ட் செய்யப்பட்ட ஸ்பார்க் பணிகளை இயக்க, REST API ஆக Apache Livy ஐப் பயன்படுத்த இலக்கு செயல்படுத்தல் தேர்வு செய்துள்ளது. அதன் உதவியுடன், வழக்கமான சுருட்டை கோரிக்கைகளைப் பயன்படுத்தி, குபெர்நெட்ஸ் கிளஸ்டரில் ஸ்பார்க் பணிகளை இயக்கலாம், இது எந்தவொரு CI தீர்வின் அடிப்படையிலும் எளிதாகச் செயல்படுத்தப்படுகிறது, மேலும் குபெர்னெட்டஸ் ஏபிஐ உடன் தொடர்புகொள்ளும்போது, குபெர்னெட்டஸ் கிளஸ்டருக்குள் அதன் இடம் அங்கீகரிப்பு சிக்கலை தீர்க்கிறது.

சோதனை வளையத்தில் குபெர்னெட்ஸ் கிளஸ்டரில் CI/CD செயல்முறையின் ஒரு பகுதியாக ஸ்பார்க் பணிகளை இயக்குவது - இரண்டாவது பயன்பாட்டு நிகழ்வாக இதை முன்னிலைப்படுத்துவோம்.

Apache Livy பற்றி கொஞ்சம் - இது ஒரு வலை இடைமுகத்தை வழங்கும் HTTP சேவையகமாகவும், தேவையான அளவுருக்களைக் கடந்து ஸ்பார்க்-சமர்ப்பிப்பை தொலைவிலிருந்து தொடங்க உங்களை அனுமதிக்கும் RESTful API ஆகவும் செயல்படுகிறது. பாரம்பரியமாக இது HDP விநியோகத்தின் ஒரு பகுதியாக அனுப்பப்படுகிறது, ஆனால் இது போன்ற பொருத்தமான மேனிஃபெஸ்ட் மற்றும் டோக்கர் படங்களின் தொகுப்பைப் பயன்படுத்தி OKD அல்லது வேறு எந்த குபெர்னெட்ஸ் நிறுவலுக்கும் பயன்படுத்தப்படலாம் - github.com/ttauveron/k8s-big-data-experiments/tree/master/livy-spark-2.3. எங்கள் விஷயத்தில், பின்வரும் Dockerfile இலிருந்து Spark பதிப்பு 2.4.5 உட்பட இதே போன்ற Docker படம் கட்டப்பட்டது:

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 களஞ்சியம் போன்ற உங்கள் இருக்கும் டோக்கர் களஞ்சியத்தில் உருவாக்கி பதிவேற்றலாம். அதைப் பயன்படுத்த, பின்வரும் மேனிஃபெஸ்ட் ({registry-url} - டோக்கர் படப் பதிவேட்டின் URL, {image-name} - டோக்கர் படத்தின் பெயர், {tag} - டோக்கர் படக் குறிச்சொல், {livy-url} - விரும்பிய URL ஐப் பயன்படுத்தவும் சேவையகம் Livy அணுகக்கூடியதாக இருக்கும்; Red Hat OpenShift குபெர்னெட்டஸ் விநியோகமாகப் பயன்படுத்தப்பட்டால் "Route" மேனிஃபெஸ்ட் பயன்படுத்தப்படும், இல்லையெனில் NodePort வகையின் தொடர்புடைய Ingress அல்லது சர்வீஸ் மேனிஃபெஸ்ட் பயன்படுத்தப்படும்:

---
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 கோரிக்கையைப் பயன்படுத்தி எங்கள் Spark பணியை வெளியிடலாம், எடுத்துக்காட்டாக, Postman. கோரிக்கைகளுடன் கூடிய தொகுப்பின் எடுத்துக்காட்டு கீழே கொடுக்கப்பட்டுள்ளது (தொடங்கப்பட்ட பணியின் செயல்பாட்டிற்கு தேவையான மாறிகள் கொண்ட உள்ளமைவு வாதங்களை "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 சர்வரில் உள்ள Livy கொள்கலனின் பதிவுகளை Livy சர்வர் மூலம் ஆராய்வோம் - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods/{livy-pod-name }?tab=logs. "livy" என்று பெயரிடப்பட்ட ஒரு கொள்கலனில் Livy REST API ஐ அழைக்கும்போது, மேலே நாம் பயன்படுத்தியதைப் போலவே ஒரு தீப்பொறி-சமர்ப்பிப்பு செயல்படுத்தப்படுவதை அவற்றிலிருந்து நாம் காணலாம் (இங்கே {livy-pod-name} என்பது உருவாக்கப்பட்ட பாட்டின் பெயர். லிவி சேவையகத்துடன்). லைவி சர்வரைப் பயன்படுத்தி, ஸ்பார்க் எக்ஸிகியூட்டபிளை தொலைவிலிருந்து ஹோஸ்ட் செய்யும் பணிகளை இயக்க அனுமதிக்கும் இரண்டாவது வினவலையும் சேகரிப்பு அறிமுகப்படுத்துகிறது.

மூன்றாவது பயன்பாட்டு வழக்கு - ஸ்பார்க் ஆபரேட்டர்

இப்போது பணி சோதனை செய்யப்பட்டுள்ளதால், அதை தொடர்ந்து இயக்குவது குறித்த கேள்வி எழுகிறது. குபெர்னெட்ஸ் கிளஸ்டரில் பணிகளைத் தொடர்ந்து இயக்குவதற்கான சொந்த வழி CronJob நிறுவனம் மற்றும் நீங்கள் அதைப் பயன்படுத்தலாம், ஆனால் தற்போது Kubernetes இல் பயன்பாடுகளை நிர்வகிக்க ஆபரேட்டர்களின் பயன்பாடு மிகவும் பிரபலமாக உள்ளது மற்றும் Spark க்கு மிகவும் முதிர்ந்த ஆபரேட்டர் உள்ளது, இதுவும் நிறுவன அளவிலான தீர்வுகளில் பயன்படுத்தப்படுகிறது (உதாரணமாக, Lightbend FastData இயங்குதளம்). இதைப் பயன்படுத்த பரிந்துரைக்கிறோம் - ஸ்பார்க்கின் தற்போதைய நிலையான பதிப்பு (2.4.5) குபெர்னெட்டஸில் ஸ்பார்க் பணிகளை இயக்குவதற்கான குறைந்த உள்ளமைவு விருப்பங்களைக் கொண்டுள்ளது, அதே நேரத்தில் அடுத்த பெரிய பதிப்பு (3.0.0) குபெர்னெட்டஸுக்கு முழு ஆதரவை அறிவிக்கிறது, ஆனால் அதன் வெளியீட்டு தேதி தெரியவில்லை. . ஸ்பார்க் ஆபரேட்டர் முக்கியமான உள்ளமைவு விருப்பங்களைச் சேர்ப்பதன் மூலம் இந்த குறைபாட்டை ஈடுசெய்கிறது (உதாரணமாக, ஸ்பார்க் பாட்களுக்கு ஹடூப் அணுகல் உள்ளமைவுடன் ஒரு கான்ஃபிக்மேப்பை ஏற்றுதல்) மற்றும் தொடர்ந்து திட்டமிடப்பட்ட பணியை இயக்கும் திறன்.

இதை மூன்றாவது பயன்பாட்டு நிகழ்வாக முன்னிலைப்படுத்துவோம் - உற்பத்தி வளையத்தில் குபெர்னெட்டஸ் கிளஸ்டரில் ஸ்பார்க் பணிகளைத் தொடர்ந்து இயக்குகிறது.

ஸ்பார்க் ஆபரேட்டர் ஓப்பன் சோர்ஸ் மற்றும் கூகுள் கிளவுட் பிளாட்ஃபார்மில் உருவாக்கப்பட்டது - github.com/GoogleCloudPlatform/spark-on-k8s-operator. அதன் நிறுவல் 3 வழிகளில் செய்யப்படலாம்:

Lightbend FastData இயங்குதளம்/Cloudflow நிறுவலின் ஒரு பகுதியாக;

ஹெல்மைப் பயன்படுத்துதல்:

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

அதிகாரப்பூர்வ களஞ்சியத்திலிருந்து மேனிஃபெஸ்ட்களைப் பயன்படுத்துதல் (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
	
```

ஆபரேட்டர் சரியாக நிறுவப்பட்டிருந்தால், தொடர்புடைய திட்டத்தில் ஸ்பார்க் ஆபரேட்டருடன் செயலில் உள்ள பாட் தோன்றும் (உதாரணமாக, கிளவுட்ஃப்ளோ நிறுவலுக்கான கிளவுட்ஃப்ளோ இடத்தில் கிளவுட்ஃப்ளோ-எஃப்டிபி-ஸ்பார்கோபரேட்டர்) மற்றும் "ஸ்பார்க் அப்ளிகேஷன்ஸ்" என்று பெயரிடப்பட்ட குபெர்னெட்ஸ் ஆதார வகை தோன்றும். . பின்வரும் கட்டளையுடன் கிடைக்கும் ஸ்பார்க் பயன்பாடுகளை நீங்கள் ஆராயலாம்:

oc get sparkapplications -n {project}

ஸ்பார்க் ஆபரேட்டரைப் பயன்படுத்தி பணிகளை இயக்க, நீங்கள் 3 விஷயங்களைச் செய்ய வேண்டும்:

தேவையான அனைத்து நூலகங்களையும், கட்டமைப்பு மற்றும் இயங்கக்கூடிய கோப்புகளையும் உள்ளடக்கிய ஒரு டோக்கர் படத்தை உருவாக்கவும். இலக்குப் படத்தில், இது CI/CD நிலையில் உருவாக்கப்பட்ட மற்றும் சோதனைக் கிளஸ்டரில் சோதிக்கப்பட்ட ஒரு படம்;
குபெர்னெட்ஸ் கிளஸ்டரிலிருந்து அணுகக்கூடிய பதிவேட்டில் ஒரு டோக்கர் படத்தை வெளியிடவும்;
"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" அகராதியானது அணுகக்கூடிய பதிவேட்டில் உருவாக்கப்பட்ட டோக்கர் படத்தின் முகவரியைக் கொண்டிருக்க வேண்டும்;
4. "spec.mainClass" அகராதியில் ஸ்பார்க் டாஸ்க் கிளாஸ் இருக்க வேண்டும், இது செயல்முறை தொடங்கும் போது இயக்கப்பட வேண்டும்;
5. "spec.mainApplicationFile" அகராதியில் இயங்கக்கூடிய ஜார் கோப்பிற்கான பாதை இருக்க வேண்டும்;
6. "spec.sparkVersion" அகராதி பயன்படுத்தப்படும் Spark இன் பதிப்பைக் குறிக்க வேண்டும்;
7. "spec.driver.serviceAccount" அகராதியானது, பயன்பாட்டை இயக்கப் பயன்படுத்தப்படும் தொடர்புடைய குபெர்னெட்டஸ் பெயர்வெளியில் உள்ள சேவைக் கணக்கைக் குறிப்பிட வேண்டும்;
8. "spec.executor" அகராதியானது பயன்பாட்டிற்கு ஒதுக்கப்பட்ட ஆதாரங்களின் எண்ணிக்கையைக் குறிக்க வேண்டும்;
9. "spec.volumeMounts" அகராதியானது உள்ளூர் ஸ்பார்க் பணிக் கோப்புகள் உருவாக்கப்படும் உள்ளூர் கோப்பகத்தைக் குறிப்பிட வேண்டும்.

மேனிஃபெஸ்ட்டை உருவாக்குவதற்கான உதாரணம் (இங்கே {spark-service-account} என்பது ஸ்பார்க் பணிகளை இயக்குவதற்கான குபெர்னெட்ஸ் கிளஸ்டருக்குள் இருக்கும் சேவைக் கணக்கு):

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"

இந்த மேனிஃபெஸ்ட் ஒரு சேவைக் கணக்கைக் குறிப்பிடுகிறது, மேனிஃபெஸ்டை வெளியிடும் முன், Kubernetes API உடன் தொடர்புகொள்வதற்கு (தேவைப்பட்டால்) Spark பயன்பாட்டிற்கு தேவையான அணுகல் உரிமைகளை வழங்கும் தேவையான பங்கு பிணைப்புகளை நீங்கள் உருவாக்க வேண்டும். எங்கள் விஷயத்தில், Pods ஐ உருவாக்க பயன்பாட்டிற்கு உரிமைகள் தேவை. தேவையான பங்கு பிணைப்பை உருவாக்குவோம்:

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

இந்த மேனிஃபெஸ்ட் விவரக்குறிப்பில் "hadoopConfigMap" அளவுரு இருக்கலாம் என்பதும் குறிப்பிடத்தக்கது, இது டோக்கர் படத்தில் தொடர்புடைய கோப்பை முதலில் வைக்காமல் Hadoop உள்ளமைவுடன் ஒரு ConfigMap ஐக் குறிப்பிட உங்களை அனுமதிக்கிறது. தொடர்ந்து பணிகளை இயக்குவதற்கும் இது ஏற்றது - "அட்டவணை" அளவுருவைப் பயன்படுத்தி, கொடுக்கப்பட்ட பணியை இயக்குவதற்கான அட்டவணையை குறிப்பிடலாம்.

அதன் பிறகு, எங்கள் மேனிஃபெஸ்ட்டை spark-pi.yaml கோப்பில் சேமித்து அதை எங்கள் குபெர்னெட்ஸ் கிளஸ்டருக்குப் பயன்படுத்துகிறோம்:

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}

சிறப்பு 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}

முடிவில், ஸ்பார்க்கின் தற்போதைய நிலையான பதிப்பை (2.4.5) குபெர்னெட்டஸில் பயன்படுத்துவதில் கண்டறியப்பட்ட குறைபாடுகளைக் கருத்தில் கொள்ள விரும்புகிறேன்:

முதல் மற்றும், ஒருவேளை, முக்கிய தீமை தரவு இடம் இல்லாதது. YARN இன் அனைத்து குறைபாடுகள் இருந்தபோதிலும், அதைப் பயன்படுத்துவதில் நன்மைகள் இருந்தன, எடுத்துக்காட்டாக, தரவுக்கு குறியீட்டை வழங்குவதற்கான கொள்கை (குறியீட்டிற்கு தரவுக்கு பதிலாக). அதற்கு நன்றி, கணக்கீடுகளில் ஈடுபட்டுள்ள தரவு அமைந்துள்ள முனைகளில் ஸ்பார்க் பணிகள் செயல்படுத்தப்பட்டன, மேலும் நெட்வொர்க்கில் தரவை வழங்குவதற்கான நேரம் கணிசமாகக் குறைக்கப்பட்டது. Kubernetes ஐப் பயன்படுத்தும் போது, நெட்வொர்க் முழுவதும் ஒரு பணியில் ஈடுபட்டுள்ள தரவை நகர்த்த வேண்டிய அவசியத்தை நாங்கள் எதிர்கொள்கிறோம். அவை போதுமான அளவு பெரியதாக இருந்தால், பணியைச் செயல்படுத்தும் நேரம் கணிசமாக அதிகரிக்கக்கூடும், மேலும் அவற்றின் தற்காலிக சேமிப்பிற்காக ஸ்பார்க் பணி நிகழ்வுகளுக்கு ஒதுக்கப்பட்ட வட்டு இடத்தின் அளவு அதிகமாக தேவைப்படும். குபெர்னெட்டஸில் (உதாரணமாக, Alluxio) தரவு இருப்பிடத்தை உறுதிசெய்யும் சிறப்பு மென்பொருளைப் பயன்படுத்துவதன் மூலம் இந்த குறைபாட்டைக் குறைக்க முடியும், ஆனால் இது உண்மையில் குபெர்னெட்டஸ் கிளஸ்டரின் முனைகளில் தரவின் முழுமையான நகலை சேமிக்க வேண்டியதன் அவசியத்தை குறிக்கிறது.
இரண்டாவது முக்கியமான குறைபாடு பாதுகாப்பு. இயல்பாக, Spark பணிகளை இயக்குவது தொடர்பான பாதுகாப்பு தொடர்பான அம்சங்கள் முடக்கப்பட்டுள்ளன, Kerberos இன் பயன்பாடு அதிகாரப்பூர்வ ஆவணத்தில் உள்ளடக்கப்படவில்லை (தொடர்பான விருப்பங்கள் பதிப்பு 3.0.0 இல் அறிமுகப்படுத்தப்பட்டிருந்தாலும், கூடுதல் வேலை தேவைப்படும்), மற்றும் பாதுகாப்பு ஆவணங்கள் Spark ஐப் பயன்படுத்தி (https://spark.apache.org/docs/2.4.5/security.html) YARN, Mesos மற்றும் Standalone Cluster ஆகியவை முக்கிய அங்காடிகளாகத் தோன்றும். அதே நேரத்தில், ஸ்பார்க் பணிகள் தொடங்கப்படும் பயனரை நேரடியாகக் குறிப்பிட முடியாது - அது செயல்படும் சேவைக் கணக்கை மட்டுமே நாங்கள் குறிப்பிடுகிறோம், மேலும் உள்ளமைக்கப்பட்ட பாதுகாப்புக் கொள்கைகளின் அடிப்படையில் பயனர் தேர்ந்தெடுக்கப்படுவார். இது சம்பந்தமாக, ரூட் பயனர் பயன்படுத்தப்படுகிறார், இது உற்பத்தி சூழலில் பாதுகாப்பானது அல்ல, அல்லது சீரற்ற UID கொண்ட பயனர், தரவு அணுகல் உரிமைகளை விநியோகிக்கும்போது சிரமமாக இருக்கும் (இதை PodSecurityPolicies உருவாக்கி அவற்றை இணைப்பதன் மூலம் தீர்க்க முடியும். தொடர்புடைய சேவை கணக்குகள்). தற்போது, தேவையான அனைத்து கோப்புகளையும் நேரடியாக டோக்கர் படத்தில் வைப்பது அல்லது ஸ்பார்க் வெளியீட்டு ஸ்கிரிப்டை மாற்றுவது உங்கள் நிறுவனத்தில் ஏற்றுக்கொள்ளப்பட்ட ரகசியங்களைச் சேமித்து மீட்டெடுப்பதற்கான பொறிமுறையைப் பயன்படுத்துவதே இதற்கு தீர்வாகும்.
Kubernetes ஐப் பயன்படுத்தி Spark வேலைகளை இயக்குவது அதிகாரப்பூர்வமாக இன்னும் சோதனை முறையில் உள்ளது மேலும் எதிர்காலத்தில் பயன்படுத்தப்படும் கலைப்பொருட்களில் (உள்ளமைவு கோப்புகள், டோக்கர் அடிப்படை படங்கள் மற்றும் வெளியீட்டு ஸ்கிரிப்டுகள்) குறிப்பிடத்தக்க மாற்றங்கள் இருக்கலாம். உண்மையில், பொருள் தயாரிக்கும் போது, பதிப்புகள் 2.3.0 மற்றும் 2.4.5 சோதிக்கப்பட்டன, நடத்தை கணிசமாக வேறுபட்டது.

புதுப்பிப்புகளுக்காக காத்திருப்போம் - ஸ்பார்க்கின் புதிய பதிப்பு (3.0.0) சமீபத்தில் வெளியிடப்பட்டது, இது குபெர்னெட்டஸில் ஸ்பார்க்கின் வேலையில் குறிப்பிடத்தக்க மாற்றங்களைக் கொண்டு வந்தது, ஆனால் இந்த ஆதார மேலாளருக்கான ஆதரவின் சோதனை நிலையைத் தக்க வைத்துக் கொண்டது. உங்கள் கணினியின் பாதுகாப்பிற்கு பயப்படாமல் மற்றும் செயல்பாட்டு கூறுகளை சுயாதீனமாக மாற்றியமைக்க வேண்டிய அவசியமின்றி, அடுத்த புதுப்பிப்புகள், YARN ஐ கைவிட்டு, Kubernetes இல் Spark பணிகளை இயக்குவதை முழுமையாக பரிந்துரைக்கும்.

துடுப்பு.

ஆதாரம்: www.habr.com

குபெர்னெட்டஸில் அப்பாச்சி ஸ்பார்க் ஓடுகிறது

முதல் பயன்பாட்டு வழக்கு - தீப்பொறி-சமர்ப்பி

இரண்டாவது பயன்பாட்டு வழக்கு - அப்பாச்சி லிவி

மூன்றாவது பயன்பாட்டு வழக்கு - ஸ்பார்க் ஆபரேட்டர்

கருத்தைச் சேர் Отменить ответ