કુબરનેટ્સ પર અપાચે સ્પાર્ક ચલાવવું

પ્રિય વાચકો, શુભ બપોર. આજે આપણે અપાચે સ્પાર્ક અને તેના વિકાસની સંભાવનાઓ વિશે થોડી વાત કરીશું.

બિગ ડેટાના આધુનિક વિશ્વમાં, અપાચે સ્પાર્ક એ બેચ ડેટા પ્રોસેસિંગ કાર્યો વિકસાવવા માટેનું વાસ્તવિક ધોરણ છે. વધુમાં, તેનો ઉપયોગ સ્ટ્રીમિંગ એપ્લિકેશન્સ બનાવવા માટે પણ થાય છે જે માઇક્રો બેચ કોન્સેપ્ટમાં કામ કરે છે, નાના ભાગોમાં ડેટા પ્રોસેસિંગ અને શિપિંગ કરે છે (સ્પાર્ક સ્ટ્રક્ચર્ડ સ્ટ્રીમિંગ). અને પરંપરાગત રીતે તે સંસાધન સંચાલક તરીકે YARN (અથવા કેટલાક કિસ્સાઓમાં Apache Mesos) નો ઉપયોગ કરીને એકંદર Hadoop સ્ટેકનો ભાગ રહ્યો છે. 2020 સુધીમાં, તેના પરંપરાગત સ્વરૂપમાં તેનો ઉપયોગ યોગ્ય Hadoop વિતરણના અભાવને કારણે મોટાભાગની કંપનીઓ માટે પ્રશ્નમાં છે - HDP અને CDHનો વિકાસ અટકી ગયો છે, CDH સારી રીતે વિકસિત નથી અને તેની કિંમત ઊંચી છે, અને બાકીના Hadoop સપ્લાયર્સ પાસે છે. ક્યાં તો અસ્તિત્વ બંધ થઈ ગયું છે અથવા ધૂંધળું ભવિષ્ય છે. તેથી, કુબરનેટસનો ઉપયોગ કરીને અપાચે સ્પાર્કનું લોન્ચિંગ સમુદાય અને મોટી કંપનીઓમાં વધુ રસ ધરાવે છે - ખાનગી અને જાહેર વાદળોમાં કન્ટેનર ઓર્કેસ્ટ્રેશન અને સંસાધન સંચાલનમાં માનક બનીને, તે YARN પર સ્પાર્ક કાર્યોના અસુવિધાજનક સંસાધન શેડ્યુલિંગની સમસ્યાને હલ કરે છે અને પ્રદાન કરે છે. તમામ કદ અને પટ્ટાઓની કંપનીઓ માટે ઘણા વ્યવસાયિક અને ખુલ્લા વિતરણો સાથે સતત વિકાસશીલ પ્લેટફોર્મ. વધુમાં, લોકપ્રિયતાને પગલે, મોટા ભાગનાએ પહેલેથી જ તેમના પોતાના કેટલાક સ્થાપનો હસ્તગત કરી લીધા છે અને તેના ઉપયોગમાં તેમની કુશળતા વધારી છે, જે ચાલને સરળ બનાવે છે.

વર્ઝન 2.3.0 થી શરૂ કરીને, Apache Spark એ Kubernetes ક્લસ્ટરમાં ચાલતા કાર્યો માટે સત્તાવાર સમર્થન મેળવ્યું છે અને આજે, અમે આ અભિગમની વર્તમાન પરિપક્વતા, તેના ઉપયોગ માટેના વિવિધ વિકલ્પો અને અમલીકરણ દરમિયાન આવતી મુશ્કેલીઓ વિશે વાત કરીશું.

સૌ પ્રથમ, ચાલો Apache Spark પર આધારિત કાર્યો અને એપ્લિકેશનો વિકસાવવાની પ્રક્રિયા જોઈએ અને લાક્ષણિક કેસોને પ્રકાશિત કરીએ જેમાં તમારે કુબરનેટ્સ ક્લસ્ટર પર કાર્ય ચલાવવાની જરૂર છે. આ પોસ્ટની તૈયારીમાં, OpenShift નો ઉપયોગ વિતરણ તરીકે થાય છે અને તેની કમાન્ડ લાઇન યુટિલિટી (oc) ને સંબંધિત આદેશો આપવામાં આવશે. અન્ય 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 સંભવિત અભિગમો છે:

