കുബർനെറ്റസിൽ അപ്പാച്ചെ സ്പാർക്ക് പ്രവർത്തിപ്പിക്കുന്നു

പ്രിയ വായനക്കാരേ, ശുഭ സായാഹ്നം. ഇന്ന് നമ്മൾ അപ്പാച്ചെ സ്പാർക്കിനെക്കുറിച്ചും അതിന്റെ വികസന സാധ്യതകളെക്കുറിച്ചും കുറച്ച് സംസാരിക്കും.

ബിഗ് ഡാറ്റയുടെ ആധുനിക ലോകത്ത്, ബാച്ച് ഡാറ്റ പ്രോസസ്സിംഗ് ടാസ്‌ക്കുകൾ വികസിപ്പിക്കുന്നതിനുള്ള യഥാർത്ഥ സ്റ്റാൻഡേർഡാണ് അപ്പാച്ചെ സ്പാർക്ക്. കൂടാതെ, മൈക്രോ ബാച്ച് ആശയത്തിൽ പ്രവർത്തിക്കുന്ന സ്ട്രീമിംഗ് ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിക്കുന്നതിനും ചെറിയ ഭാഗങ്ങളിൽ ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നതിനും ഷിപ്പിംഗ് ചെയ്യുന്നതിനും ഇത് ഉപയോഗിക്കുന്നു (സ്പാർക്ക് സ്ട്രക്ചേർഡ് സ്ട്രീമിംഗ്). കൂടാതെ പരമ്പരാഗതമായി ഇത് മൊത്തത്തിലുള്ള ഹഡൂപ്പ് സ്റ്റാക്കിന്റെ ഭാഗമാണ്, റിസോഴ്‌സ് മാനേജരായി YARN (അല്ലെങ്കിൽ ചില സന്ദർഭങ്ങളിൽ Apache Mesos) ഉപയോഗിക്കുന്നു. 2020-ഓടെ, മാന്യമായ ഹഡൂപ്പ് വിതരണങ്ങളുടെ അഭാവം മൂലം മിക്ക കമ്പനികൾക്കും അതിന്റെ പരമ്പരാഗത രൂപത്തിൽ അതിന്റെ ഉപയോഗം സംശയാസ്പദമാണ് - HDP, CDH എന്നിവയുടെ വികസനം നിലച്ചു, CDH നന്നായി വികസിച്ചിട്ടില്ല, ഉയർന്ന ചിലവുണ്ട്, ശേഷിക്കുന്ന ഹഡൂപ്പ് വിതരണക്കാർ ഒന്നുകിൽ നിലവിലില്ല അല്ലെങ്കിൽ മങ്ങിയ ഭാവി ഉണ്ടായിരിക്കും. അതിനാൽ, കുബർനെറ്റസ് ഉപയോഗിച്ച് അപ്പാച്ചെ സ്പാർക്കിന്റെ സമാരംഭം കമ്മ്യൂണിറ്റിയിലും വൻകിട കമ്പനികളിലും താൽപ്പര്യം വർദ്ധിപ്പിക്കുന്നു - സ്വകാര്യ, പൊതു ക്ലൗഡുകളിൽ കണ്ടെയ്നർ ഓർക്കസ്ട്രേഷനിലും റിസോഴ്സ് മാനേജ്മെന്റിലും ഒരു സ്റ്റാൻഡേർഡ് ആയി മാറുന്നു, ഇത് YARN-ലെ സ്പാർക്ക് ടാസ്ക്കുകളുടെ അസൌകര്യമായ റിസോഴ്സ് ഷെഡ്യൂളിംഗിലെ പ്രശ്നം പരിഹരിക്കുകയും നൽകുന്നു. എല്ലാ വലുപ്പത്തിലും വരകളിലുമുള്ള കമ്പനികൾക്കായി നിരവധി വാണിജ്യപരവും തുറന്നതുമായ വിതരണങ്ങളുള്ള ക്രമാനുഗതമായി വികസിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു പ്ലാറ്റ്ഫോം. കൂടാതെ, ജനപ്രീതിയുടെ പശ്ചാത്തലത്തിൽ, മിക്കവർക്കും ഇതിനകം തന്നെ സ്വന്തമായി രണ്ട് ഇൻസ്റ്റാളേഷനുകൾ നേടാനും അതിന്റെ ഉപയോഗത്തിൽ അവരുടെ വൈദഗ്ദ്ധ്യം വർദ്ധിപ്പിക്കാനും കഴിഞ്ഞു, ഇത് നീക്കം ലളിതമാക്കുന്നു.