• જનરેટ કરેલ ડોકર ઇમેજમાં એક્ઝિક્યુટેબલ સ્પાર્ક ટાસ્ક કોડનો સમાવેશ થાય છે;
• બનાવેલ ઇમેજમાં ફક્ત સ્પાર્ક અને જરૂરી નિર્ભરતા શામેલ છે, એક્ઝિક્યુટેબલ કોડ રિમોટલી હોસ્ટ કરવામાં આવે છે (ઉદાહરણ તરીકે, HDFS માં).

પ્રથમ, ચાલો સ્પાર્ક કાર્યનું પરીક્ષણ ઉદાહરણ ધરાવતી ડોકર ઈમેજ બનાવીએ. ડોકર ઇમેજ બનાવવા માટે, સ્પાર્ક પાસે "ડોકર-ઇમેજ-ટૂલ" નામની ઉપયોગિતા છે. ચાલો તેના પર મદદનો અભ્યાસ કરીએ:

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

તેની મદદથી, અમે સ્પાર્કનો ઉપયોગ કરીને 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 - પોડ્સ લોન્ચ કરતી વખતે ઉપયોગમાં લેવાતા કુબરનેટ્સ સર્વિસ એકાઉન્ટનું નામ (કુબરનેટ્સ 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.

વિકાસ પ્રક્રિયાને સરળ બનાવવા માટે, અન્ય વિકલ્પનો ઉપયોગ કરી શકાય છે, જેમાં સ્પાર્કની એક સામાન્ય બેઝ ઈમેજ બનાવવામાં આવે છે, જે ચલાવવા માટેના તમામ કાર્યો દ્વારા ઉપયોગમાં લેવામાં આવે છે, અને એક્ઝિક્યુટેબલ ફાઇલોના સ્નેપશોટને બાહ્ય સ્ટોરેજ (ઉદાહરણ તરીકે, 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 માં એક નિર્દેશ ઉમેરો અને એન્ટ્રીપોઇન્ટમાં SPARK_CLASSPATH માં HDFS રૂપરેખાંકન ફાઇલનો સમાવેશ કરો.

બીજો ઉપયોગ કેસ - અપાચે લિવી

વધુમાં, જ્યારે કોઈ કાર્ય વિકસાવવામાં આવે છે અને પરિણામનું પરીક્ષણ કરવાની જરૂર પડે છે, ત્યારે તેને CI/CD પ્રક્રિયાના ભાગ રૂપે શરૂ કરવાનો અને તેના અમલની સ્થિતિને ટ્રૅક કરવાનો પ્રશ્ન ઊભો થાય છે. અલબત્ત, તમે તેને સ્થાનિક સ્પાર્ક-સબમિટ કૉલનો ઉપયોગ કરીને ચલાવી શકો છો, પરંતુ આ CI/CD ઈન્ફ્રાસ્ટ્રક્ચરને જટિલ બનાવે છે કારણ કે તેને CI સર્વર એજન્ટ્સ/રનર્સ પર સ્પાર્ક ઇન્સ્ટોલ અને ગોઠવવાની અને કુબરનેટ્સ API ની ઍક્સેસ સેટ કરવાની જરૂર છે. આ કિસ્સામાં, લક્ષ્ય અમલીકરણે કુબરનેટ્સ ક્લસ્ટરની અંદર હોસ્ટ કરેલા સ્પાર્ક કાર્યોને ચલાવવા માટે REST API તરીકે Apache Livy નો ઉપયોગ કરવાનું પસંદ કર્યું છે. તેની મદદ વડે, તમે નિયમિત કર્એલ વિનંતીઓનો ઉપયોગ કરીને કુબરનેટ્સ ક્લસ્ટર પર સ્પાર્ક કાર્યો ચલાવી શકો છો, જે કોઈપણ CI સોલ્યુશનના આધારે સરળતાથી લાગુ કરવામાં આવે છે, અને કુબરનેટ્સ ક્લસ્ટરની અંદર તેનું પ્લેસમેન્ટ કુબરનેટ્સ API સાથે ક્રિયાપ્રતિક્રિયા કરતી વખતે પ્રમાણીકરણની સમસ્યાને હલ કરે છે.

ચાલો તેને બીજા ઉપયોગના કેસ તરીકે પ્રકાશિત કરીએ - ટેસ્ટ લૂપમાં કુબરનેટ્સ ક્લસ્ટર પર CI/CD પ્રક્રિયાના ભાગ રૂપે સ્પાર્ક કાર્યો ચલાવવું.

Apache Livy વિશે થોડું - તે એક HTTP સર્વર તરીકે કામ કરે છે જે વેબ ઇન્ટરફેસ અને RESTful API પ્રદાન કરે છે જે તમને જરૂરી પરિમાણો પસાર કરીને રિમોટલી સ્પાર્ક-સબમિટ શરૂ કરવાની મંજૂરી આપે છે. પરંપરાગત રીતે તે HDP વિતરણના ભાગ રૂપે મોકલવામાં આવ્યું છે, પરંતુ યોગ્ય મેનિફેસ્ટ અને ડોકર ઈમેજોના સમૂહનો ઉપયોગ કરીને OKD અથવા અન્ય કોઈપણ કુબરનેટ્સ ઇન્સ્ટોલેશનમાં પણ જમાવી શકાય છે, જેમ કે આ એક - 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 રીપોઝીટરી. તેને જમાવવા માટે, નીચેના મેનિફેસ્ટનો ઉપયોગ કરો ({registry-url} - ડોકર ઇમેજ રજિસ્ટ્રીનું URL, {image-name} - ડોકર ઇમેજનું નામ, {tag} - Docker ઇમેજ ટૅગ, {livy-url} - ઇચ્છિત URL જ્યાં સર્વર સુલભ Livy હશે; જો Red Hat OpenShift નો ઉપયોગ Kubernetes વિતરણ તરીકે કરવામાં આવે તો “રૂટ” મેનિફેસ્ટનો ઉપયોગ કરવામાં આવે છે, અન્યથા નોડપોર્ટ પ્રકારના અનુરૂપ પ્રવેશ અથવા સેવા મેનિફેસ્ટનો ઉપયોગ કરવામાં આવે છે):

---
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 વિનંતીનો ઉપયોગ કરીને પ્રકાશિત કરી શકીએ છીએ, ઉદાહરણ તરીકે, પોસ્ટમેન. વિનંતીઓ સાથેના સંગ્રહનું ઉદાહરણ નીચે રજૂ કરવામાં આવ્યું છે (લૉન્ચ કરેલા કાર્યના ઑપરેશન માટે જરૂરી ચલો સાથે રૂપરેખાંકન દલીલો "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. તે જ સમયે, લિવી ઇન્ટરફેસ (http://{livy-url}/ui) માં એક સત્ર દેખાશે, જેમાં લિવી API અથવા ગ્રાફિકલ ઇન્ટરફેસનો ઉપયોગ કરીને, તમે કાર્યની પ્રગતિને ટ્રૅક કરી શકો છો અને સત્રનો અભ્યાસ કરી શકો છો. લોગ

હવે ચાલો બતાવીએ કે લિવી કેવી રીતે કામ કરે છે. આ કરવા માટે, ચાલો લિવી સર્વર સાથે પોડની અંદર લિવી કન્ટેનરના લોગની તપાસ કરીએ - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods/{livy-pod-name }?tab=logs. તેમાંથી આપણે જોઈ શકીએ છીએ કે જ્યારે “livy” નામના કન્ટેનરમાં Livy REST API ને કૉલ કરવામાં આવે છે, ત્યારે એક સ્પાર્ક-સબમિટ કરવામાં આવે છે, જેમ કે આપણે ઉપર ઉપયોગ કર્યો છે (અહીં {livy-pod-name} એ બનાવેલ પોડનું નામ છે. લિવી સર્વર સાથે). સંગ્રહ એક બીજી ક્વેરી પણ રજૂ કરે છે જે તમને એવા કાર્યો ચલાવવા માટે પરવાનગી આપે છે જે લિવી સર્વરનો ઉપયોગ કરીને સ્પાર્ક એક્ઝિક્યુટેબલને રિમોટલી હોસ્ટ કરે છે.

ત્રીજો ઉપયોગ કેસ - સ્પાર્ક ઓપરેટર

હવે જ્યારે કાર્યનું પરીક્ષણ કરવામાં આવ્યું છે, ત્યારે તેને નિયમિતપણે ચલાવવાનો પ્રશ્ન ઊભો થાય છે. કુબરનેટ્સ ક્લસ્ટરમાં નિયમિતપણે કાર્યો ચલાવવાની મૂળ રીત એ ક્રોનજોબ એન્ટિટી છે અને તમે તેનો ઉપયોગ કરી શકો છો, પરંતુ આ ક્ષણે કુબરનેટ્સમાં એપ્લિકેશનનું સંચાલન કરવા માટે ઓપરેટર્સનો ઉપયોગ ખૂબ જ લોકપ્રિય છે અને સ્પાર્ક માટે એકદમ પરિપક્વ ઓપરેટર છે, જે પણ છે. એન્ટરપ્રાઇઝ-લેવલ સોલ્યુશન્સમાં વપરાય છે (ઉદાહરણ તરીકે, લાઇટબેન્ડ ફાસ્ટડેટા પ્લેટફોર્મ). અમે તેનો ઉપયોગ કરવાની ભલામણ કરીએ છીએ - સ્પાર્કના વર્તમાન સ્થિર સંસ્કરણ (2.4.5)માં કુબરનેટ્સમાં સ્પાર્ક કાર્યો ચલાવવા માટે મર્યાદિત રૂપરેખાંકન વિકલ્પો છે, જ્યારે આગામી મુખ્ય સંસ્કરણ (3.0.0) કુબરનેટ્સ માટે સંપૂર્ણ સમર્થન જાહેર કરે છે, પરંતુ તેની પ્રકાશન તારીખ અજાણ છે. . સ્પાર્ક ઓપરેટર મહત્વપૂર્ણ રૂપરેખાંકન વિકલ્પો ઉમેરીને (ઉદાહરણ તરીકે, સ્પાર્ક પોડ્સમાં Hadoop એક્સેસ રૂપરેખાંકન સાથે કોન્ફિગમેપને માઉન્ટ કરીને) અને નિયમિત રીતે સુનિશ્ચિત કાર્ય ચલાવવાની ક્ષમતા ઉમેરીને આ ખામીને વળતર આપે છે.

ચાલો તેને ત્રીજા ઉપયોગના કેસ તરીકે પ્રકાશિત કરીએ - ઉત્પાદન લૂપમાં કુબરનેટ્સ ક્લસ્ટર પર સ્પાર્ક કાર્યો નિયમિતપણે ચલાવો.

સ્પાર્ક ઓપરેટર ઓપન સોર્સ છે અને ગૂગલ ક્લાઉડ પ્લેટફોર્મની અંદર વિકસિત છે - 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). તે નીચેનાને ધ્યાનમાં લેવા યોગ્ય છે - ક્લાઉડફ્લોમાં 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"

આ મેનિફેસ્ટ એક સર્વિસ એકાઉન્ટનો ઉલ્લેખ કરે છે કે જેના માટે, મેનિફેસ્ટ પ્રકાશિત કરતા પહેલા, તમારે જરૂરી રોલ બાઈન્ડિંગ્સ બનાવવી આવશ્યક છે જે સ્પાર્ક એપ્લિકેશનને કુબરનેટ્સ API (જો જરૂરી હોય તો) સાથે ક્રિયાપ્રતિક્રિયા કરવા માટે જરૂરી ઍક્સેસ અધિકારો પ્રદાન કરે છે. અમારા કિસ્સામાં, એપ્લિકેશનને પોડ્સ બનાવવાના અધિકારોની જરૂર છે. ચાલો જરૂરી ભૂમિકા બંધનકર્તા બનાવીએ:

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

એ નોંધવું પણ યોગ્ય છે કે આ મેનિફેસ્ટ સ્પષ્ટીકરણમાં "hadoopConfigMap" પરિમાણ શામેલ હોઈ શકે છે, જે તમને ડોકર ઇમેજમાં અનુરૂપ ફાઇલને પ્રથમ સ્થાન આપ્યા વિના Hadoop રૂપરેખાંકન સાથે ConfigMap નો ઉલ્લેખ કરવાની મંજૂરી આપે છે. તે નિયમિતપણે કાર્યો ચલાવવા માટે પણ યોગ્ય છે - "શેડ્યૂલ" પરિમાણનો ઉપયોગ કરીને, આપેલ કાર્ય ચલાવવા માટેનું શેડ્યૂલ નિર્દિષ્ટ કરી શકાય છે.

તે પછી, અમે અમારા મેનિફેસ્ટને 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-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) ના વર્તમાન સ્થિર સંસ્કરણનો ઉપયોગ કરવાના શોધાયેલા ગેરફાયદાને ધ્યાનમાં લેવા માંગુ છું:

1. પ્રથમ અને, કદાચ, મુખ્ય ગેરલાભ એ ડેટા લોકેલિટીનો અભાવ છે. YARN ની તમામ ખામીઓ હોવા છતાં, તેનો ઉપયોગ કરવાના ફાયદા પણ હતા, ઉદાહરણ તરીકે, ડેટાને કોડ પહોંચાડવાનો સિદ્ધાંત (ડેટાથી કોડને બદલે). તેના માટે આભાર, સ્પાર્ક કાર્યો નોડ્સ પર એક્ઝિક્યુટ કરવામાં આવ્યા હતા જ્યાં ગણતરીમાં સામેલ ડેટા સ્થિત હતો, અને નેટવર્ક પર ડેટા પહોંચાડવામાં જે સમય લાગ્યો હતો તે નોંધપાત્ર રીતે ઘટાડવામાં આવ્યો હતો. કુબરનેટ્સનો ઉપયોગ કરતી વખતે, અમને સમગ્ર નેટવર્ક પર કાર્યમાં સામેલ ડેટાને ખસેડવાની જરૂરિયાતનો સામનો કરવો પડે છે. જો તેઓ પૂરતા પ્રમાણમાં મોટા હોય, તો કાર્ય અમલીકરણનો સમય નોંધપાત્ર રીતે વધી શકે છે, અને તેમના કામચલાઉ સ્ટોરેજ માટે સ્પાર્ક ટાસ્ક ઇન્સ્ટન્સને ફાળવવામાં આવેલી ડિસ્ક સ્પેસની પણ જરૂર પડે છે. આ ગેરલાભને વિશિષ્ટ સોફ્ટવેરનો ઉપયોગ કરીને ઘટાડી શકાય છે જે કુબરનેટ્સ (ઉદાહરણ તરીકે, એલુક્સિયો) માં ડેટા સ્થાનની ખાતરી કરે છે, પરંતુ આનો અર્થ એ છે કે કુબરનેટ્સ ક્લસ્ટરના નોડ્સ પર ડેટાની સંપૂર્ણ નકલ સંગ્રહિત કરવાની જરૂરિયાત છે.
2. બીજો મહત્વનો ગેરલાભ એ સુરક્ષા છે. મૂળભૂત રીતે, ચાલતા સ્પાર્ક કાર્યોને લગતી સુરક્ષા-સંબંધિત સુવિધાઓ અક્ષમ છે, કર્બેરોસનો ઉપયોગ સત્તાવાર દસ્તાવેજોમાં આવરી લેવામાં આવ્યો નથી (જોકે અનુરૂપ વિકલ્પો સંસ્કરણ 3.0.0 માં રજૂ કરવામાં આવ્યા હતા, જેને વધારાના કાર્યની જરૂર પડશે), અને સુરક્ષા દસ્તાવેજીકરણ માટે Spark (https://spark.apache.org/docs/2.4.5/security.html) નો ઉપયોગ કરીને ફક્ત યાર્ન, મેસોસ અને સ્ટેન્ડઅલોન ક્લસ્ટર કી સ્ટોર તરીકે દેખાય છે. તે જ સમયે, વપરાશકર્તા કે જેના હેઠળ સ્પાર્ક કાર્યો શરૂ કરવામાં આવ્યા છે તેનો સીધો ઉલ્લેખ કરી શકાતો નથી - અમે ફક્ત તે સેવા એકાઉન્ટનો ઉલ્લેખ કરીએ છીએ કે જેના હેઠળ તે કાર્ય કરશે, અને વપરાશકર્તાને ગોઠવેલ સુરક્ષા નીતિઓના આધારે પસંદ કરવામાં આવે છે. આ સંદર્ભે, કાં તો રુટ વપરાશકર્તાનો ઉપયોગ કરવામાં આવે છે, જે ઉત્પાદક વાતાવરણમાં સલામત નથી, અથવા રેન્ડમ UID ધરાવતા વપરાશકર્તા, જે ડેટાના ઍક્સેસ અધિકારોનું વિતરણ કરતી વખતે અસુવિધાજનક છે (આ PodSecurity Policies બનાવીને અને તેને લિંક કરીને ઉકેલી શકાય છે. અનુરૂપ સેવા એકાઉન્ટ્સ). હાલમાં, ઉકેલ એ છે કે કાં તો બધી જરૂરી ફાઈલોને સીધી ડોકર ઈમેજમાં મૂકો, અથવા તમારી સંસ્થામાં અપનાવવામાં આવેલા રહસ્યોને સંગ્રહિત કરવા અને પુનઃપ્રાપ્ત કરવા માટેની પદ્ધતિનો ઉપયોગ કરવા માટે સ્પાર્ક લોન્ચ સ્ક્રિપ્ટમાં ફેરફાર કરો.
3. કુબરનેટ્સનો ઉપયોગ કરીને સ્પાર્ક જોબ્સ ચલાવવાનું સત્તાવાર રીતે હજી પણ પ્રાયોગિક મોડમાં છે અને ભવિષ્યમાં ઉપયોગમાં લેવાતી કલાકૃતિઓમાં નોંધપાત્ર ફેરફારો થઈ શકે છે. અને ખરેખર, સામગ્રી તૈયાર કરતી વખતે, સંસ્કરણ 2.3.0 અને 2.4.5 નું પરીક્ષણ કરવામાં આવ્યું હતું, વર્તન નોંધપાત્ર રીતે અલગ હતું.

ચાલો અપડેટ્સની રાહ જોઈએ - તાજેતરમાં સ્પાર્ક (3.0.0) નું નવું સંસ્કરણ બહાર પાડવામાં આવ્યું હતું, જેણે કુબરનેટ્સ પર સ્પાર્કના કાર્યમાં નોંધપાત્ર ફેરફારો કર્યા હતા, પરંતુ આ સંસાધન સંચાલક માટે સમર્થનની પ્રાયોગિક સ્થિતિ જાળવી રાખી હતી. કદાચ આગામી અપડેટ્સ તમારી સિસ્ટમની સુરક્ષા માટે ડર્યા વિના અને કાર્યાત્મક ઘટકોને સ્વતંત્ર રીતે સંશોધિત કરવાની જરૂર વિના યાર્નને સંપૂર્ણપણે છોડી દેવા અને કુબરનેટ્સ પર સ્પાર્ક કાર્યો ચલાવવાની ભલામણ કરવાનું ખરેખર શક્ય બનાવશે.

ફિન.

સોર્સ: www.habr.com