പതിപ്പ് 2.3.0 മുതൽ, അപ്പാച്ചെ സ്പാർക്ക് ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ ടാസ്‌ക്കുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് ഔദ്യോഗിക പിന്തുണ നേടി, ഇന്ന്, ഈ സമീപനത്തിന്റെ നിലവിലെ പക്വതയെക്കുറിച്ചും അതിന്റെ ഉപയോഗത്തിനുള്ള വിവിധ ഓപ്ഷനുകളെക്കുറിച്ചും നടപ്പിലാക്കുമ്പോൾ നേരിടുന്ന അപകടങ്ങളെക്കുറിച്ചും ഞങ്ങൾ സംസാരിക്കും.

ഒന്നാമതായി, അപ്പാച്ചെ സ്പാർക്കിനെ അടിസ്ഥാനമാക്കി ടാസ്‌ക്കുകളും ആപ്ലിക്കേഷനുകളും വികസിപ്പിക്കുന്ന പ്രക്രിയ നോക്കാം, കൂടാതെ നിങ്ങൾ ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ ഒരു ടാസ്‌ക് പ്രവർത്തിപ്പിക്കേണ്ട സാധാരണ കേസുകൾ ഹൈലൈറ്റ് ചെയ്യുക. ഈ പോസ്റ്റ് തയ്യാറാക്കുമ്പോൾ, 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

Kubernetes-ൽ Spark jobs പ്രവർത്തിപ്പിക്കുന്നതിന്, അടിസ്ഥാന ഇമേജായി ഉപയോഗിക്കുന്നതിന് നിങ്ങൾ ഒരു ഡോക്കർ ഇമേജ് സൃഷ്ടിക്കേണ്ടതുണ്ട്. ഇവിടെ സാധ്യമായ 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

അതിന്റെ സഹായത്തോടെ, സ്പാർക്ക് ഉപയോഗിച്ച് പൈ കണക്കാക്കുന്നതിനുള്ള ഒരു ടെസ്റ്റ് ടാസ്‌ക് അടങ്ങിയ ഒരു അടിസ്ഥാന സ്പാർക്ക് ഇമേജ് ഞങ്ങൾ കൂട്ടിച്ചേർക്കുന്നു (ഇവിടെ {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 ക്ലസ്റ്ററിലേക്ക് ഒരു സ്പാർക്ക് ടാസ്ക്ക് പ്രസിദ്ധീകരിക്കാൻ നമുക്ക് 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

ഇവിടെ:

- പേര് - കുബെർനെറ്റസ് പോഡുകളുടെ പേരിന്റെ രൂപീകരണത്തിൽ പങ്കെടുക്കുന്ന ചുമതലയുടെ പേര്;

—class — എക്സിക്യൂട്ടബിൾ ഫയലിന്റെ ക്ലാസ്, ടാസ്ക് ആരംഭിക്കുമ്പോൾ വിളിക്കുന്നു;

—conf — സ്പാർക്ക് കോൺഫിഗറേഷൻ പാരാമീറ്ററുകൾ;

spark.executor.instances — സമാരംഭിക്കാനുള്ള സ്പാർക്ക് എക്സിക്യൂട്ടർമാരുടെ എണ്ണം;

spark.kubernetes.authenticate.driver.serviceAccountName - പോഡുകൾ സമാരംഭിക്കുമ്പോൾ ഉപയോഗിക്കുന്ന Kubernetes സേവന അക്കൗണ്ടിന്റെ പേര് (Kubernetes API-യുമായി ഇടപഴകുമ്പോൾ സുരക്ഷാ സന്ദർഭവും കഴിവുകളും നിർവചിക്കാൻ);

spark.kubernetes.namespace — ഡ്രൈവർ, എക്സിക്യൂട്ടർ പോഡുകൾ ലോഞ്ച് ചെയ്യുന്ന കുബർനെറ്റസ് നെയിംസ്പേസ്;

spark.submit.deployMode — സ്പാർക്ക് ലോഞ്ച് ചെയ്യുന്ന രീതി (സാധാരണ സ്പാർക്ക്-സബ്മിറ്റ് "ക്ലസ്റ്റർ" ഉപയോഗിക്കുന്നു, സ്പാർക്ക് ഓപ്പറേറ്റർക്കും പിന്നീടുള്ള സ്പാർക്ക് "ക്ലയന്റ്" പതിപ്പുകൾക്കും);

spark.kubernetes.container.image - പോഡുകൾ വിക്ഷേപിക്കാൻ ഉപയോഗിക്കുന്ന ഡോക്കർ ചിത്രം;

spark.master — Kubernetes API URL (ബാഹ്യ വ്യക്തമാക്കിയിരിക്കുന്നതിനാൽ ലോക്കൽ മെഷീനിൽ നിന്ന് ആക്‌സസ്സ് സംഭവിക്കുന്നു);

ഡോക്കർ ഇമേജിനുള്ളിൽ എക്സിക്യൂട്ടബിൾ സ്പാർക്കിലേക്കുള്ള പാതയാണ് local://.

ഞങ്ങൾ അനുബന്ധ OKD പ്രോജക്റ്റിലേക്ക് പോയി സൃഷ്ടിച്ച പോഡുകൾ പഠിക്കുന്നു - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods.

വികസന പ്രക്രിയ ലളിതമാക്കാൻ, മറ്റൊരു ഓപ്‌ഷൻ ഉപയോഗിക്കാം, അതിൽ സ്പാർക്കിന്റെ ഒരു പൊതു അടിസ്ഥാന ഇമേജ് സൃഷ്‌ടിക്കുകയും എല്ലാ ടാസ്‌ക്കുകളും പ്രവർത്തിപ്പിക്കുന്നതിനായി ഉപയോഗിക്കുകയും എക്‌സിക്യൂട്ടബിൾ ഫയലുകളുടെ സ്‌നാപ്പ്‌ഷോട്ടുകൾ ബാഹ്യ സ്റ്റോറേജിലേക്ക് പ്രസിദ്ധീകരിക്കുകയും (ഉദാഹരണത്തിന്, ഹഡൂപ്പ്) വിളിക്കുമ്പോൾ വ്യക്തമാക്കുകയും ചെയ്യുന്നു. സ്പാർക്ക്-ഒരു ലിങ്കായി സമർപ്പിക്കുക. ഈ സാഹചര്യത്തിൽ, ഡോക്കർ ഇമേജുകൾ പുനർനിർമ്മിക്കാതെ തന്നെ നിങ്ങൾക്ക് സ്പാർക്ക് ടാസ്ക്കുകളുടെ വ്യത്യസ്ത പതിപ്പുകൾ പ്രവർത്തിപ്പിക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, ഇമേജുകൾ പ്രസിദ്ധീകരിക്കാൻ 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-ലേക്ക് അപ്‌ലോഡ് ചെയ്‌ത സ്‌പാർക്ക് ഫയൽ ഉപയോഗിച്ച് നമുക്ക് സ്പാർക്ക്-സബ്മിറ്റ് ചെയ്യാൻ കഴിയും (ഇവിടെ {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 ഡയറക്‌ടറിയിലേക്ക് പകർത്തുന്നതിന് ഡോക്കർഫയലിലേക്ക് ഒരു നിർദ്ദേശം ചേർക്കുക. എൻട്രി പോയിന്റിൽ SPARK_CLASSPATH-ൽ HDFS കോൺഫിഗറേഷൻ ഫയൽ ഉൾപ്പെടുത്തുക.

രണ്ടാമത്തെ ഉപയോഗ കേസ് - അപ്പാച്ചെ ലിവി

കൂടാതെ, ഒരു ടാസ്‌ക് വികസിപ്പിച്ച് ഫലം പരിശോധിക്കേണ്ടിവരുമ്പോൾ, CI/CD പ്രക്രിയയുടെ ഭാഗമായി അത് സമാരംഭിക്കുകയും അതിന്റെ നിർവ്വഹണ നില ട്രാക്കുചെയ്യുകയും ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള ചോദ്യം ഉയർന്നുവരുന്നു. തീർച്ചയായും, നിങ്ങൾക്ക് ഒരു ലോക്കൽ സ്പാർക്ക്-സബ്മിറ്റ് കോൾ ഉപയോഗിച്ച് ഇത് പ്രവർത്തിപ്പിക്കാം, എന്നാൽ ഇത് CI/CD ഇൻഫ്രാസ്ട്രക്ചറിനെ സങ്കീർണ്ണമാക്കുന്നു, കാരണം ഇതിന് CI സെർവർ ഏജന്റുമാരിൽ/റണ്ണറുകളിൽ സ്പാർക്ക് ഇൻസ്റ്റാൾ ചെയ്യുകയും കോൺഫിഗർ ചെയ്യുകയും Kubernetes API-യിലേക്കുള്ള ആക്സസ് സജ്ജീകരിക്കുകയും വേണം. ഈ സാഹചര്യത്തിൽ, ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിനുള്ളിൽ ഹോസ്റ്റ് ചെയ്‌തിരിക്കുന്ന സ്പാർക്ക് ടാസ്‌ക്കുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് ഒരു REST API ആയി Apache Livy ഉപയോഗിക്കാൻ ടാർഗെറ്റ് നടപ്പിലാക്കൽ തിരഞ്ഞെടുത്തു. അതിന്റെ സഹായത്തോടെ, സാധാരണ cURL അഭ്യർത്ഥനകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഒരു Kubernetes ക്ലസ്റ്ററിൽ Spark ടാസ്‌ക്കുകൾ പ്രവർത്തിപ്പിക്കാൻ കഴിയും, അത് ഏത് CI സൊല്യൂഷനെയും അടിസ്ഥാനമാക്കി എളുപ്പത്തിൽ നടപ്പിലാക്കും, കൂടാതെ Kubernetes API-യുമായി സംവദിക്കുമ്പോൾ ആധികാരികത ഉറപ്പാക്കുന്നതിനുള്ള പ്രശ്നം Kubernetes ക്ലസ്റ്ററിനുള്ളിൽ സ്ഥാപിക്കുന്നത് പരിഹരിക്കുന്നു.

ഒരു രണ്ടാം ഉപയോഗ കേസായി നമുക്ക് ഇത് ഹൈലൈറ്റ് ചെയ്യാം - ഒരു ടെസ്റ്റ് ലൂപ്പിലെ ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ ഒരു CI/CD പ്രോസസിന്റെ ഭാഗമായി സ്പാർക്ക് ടാസ്‌ക്കുകൾ പ്രവർത്തിപ്പിക്കുന്നു.

അപ്പാച്ചെ ലിവിയെക്കുറിച്ച് അൽപ്പം - ഇത് ഒരു വെബ് ഇന്റർഫേസും ആവശ്യമായ പാരാമീറ്ററുകൾ പാസാക്കി സ്പാർക്ക്-സബ്മിറ്റ് വിദൂരമായി സമാരംഭിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു RESTful API നൽകുന്ന ഒരു HTTP സെർവറായി പ്രവർത്തിക്കുന്നു. പരമ്പരാഗതമായി ഇത് ഒരു HDP വിതരണത്തിന്റെ ഭാഗമായാണ് ഷിപ്പ് ചെയ്‌തിരിക്കുന്നത്, എന്നാൽ ഉചിതമായ മാനിഫെസ്റ്റും ഇതുപോലുള്ള ഒരു കൂട്ടം ഡോക്കർ ഇമേജുകളും ഉപയോഗിച്ച് 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 റിപ്പോസിറ്ററി. ഇത് വിന്യസിക്കാൻ, ഇനിപ്പറയുന്ന മാനിഫെസ്റ്റ് ഉപയോഗിക്കുക ({registry-url} - ഡോക്കർ ഇമേജ് രജിസ്ട്രിയുടെ URL, {image-name} - ഡോക്കർ ഇമേജിന്റെ പേര്, {tag} - ഡോക്കർ ഇമേജ് ടാഗ്, {livy-url} - ആവശ്യമുള്ള URL എവിടെയാണ് സെർവർ ലിവി ആക്‌സസ് ചെയ്യാവുന്നതാണ്; കുബെർനെറ്റസ് വിതരണമായി Red Hat OpenShift ഉപയോഗിക്കുകയാണെങ്കിൽ “റൂട്ട്” മാനിഫെസ്റ്റ് ഉപയോഗിക്കും, അല്ലാത്തപക്ഷം നോഡ്‌പോർട്ട് തരത്തിന്റെ അനുബന്ധ ഇൻഗ്രെസ് അല്ലെങ്കിൽ സേവന മാനിഫെസ്റ്റ് ഉപയോഗിക്കുന്നു:

---
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. Livy ഉപയോഗിച്ച്, പോസ്റ്റ്‌മാനിൽ നിന്നുള്ള ഒരു 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) ഒരു സെഷൻ ദൃശ്യമാകും, അതിനുള്ളിൽ, Livy API അല്ലെങ്കിൽ ഗ്രാഫിക്കൽ ഇന്റർഫേസ് ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ടാസ്‌ക്കിന്റെ പുരോഗതി ട്രാക്കുചെയ്യാനും സെഷൻ പഠിക്കാനും കഴിയും. രേഖകൾ.

ഇനി ലിവി എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണിക്കാം. ഇത് ചെയ്യുന്നതിന്, ലിവി സെർവർ ഉപയോഗിച്ച് പോഡിനുള്ളിലെ ലിവി കണ്ടെയ്‌നറിന്റെ ലോഗുകൾ പരിശോധിക്കാം - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods/{livy-pod-name }?ടാബ്=ലോഗുകൾ. "livy" എന്ന് പേരിട്ടിരിക്കുന്ന ഒരു കണ്ടെയ്‌നറിൽ Livy REST API-യെ വിളിക്കുമ്പോൾ, മുകളിൽ ഞങ്ങൾ ഉപയോഗിച്ചതിന് സമാനമായി ഒരു സ്പാർക്ക്-സബ്മിറ്റ് എക്സിക്യൂട്ട് ചെയ്യപ്പെടുന്നതായി അവയിൽ നിന്ന് നമുക്ക് കാണാൻ കഴിയും (ഇവിടെ {livy-pod-name} എന്നത് സൃഷ്ടിച്ച പോഡിന്റെ പേരാണ്. ലിവി സെർവർ ഉപയോഗിച്ച്). ഒരു ലിവി സെർവർ ഉപയോഗിച്ച് എക്സിക്യൂട്ടബിൾ സ്പാർക്ക് വിദൂരമായി ഹോസ്റ്റുചെയ്യുന്ന ടാസ്‌ക്കുകൾ പ്രവർത്തിപ്പിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന രണ്ടാമത്തെ അന്വേഷണവും ശേഖരം അവതരിപ്പിക്കുന്നു.

മൂന്നാമത്തെ ഉപയോഗ കേസ് - സ്പാർക്ക് ഓപ്പറേറ്റർ

ഇപ്പോൾ ടാസ്ക് പരീക്ഷിച്ചുകഴിഞ്ഞാൽ, ഇത് പതിവായി പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള ചോദ്യം ഉയർന്നുവരുന്നു. ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ പതിവായി ടാസ്‌ക്കുകൾ പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള നേറ്റീവ് മാർഗം ക്രോൺജോബ് എന്റിറ്റിയാണ്, നിങ്ങൾക്ക് ഇത് ഉപയോഗിക്കാം, എന്നാൽ ഇപ്പോൾ കുബെർനെറ്റസിലെ ആപ്ലിക്കേഷനുകൾ നിയന്ത്രിക്കുന്നതിന് ഓപ്പറേറ്റർമാരുടെ ഉപയോഗം വളരെ ജനപ്രിയമാണ്, കൂടാതെ സ്പാർക്കിന് വളരെ പക്വതയുള്ള ഒരു ഓപ്പറേറ്റർ ഉണ്ട്, അതും. എന്റർപ്രൈസ് ലെവൽ സൊല്യൂഷനുകളിൽ ഉപയോഗിക്കുന്നു (ഉദാഹരണത്തിന്, Lightbend FastData പ്ലാറ്റ്ഫോം). ഇത് ഉപയോഗിക്കാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു - സ്പാർക്കിന്റെ (2.4.5) നിലവിലെ സ്ഥിരതയുള്ള പതിപ്പിന് കുബർനെറ്റസിൽ സ്പാർക്ക് ടാസ്‌ക്കുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് പരിമിതമായ കോൺഫിഗറേഷൻ ഓപ്ഷനുകളുണ്ട്, അതേസമയം അടുത്ത പ്രധാന പതിപ്പ് (3.0.0) കുബർനെറ്റസിന് പൂർണ്ണ പിന്തുണ പ്രഖ്യാപിക്കുന്നു, പക്ഷേ അതിന്റെ റിലീസ് തീയതി അജ്ഞാതമായി തുടരുന്നു. . പ്രധാനപ്പെട്ട കോൺഫിഗറേഷൻ ഓപ്‌ഷനുകൾ (ഉദാഹരണത്തിന്, സ്‌പാർക്ക് പോഡുകളിലേക്ക് ഹഡൂപ്പ് ആക്‌സസ് കോൺഫിഗറേഷനോടുകൂടിയ കോൺഫിഗറേഷൻ മാപ്പ് മൗണ്ടുചെയ്യൽ) കൂടാതെ പതിവായി ഷെഡ്യൂൾ ചെയ്‌ത ടാസ്‌ക്ക് പ്രവർത്തിപ്പിക്കാനുള്ള കഴിവ് എന്നിവ ചേർത്ത് സ്പാർക്ക് ഓപ്പറേറ്റർ ഈ പോരായ്മ നികത്തുന്നു.

ഒരു മൂന്നാം ഉപയോഗ കേസായി നമുക്ക് ഇത് ഹൈലൈറ്റ് ചെയ്യാം - ഒരു പ്രൊഡക്ഷൻ ലൂപ്പിലെ കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ പതിവായി സ്പാർക്ക് ടാസ്‌ക്കുകൾ പ്രവർത്തിപ്പിക്കുന്നു.

സ്പാർക്ക് ഓപ്പറേറ്റർ ഓപ്പൺ സോഴ്സ് ആണ് കൂടാതെ Google ക്ലൗഡ് പ്ലാറ്റ്ഫോമിൽ വികസിപ്പിച്ചതാണ് - github.com/GoogleCloudPlatform/spark-on-k8s-operator. അതിന്റെ ഇൻസ്റ്റാളേഷൻ 3 തരത്തിൽ ചെയ്യാം:

1. Lightbend FastData പ്ലാറ്റ്ഫോം/Cloudflow ഇൻസ്റ്റലേഷന്റെ ഭാഗമായി;
2. ഹെൽമിന്റെ ഉപയോഗം:

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

3. ഔദ്യോഗിക ശേഖരത്തിൽ നിന്നുള്ള മാനിഫെസ്റ്റുകൾ ഉപയോഗിക്കുന്നു (https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/tree/master/manifest). ഇനിപ്പറയുന്നവ ശ്രദ്ധിക്കേണ്ടതാണ് - ക്ലൗഡ്ഫ്ലോയിൽ 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" നിഘണ്ടു ഉപയോഗിക്കുന്ന സ്പാർക്കിന്റെ പതിപ്പ് സൂചിപ്പിക്കണം;
  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 കോൺഫിഗറേഷനുള്ള ഒരു കോൺഫിഗ്മാപ്പ് വ്യക്തമാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. ടാസ്‌ക്കുകൾ പതിവായി പ്രവർത്തിപ്പിക്കുന്നതിനും ഇത് അനുയോജ്യമാണ് - “ഷെഡ്യൂൾ” പാരാമീറ്റർ ഉപയോഗിച്ച്, തന്നിരിക്കുന്ന ടാസ്‌ക് പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള ഒരു ഷെഡ്യൂൾ വ്യക്തമാക്കാം.

അതിനുശേഷം, ഞങ്ങൾ ഞങ്ങളുടെ മാനിഫെസ്റ്റ് 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) നിലവിലെ സ്ഥിരതയുള്ള പതിപ്പ് ഉപയോഗിക്കുന്നതിന്റെ കണ്ടെത്തിയ ദോഷങ്ങൾ പരിഗണിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു:

1. ആദ്യത്തേതും, ഒരുപക്ഷേ, പ്രധാന പോരായ്മയും ഡാറ്റ ലോക്കാലിറ്റിയുടെ അഭാവമാണ്. YARN-ന്റെ എല്ലാ പോരായ്മകളും ഉണ്ടായിരുന്നിട്ടും, അത് ഉപയോഗിക്കുന്നതിനുള്ള ഗുണങ്ങളും ഉണ്ടായിരുന്നു, ഉദാഹരണത്തിന്, ഡാറ്റയിലേക്ക് കോഡ് ഡെലിവർ ചെയ്യുന്ന തത്വം (കോഡിലേക്കുള്ള ഡാറ്റയ്ക്ക് പകരം). ഇതിന് നന്ദി, കണക്കുകൂട്ടലുകളിൽ ഉൾപ്പെട്ടിരിക്കുന്ന ഡാറ്റ സ്ഥിതിചെയ്യുന്ന നോഡുകളിൽ സ്പാർക്ക് ടാസ്ക്കുകൾ നിർവ്വഹിച്ചു, കൂടാതെ നെറ്റ്വർക്കിലൂടെ ഡാറ്റ കൈമാറാൻ എടുത്ത സമയം ഗണ്യമായി കുറഞ്ഞു. Kubernetes ഉപയോഗിക്കുമ്പോൾ, ഒരു ടാസ്‌ക്കിൽ ഉൾപ്പെട്ടിരിക്കുന്ന ഡാറ്റ നെറ്റ്‌വർക്കിലുടനീളം നീക്കേണ്ടതിന്റെ ആവശ്യകത ഞങ്ങൾ അഭിമുഖീകരിക്കുന്നു. അവ ആവശ്യത്തിന് വലുതാണെങ്കിൽ, ടാസ്‌ക് എക്‌സിക്യൂഷൻ സമയം ഗണ്യമായി വർദ്ധിക്കും, കൂടാതെ സ്‌പാർക്ക് ടാസ്‌ക് ഇൻസ്‌റ്റൻസുകൾക്ക് അവയുടെ താത്കാലിക സംഭരണത്തിനായി നീക്കിവച്ചിരിക്കുന്ന ഡിസ്‌ക് സ്‌പേസ് ആവശ്യമായി വരും. Kubernetes-ൽ (ഉദാഹരണത്തിന്, Alluxio) ഡാറ്റാ പ്രദേശം ഉറപ്പാക്കുന്ന പ്രത്യേക സോഫ്‌റ്റ്‌വെയർ ഉപയോഗിച്ച് ഈ പോരായ്മ ലഘൂകരിക്കാനാകും, എന്നാൽ ഇത് യഥാർത്ഥത്തിൽ കുബർനെറ്റസ് ക്ലസ്റ്ററിന്റെ നോഡുകളിൽ ഡാറ്റയുടെ പൂർണ്ണമായ പകർപ്പ് സംഭരിക്കേണ്ടതിന്റെ ആവശ്യകതയെ അർത്ഥമാക്കുന്നു.
2. രണ്ടാമത്തെ പ്രധാന പോരായ്മ സുരക്ഷയാണ്. ഡിഫോൾട്ടായി, സ്പാർക്ക് ടാസ്ക്കുകൾ പ്രവർത്തിപ്പിക്കുന്നതുമായി ബന്ധപ്പെട്ട സുരക്ഷാ സംബന്ധിയായ സവിശേഷതകൾ പ്രവർത്തനരഹിതമാക്കിയിരിക്കുന്നു, കെർബറോസിന്റെ ഉപയോഗം ഔദ്യോഗിക ഡോക്യുമെന്റേഷനിൽ ഉൾപ്പെടുത്തിയിട്ടില്ല (അനുബന്ധ ഓപ്ഷനുകൾ പതിപ്പ് 3.0.0-ൽ അവതരിപ്പിച്ചിട്ടുണ്ടെങ്കിലും, ഇതിന് അധിക ജോലി ആവശ്യമായി വരും), കൂടാതെ സുരക്ഷാ ഡോക്യുമെന്റേഷനും Spark (https://spark.apache.org/docs/2.4.5/security.html) ഉപയോഗിച്ച് YARN, Mesos, Standalone Cluster എന്നിവ മാത്രമേ പ്രധാന സ്റ്റോറുകളായി ദൃശ്യമാകൂ. അതേ സമയം, സ്പാർക്ക് ടാസ്‌ക്കുകൾ ലോഞ്ച് ചെയ്യുന്ന ഉപയോക്താവിനെ നേരിട്ട് വ്യക്തമാക്കാൻ കഴിയില്ല - അത് പ്രവർത്തിക്കുന്ന സേവന അക്കൗണ്ട് മാത്രമാണ് ഞങ്ങൾ വ്യക്തമാക്കുന്നത്, കോൺഫിഗർ ചെയ്‌ത സുരക്ഷാ നയങ്ങളെ അടിസ്ഥാനമാക്കിയാണ് ഉപയോക്താവിനെ തിരഞ്ഞെടുക്കുന്നത്. ഇക്കാര്യത്തിൽ, ഒന്നുകിൽ റൂട്ട് ഉപയോക്താവ് ഉപയോഗിക്കുന്നു, അത് ഉൽപ്പാദനപരമായ അന്തരീക്ഷത്തിൽ സുരക്ഷിതമല്ല, അല്ലെങ്കിൽ റാൻഡം യുഐഡി ഉള്ള ഒരു ഉപയോക്താവ്, ഡാറ്റയിലേക്കുള്ള ആക്സസ് അവകാശങ്ങൾ വിതരണം ചെയ്യുമ്പോൾ ഇത് അസൗകര്യമുണ്ടാക്കുന്നു (PodSecurityPolicies സൃഷ്ടിച്ച് അവയെ ലിങ്ക് ചെയ്യുന്നതിലൂടെ ഇത് പരിഹരിക്കാനാകും. അനുബന്ധ സേവന അക്കൗണ്ടുകൾ). നിലവിൽ, ഒന്നുകിൽ ആവശ്യമായ എല്ലാ ഫയലുകളും ഡോക്കർ ഇമേജിലേക്ക് നേരിട്ട് സ്ഥാപിക്കുക അല്ലെങ്കിൽ നിങ്ങളുടെ സ്ഥാപനത്തിൽ സ്വീകരിച്ച രഹസ്യങ്ങൾ സംഭരിക്കുന്നതിനും വീണ്ടെടുക്കുന്നതിനുമുള്ള സംവിധാനം ഉപയോഗിക്കുന്നതിന് സ്പാർക്ക് ലോഞ്ച് സ്ക്രിപ്റ്റ് പരിഷ്ക്കരിക്കുക എന്നതാണ് പരിഹാരം.
3. Kubernetes ഉപയോഗിച്ച് സ്പാർക്ക് ജോലികൾ പ്രവർത്തിപ്പിക്കുന്നത് ഔദ്യോഗികമായി ഇപ്പോഴും പരീക്ഷണാത്മക മോഡിലാണ്, ഭാവിയിൽ ഉപയോഗിക്കുന്ന ആർട്ടിഫാക്റ്റുകളിൽ (കോൺഫിഗറേഷൻ ഫയലുകൾ, ഡോക്കർ ബേസ് ഇമേജുകൾ, ലോഞ്ച് സ്ക്രിപ്റ്റുകൾ) കാര്യമായ മാറ്റങ്ങൾ ഉണ്ടായേക്കാം. തീർച്ചയായും, മെറ്റീരിയൽ തയ്യാറാക്കുമ്പോൾ, 2.3.0, 2.4.5 പതിപ്പുകൾ പരീക്ഷിച്ചു, സ്വഭാവം വളരെ വ്യത്യസ്തമായിരുന്നു.

അപ്‌ഡേറ്റുകൾക്കായി നമുക്ക് കാത്തിരിക്കാം - സ്പാർക്കിന്റെ (3.0.0) ഒരു പുതിയ പതിപ്പ് അടുത്തിടെ പുറത്തിറങ്ങി, ഇത് കുബർനെറ്റസിലെ സ്പാർക്കിന്റെ പ്രവർത്തനത്തിൽ കാര്യമായ മാറ്റങ്ങൾ വരുത്തി, എന്നാൽ ഈ റിസോഴ്സ് മാനേജറിനുള്ള പിന്തുണയുടെ പരീക്ഷണാത്മക നില നിലനിർത്തി. ഒരുപക്ഷേ അടുത്ത അപ്‌ഡേറ്റുകൾ നിങ്ങളുടെ സിസ്റ്റത്തിന്റെ സുരക്ഷയെ ഭയപ്പെടാതെയും പ്രവർത്തന ഘടകങ്ങളെ സ്വതന്ത്രമായി പരിഷ്‌ക്കരിക്കേണ്ടതില്ലാതെയും നൂൽ ഉപേക്ഷിക്കാനും കുബർനെറ്റസിൽ സ്പാർക്ക് ടാസ്‌ക്കുകൾ പ്രവർത്തിപ്പിക്കാനും പൂർണ്ണമായി ശുപാർശ ചെയ്യുന്നത് സാധ്യമാക്കും.

ഫിൻ.

അവലംബം: www.habr.com