Darbojas Apache Spark vietnē Kubernetes

Cienījamie lasītāji, laba pēcpusdiena. Šodien mēs nedaudz runāsim par Apache Spark un tās attīstības perspektīvām.

Mūsdienu lielo datu pasaulē Apache Spark ir de facto standarts pakešu datu apstrādes uzdevumu izstrādei. Turklāt to izmanto arī, lai izveidotu straumēšanas lietojumprogrammas, kas darbojas mikropakešu koncepcijā, apstrādājot un nosūtot datus nelielās porcijās (Spark Structured Streaming). Un tradicionāli tā ir bijusi daļa no kopējās Hadoop steka, izmantojot YARN (vai dažos gadījumos Apache Mesos) kā resursu pārvaldnieku. Līdz 2020. gadam tā izmantošana tradicionālajā formā ir apšaubāma lielākajai daļai uzņēmumu, jo trūkst pienācīgas Hadoop izplatīšanas — HDP un CDH attīstība ir apstājusies, CDH nav labi attīstīts un tam ir augstas izmaksas, un pārējiem Hadoop piegādātājiem ir vai nu beidza pastāvēt, vai arī tiem ir blāva nākotne. Tāpēc Apache Spark palaišana, izmantojot Kubernetes, rada arvien lielāku interesi sabiedrībā un lielos uzņēmumos - kļūstot par standartu konteineru orķestrēšanā un resursu pārvaldībā privātajos un publiskajos mākoņos, tas atrisina problēmu ar neērto resursu plānošanu Spark uzdevumiem YARN un nodrošina stabili attīstoša platforma ar daudzām komerciālām un atvērtām izplatībām visu izmēru un joslu uzņēmumiem. Turklāt, ņemot vērā popularitāti, vairums jau ir paspējuši iegādāties pāris savas instalācijas un ir palielinājuši savas zināšanas tās lietošanā, kas vienkāršo pārvietošanos.

Sākot ar versiju 2.3.0, Apache Spark ieguva oficiālu atbalstu uzdevumu izpildei Kubernetes klasterī, un šodien mēs runāsim par šīs pieejas pašreizējo briedumu, dažādām tās izmantošanas iespējām un kļūmēm, ar kurām saskarsies ieviešanas laikā.

Vispirms apskatīsim uzdevumu un lietojumprogrammu izstrādes procesu, pamatojoties uz Apache Spark, un izcelsim tipiskus gadījumus, kad jums ir jāpalaiž uzdevums Kubernetes klasterī. Sagatavojot šo ziņu, OpenShift tiek izmantots kā izplatīšana, un tiks dotas komandas, kas attiecas uz tā komandrindas utilītu (oc). Citiem Kubernetes izplatījumiem var izmantot atbilstošās komandas no standarta Kubernetes komandrindas utilīta (kubectl) vai to analogiem (piemēram, oc adm politikai).

Pirmais lietošanas gadījums – spark-submit

Uzdevumu un lietojumprogrammu izstrādes laikā izstrādātājam ir jāpalaiž uzdevumi, lai atkļūdotu datu transformāciju. Teorētiski šiem mērķiem var izmantot stubus, taču šajā uzdevumu klasē ātrāka un labāka ir izrādījusies izstrāde ar reālu (kaut arī testa) gala sistēmu eksemplāru piedalīšanos. Gadījumā, ja mēs atkļūdojam reālos gala sistēmu gadījumos, ir iespējami divi scenāriji:

• izstrādātājs palaiž Spark uzdevumu lokāli savrupajā režīmā;

  

• izstrādātājs testa cilpā izpilda Spark uzdevumu Kubernetes klasterī.

  

Pirmajai iespējai ir tiesības pastāvēt, taču tai ir vairāki trūkumi:

• Katram izstrādātājam ir jānodrošina piekļuve no darba vietas visiem viņam nepieciešamajiem gala sistēmu gadījumiem;
• darba mašīnai ir nepieciešams pietiekams resursu apjoms, lai izpildītu izstrādājamo uzdevumu.

Otrajai iespējai nav šo trūkumu, jo Kubernetes klastera izmantošana ļauj piešķirt nepieciešamo resursu kopu palaišanas uzdevumiem un nodrošināt tai nepieciešamo piekļuvi gala sistēmas gadījumiem, elastīgi nodrošinot piekļuvi tai, izmantojot Kubernetes lomu modeli. visi izstrādes komandas locekļi. Izcelsim to kā pirmo lietošanas gadījumu — Spark uzdevumu palaišana no vietējā izstrādātāja mašīnas Kubernetes klasterī testa ķēdē.

Parunāsim vairāk par Spark iestatīšanas procesu vietējai darbībai. Lai sāktu lietot Spark, tas jāinstalē:

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

Savācam nepieciešamās paketes darbam ar Kubernetes:

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

Pilna būvēšana aizņem daudz laika, un, lai izveidotu Docker attēlus un palaistu tos Kubernetes klasterī, jums patiešām ir nepieciešami tikai jar faili no direktorija “assembly/”, lai jūs varētu izveidot tikai šo apakšprojektu:

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

Lai palaistu Spark darbus vietnē Kubernetes, jums ir jāizveido Docker attēls, ko izmantot kā pamata attēlu. Šeit ir 2 iespējamās pieejas:

• Ģenerētajā Docker attēlā ir iekļauts izpildāmais Spark uzdevuma kods;
• Izveidotajā attēlā ir iekļauts tikai Spark un nepieciešamās atkarības, izpildāmais kods tiek mitināts attālināti (piemēram, HDFS).

Vispirms izveidosim Docker attēlu, kurā ir Spark uzdevuma testa piemērs. Lai izveidotu Docker attēlus, Spark ir utilīta ar nosaukumu "docker-image-tool". Izpētīsim palīdzību par to:

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

Ar tās palīdzību jūs varat izveidot Docker attēlus un augšupielādēt tos attālos reģistros, taču pēc noklusējuma tam ir vairāki trūkumi:

• bez kļūmēm izveido 3 Docker attēlus vienlaikus - Spark, PySpark un R;
• neļauj norādīt attēla nosaukumu.

Tāpēc mēs izmantosim šīs utilītas modificēto versiju, kas norādīta tālāk:

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

Ar tā palīdzību mēs apkopojam pamata Spark attēlu, kurā ir testa uzdevums Pi aprēķināšanai, izmantojot Spark (šeit {docker-registry-url} ir jūsu Docker attēlu reģistra URL, {repo} ir repozitorija nosaukums reģistrā, kas atbilst projektam OpenShift , {image-name} — attēla nosaukums (ja tiek izmantota trīs līmeņu attēlu atdalīšana, piemēram, kā integrētajā Red Hat OpenShift attēlu reģistrā), {tag} — šī atzīme attēla versija):

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

Piesakieties OKD klasterī, izmantojot konsoles utilītu (šeit {OKD-API-URL} ir OKD klastera API URL):

oc login {OKD-API-URL}

Iegūsim pašreizējā lietotāja pilnvaru autorizācijai Docker reģistrā:

oc whoami -t

Piesakieties OKD klastera iekšējā Docker reģistrā (kā paroli mēs izmantojam marķieri, kas iegūta, izmantojot iepriekšējo komandu):

docker login {docker-registry-url}

Augšupielādēsim salikto Docker attēlu Docker reģistra OKD:

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

Pārbaudīsim, vai samontētais attēls ir pieejams OKD. Lai to izdarītu, pārlūkprogrammā atveriet URL ar atbilstošā projekta attēlu sarakstu (šeit {project} ir projekta nosaukums OpenShift klasterī, {OKD-WEBUI-URL} ir OpenShift Web konsoles URL. ) - https://{OKD-WEBUI-URL}/console /project/{project}/browse/images/{image-name}.

Lai palaistu uzdevumus, ir jāizveido pakalpojuma konts ar privilēģijām palaist pods kā root (šo punktu apspriedīsim vēlāk):

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

Palaidīsim komandu spark-submit, lai publicētu Spark uzdevumu OKD klasterī, norādot izveidoto pakalpojuma kontu un Docker attēlu:

 /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

Здесь:

—nosaukums — uzdevuma nosaukums, kas piedalīsies Kubernetes pākstu nosaukuma veidošanā;

—class — izpildāmā faila klase, kas tiek izsaukta, kad tiek palaists uzdevums;

—conf — Spark konfigurācijas parametri;

spark.executor.instances — palaižamo Spark izpildītāju skaits;

spark.kubernetes.authenticate.driver.serviceAccountName — Kubernetes pakalpojuma konta nosaukums, kas tiek izmantots, palaižot apvidus (lai definētu drošības kontekstu un iespējas, mijiedarbojoties ar Kubernetes API);

spark.kubernetes.namespace — Kubernetes nosaukumtelpa, kurā tiks palaisti draiveru un izpildītāju podi;

spark.submit.deployMode — Spark palaišanas metode (standarta spark-submit tiek izmantots “klasteris”, Spark Operator un jaunākām Spark versijām “klients”);

spark.kubernetes.container.image — Docker attēls, ko izmanto, lai palaistu pākstis;

spark.master — Kubernetes API URL (ir norādīts ārējais, tāpēc piekļuve notiek no vietējās mašīnas);

local:// ir ceļš uz Spark izpildāmo failu Docker attēlā.

Mēs ejam uz atbilstošo OKD projektu un pētām izveidotos podi - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods.

Lai vienkāršotu izstrādes procesu, var izmantot citu opciju, kurā tiek izveidots kopīgs Spark bāzes attēls, kuru izmanto visi uzdevumi, lai palaistu, un izpildāmo failu momentuzņēmumi tiek publicēti ārējā krātuvē (piemēram, Hadoop) un norādīti zvanot. spark-iesniegt kā saiti. Šādā gadījumā varat palaist dažādas Spark uzdevumu versijas, nepārbūvējot Docker attēlus, izmantojot, piemēram, WebHDFS, lai publicētu attēlus. Mēs nosūtām pieprasījumu izveidot failu (šeit {host} ir WebHDFS pakalpojuma resursdators, {port} ir WebHDFS pakalpojuma ports, {path-to-file-on-hdfs} ir vēlamais ceļš uz failu uz HDFS):

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

Jūs saņemsit šādu atbildi (šeit {location} ir URL, kas jāizmanto faila lejupielādei):

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

Ielādējiet Spark izpildāmo failu HDFS (šeit {path-to-local-file} ir ceļš uz Spark izpildāmo failu pašreizējā resursdatorā):

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

Pēc tam mēs varam veikt spark-iesniegšanu, izmantojot Spark failu, kas augšupielādēts HDFS (šeit {class-name} ir tās klases nosaukums, kas jāpalaiž, lai pabeigtu uzdevumu):

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

Jāņem vērā, ka, lai piekļūtu HDFS un nodrošinātu uzdevuma darbību, iespējams, būs jāmaina Dockerfile un enterpoint.sh skripts - Dockerfile jāpievieno direktīva, lai kopētu atkarīgās bibliotēkas direktorijā /opt/spark/jars un iekļaut HDFS konfigurācijas failu ievades punktā SPARK_CLASSPATH. sh.

Otrais lietošanas gadījums - Apache Livy

Turklāt, kad uzdevums ir izstrādāts un rezultāts ir jāpārbauda, ​​rodas jautājums par tā palaišanu kā daļu no CI/CD procesa un izsekot tā izpildes statusam. Protams, varat to palaist, izmantojot lokālo spark-submit izsaukumu, taču tas sarežģī CI/CD infrastruktūru, jo ir jāinstalē un jākonfigurē Spark CI servera aģentos/skrējējiem un jāiestata piekļuve Kubernetes API. Šajā gadījumā mērķa ieviešana ir izvēlējusies izmantot Apache Livy kā REST API, lai palaistu Spark uzdevumus, kas mitināti Kubernetes klasterī. Ar tās palīdzību jūs varat palaist Spark uzdevumus Kubernetes klasterī, izmantojot parastos cURL pieprasījumus, kas ir viegli ieviešami, pamatojoties uz jebkuru CI risinājumu, un tā ievietošana Kubernetes klasterī atrisina autentifikācijas problēmu, mijiedarbojoties ar Kubernetes API.

Izcelsim to kā otro lietošanas gadījumu — Spark uzdevumu izpilde kā daļa no CI/CD procesa Kubernetes klasterī testa cilpā.

Nedaudz par Apache Livy - tas darbojas kā HTTP serveris, kas nodrošina tīmekļa saskarni un RESTful API, kas ļauj attālināti palaist spark-submit, nododot nepieciešamos parametrus. Tradicionāli tas tiek piegādāts kā daļa no HDP izplatīšanas, taču to var izvietot arī OKD vai jebkurā citā Kubernetes instalācijā, izmantojot atbilstošo manifestu un Docker attēlu kopu, piemēram, šo - github.com/ttauveron/k8s-big-data-experiments/tree/master/livy-spark-2.3. Mūsu gadījumā tika izveidots līdzīgs Docker attēls, tostarp Spark versija 2.4.5 no šāda Dockerfile:

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

Ģenerēto attēlu var izveidot un augšupielādēt esošajā Docker repozitorijā, piemēram, iekšējā OKD repozitorijā. Lai to izvietotu, izmantojiet šo manifestu ({registry-url} — Docker attēlu reģistra URL, {image-name} — Docker attēla nosaukums, {tag} — Docker attēla tags, {livy-url} — vēlamais URL, kur serveris būs pieejams Livy; manifests “Maršruts” tiek izmantots, ja Red Hat OpenShift tiek izmantots kā Kubernetes izplatīšana, pretējā gadījumā tiek izmantots atbilstošais NodePort tipa Ingress vai pakalpojuma manifests):

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

Pēc tā lietošanas un veiksmīgas podziņas palaišanas Livy grafiskais interfeiss ir pieejams saitē: http://{livy-url}/ui. Izmantojot Livy, mēs varam publicēt savu Spark uzdevumu, izmantojot REST pieprasījumu no, piemēram, Pastnieka. Tālāk ir parādīts kolekcijas ar pieprasījumiem piemērs (konfigurācijas argumentus ar mainīgajiem, kas nepieciešami palaistā uzdevuma darbībai, var nodot “args” masīvā):

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

Izpildīsim pirmo pieprasījumu no kolekcijas, ejam uz OKD saskarni un pārbaudīsim, vai uzdevums ir veiksmīgi palaists - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods. Tajā pašā laikā Livy saskarnē (http://{livy-url}/ui) parādīsies sesija, kurā, izmantojot Livy API vai grafisko interfeisu, varat izsekot uzdevuma gaitai un izpētīt sesiju. baļķi.

Tagad parādīsim, kā Līvija strādā. Lai to izdarītu, izpētīsim Livy konteinera žurnālus podā ar Livy serveri — https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods/{livy-pod-name }?tab=logs. No tiem mēs varam redzēt, ka, izsaucot Livy REST API konteinerā ar nosaukumu “livy”, tiek izpildīts spark-submit, līdzīgs tam, ko izmantojām iepriekš (šeit {livy-pod-name} ir izveidotā pod nosaukums ar Livy serveri). Kolekcijā ir iekļauts arī otrs vaicājums, kas ļauj izpildīt uzdevumus, kas attālināti mitina Spark izpildāmo failu, izmantojot Livy serveri.

Trešais lietošanas gadījums - Spark Operator

Tagad, kad uzdevums ir pārbaudīts, rodas jautājums par tā regulāru izpildi. Vietējais veids, kā regulāri palaist uzdevumus Kubernetes klasterī, ir entītija CronJob, un jūs to varat izmantot, taču šobrīd operatoru izmantošana lietojumprogrammu pārvaldībai Kubernetes ir ļoti populāra, un Spark ir diezgan nobriedis operators, kas arī ir izmanto uzņēmuma līmeņa risinājumos (piemēram, Lightbend FastData Platform). Mēs iesakām to izmantot — pašreizējai stabilajai Spark versijai (2.4.5) ir diezgan ierobežotas konfigurācijas iespējas Spark uzdevumu izpildei Kubernetes, savukārt nākamā lielākā versija (3.0.0) deklarē pilnīgu Kubernetes atbalstu, taču tās izlaišanas datums joprojām nav zināms. . Spark Operator kompensē šo trūkumu, pievienojot svarīgas konfigurācijas opcijas (piemēram, uzstādot ConfigMap ar Hadoop piekļuves konfigurāciju Spark podiem) un iespēju palaist regulāri ieplānotu uzdevumu.

Izcelsim to kā trešo lietošanas gadījumu — regulāra Spark uzdevumu izpilde Kubernetes klasterī ražošanas cikla ietvaros.

Spark Operator ir atvērtā pirmkoda un izstrādāts Google Cloud Platform ietvaros. github.com/GoogleCloudPlatform/spark-on-k8s-operator. Tās uzstādīšanu var veikt 3 veidos:

1. Kā daļa no Lightbend FastData Platform/Cloudflow instalācijas;
2. Izmantojot stūri:

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

3. Izmantojiet manifestus no oficiālā repozitorija (https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/tree/master/manifest). Ir vērts atzīmēt sekojošo - Cloudflow ietver operatoru ar API versiju v1beta1. Ja tiek izmantota šāda veida instalēšana, Spark lietojumprogrammu manifestu aprakstiem ir jābūt balstītiem uz Git tagu paraugiem ar atbilstošu API versiju, piemēram, "v1beta1-0.9.0-2.4.0". Operatora versiju var atrast CRD aprakstā, kas iekļauts operatora vārdnīcā “versijas”:

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

Ja operators ir pareizi instalēts, attiecīgajā projektā parādīsies aktīvs pods ar Spark operatoru (piemēram, cloudflow-fdp-sparkoperator Cloudflow instalācijas Cloudflow telpā) un tiks parādīts atbilstošs Kubernetes resursa veids ar nosaukumu “sparkapplications”. . Varat izpētīt pieejamās Spark lietojumprogrammas, izmantojot šādu komandu:

oc get sparkapplications -n {project}

Lai izpildītu uzdevumus, izmantojot Spark Operator, ir jāveic 3 darbības:

• izveidot Docker attēlu, kas ietver visas nepieciešamās bibliotēkas, kā arī konfigurācijas un izpildāmos failus. Mērķa attēlā šis ir attēls, kas izveidots CI/CD stadijā un pārbaudīts testa klasterī;
• publicēt Docker attēlu reģistrā, kas pieejams no Kubernetes klastera;
• ģenerējiet manifestu ar "SparkApplication" tipu un palaižamā uzdevuma aprakstu. Manifestu piemēri ir pieejami oficiālajā repozitorijā (piem. github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/v1beta1-0.9.0-2.4.0/examples/spark-pi.yaml). Ir svarīgi atzīmēt manifestu:
  1. vārdnīcā “apiVersion” jānorāda operatora versijai atbilstošā API versija;
  2. vārdnīcā “metadata.namespace” jānorāda nosaukumtelpa, kurā tiks palaists lietojumprogramma;
  3. vārdnīcā “spec.image” ir jāietver izveidotā Docker attēla adrese pieejamā reģistrā;
  4. vārdnīcā “spec.mainClass” ir jābūt Spark uzdevumu klasei, kas jāpalaiž, kad process sākas;
  5. vārdnīcā “spec.mainApplicationFile” ir jāietver ceļš uz izpildāmo jar failu;
  6. vārdnīcā “spec.sparkVersion” jānorāda izmantotā Spark versija;
  7. vārdnīcā “spec.driver.serviceAccount” ir jānorāda pakalpojuma konts attiecīgajā Kubernetes nosaukumvietā, kas tiks izmantots lietojumprogrammas palaišanai;
  8. vārdnīcā “spec.izpildītājs” jānorāda pieteikumam piešķirto resursu skaits;
  9. vārdnīcā "spec.volumeMounts" ir jānorāda lokālais direktorijs, kurā tiks izveidoti lokālie Spark uzdevumu faili.

Manifesta ģenerēšanas piemērs (šeit {spark-service-account} ir pakalpojuma konts Kubernetes klasterī Spark uzdevumu izpildei):

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"

Šajā manifestā ir norādīts pakalpojuma konts, kuram pirms manifesta publicēšanas ir jāizveido nepieciešamie lomu saistījumi, kas nodrošina nepieciešamās piekļuves tiesības Spark lietojumprogrammai mijiedarbībai ar Kubernetes API (ja nepieciešams). Mūsu gadījumā lietojumprogrammai ir nepieciešamas tiesības, lai izveidotu Pods. Izveidosim nepieciešamo lomu saiti:

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

Ir arī vērts atzīmēt, ka šajā manifesta specifikācijā var būt ietverts parametrs "hadoopConfigMap", kas ļauj norādīt ConfigMap ar Hadoop konfigurāciju, vispirms neievietojot attiecīgo failu Docker attēlā. Tas ir piemērots arī regulārai uzdevumu izpildei - izmantojot parametru “grafiks”, var norādīt konkrētā uzdevuma izpildes grafiku.

Pēc tam mēs saglabājam manifestu failā spark-pi.yaml un lietojam to mūsu Kubernetes klasterī:

oc apply -f spark-pi.yaml

Tas izveidos “sparkapplications” tipa objektu:

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

Šajā gadījumā tiks izveidots pods ar lietojumprogrammu, kuras statuss tiks parādīts izveidotajās “sparkaplikācijās”. To var apskatīt ar šādu komandu:

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

Pēc uzdevuma pabeigšanas POD pāries uz statusu “Pabeigts”, kas tiks atjaunināts arī sadaļā “Sparkapplications”. Lietojumprogrammu žurnālus var skatīt pārlūkprogrammā vai izmantojot šādu komandu (šeit {sparkapplications-pod-name} ir izpildāmā uzdevuma apgabala nosaukums):

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

Spark uzdevumus var pārvaldīt arī, izmantojot specializēto sparkctl utilītu. Lai to instalētu, klonējiet repozitoriju ar tā avota kodu, instalējiet Go un izveidojiet šo utilītu:

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

Apskatīsim esošo Spark uzdevumu sarakstu:

sparkctl list -n {project}

Izveidosim Spark uzdevuma aprakstu:

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"

Izpildīsim aprakstīto uzdevumu, izmantojot sparkctl:

sparkctl create spark-app.yaml -n {project}

Apskatīsim esošo Spark uzdevumu sarakstu:

sparkctl list -n {project}

Apskatīsim palaistā Spark uzdevuma notikumu sarakstu:

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

Apskatīsim palaistā Spark uzdevuma statusu:

sparkctl status spark-pi -n {project}

Noslēgumā es vēlos apsvērt atklātos trūkumus, izmantojot pašreizējo stabilo Spark versiju (2.4.5) Kubernetes:

1. Pirmais un, iespējams, galvenais trūkums ir datu lokācijas trūkums. Neskatoties uz visiem YARN trūkumiem, tā izmantošanai bija arī priekšrocības, piemēram, koda piegādes princips datiem (nevis datiem kodā). Pateicoties tam, Spark uzdevumi tika izpildīti mezglos, kuros atradās aprēķinos iesaistītie dati, un ievērojami samazinājās laiks, kas bija nepieciešams datu piegādei tīklā. Lietojot Kubernetes, mēs saskaramies ar nepieciešamību pārvietot ar uzdevumu saistītos datus tīklā. Ja tie ir pietiekami lieli, uzdevumu izpildes laiks var ievērojami palielināties, kā arī nepieciešams diezgan liels diska vietas apjoms, kas tiek atvēlēts Spark uzdevumu gadījumiem to pagaidu glabāšanai. Šo trūkumu var mazināt, izmantojot specializētu programmatūru, kas nodrošina datu atrašanās vietu Kubernetes (piemēram, Alluxio), taču patiesībā tas nozīmē nepieciešamību Kubernetes klastera mezglos saglabāt pilnīgu datu kopiju.
2. Otrs svarīgais trūkums ir drošība. Pēc noklusējuma ir atspējoti ar drošību saistītie līdzekļi saistībā ar Spark uzdevumu izpildi, Kerberos lietošana nav ietverta oficiālajā dokumentācijā (lai gan atbilstošās opcijas tika ieviestas versijā 3.0.0, kas prasīs papildu darbu), un drošības dokumentācija izmantojot Spark (https://spark.apache.org/docs/2.4.5/security.html), tikai YARN, Mesos un Standalone Cluster tiek parādīti kā galvenie veikali. Tajā pašā laikā nevar tieši norādīt lietotāju, kuram tiek palaisti Spark uzdevumi - mēs norādām tikai pakalpojuma kontu, kurā tas darbosies, un lietotājs tiek atlasīts, pamatojoties uz konfigurētajām drošības politikām. Šajā sakarā tiek izmantots vai nu root lietotājs, kas nav drošs produktīvā vidē, vai arī lietotājs ar nejaušu UID, kas ir neērti, sadalot piekļuves tiesības datiem (to var atrisināt, izveidojot PodSecurityPolicies un saistot tās ar atbilstošos pakalpojumu kontos). Pašlaik risinājums ir vai nu ievietot visus nepieciešamos failus tieši Docker attēlā, vai modificēt Spark palaišanas skriptu, lai izmantotu jūsu organizācijā pieņemto noslēpumu glabāšanas un izguves mehānismu.
3. Spark darbu izpilde, izmantojot Kubernetes, oficiāli joprojām ir eksperimentālā režīmā, un nākotnē var būt būtiskas izmaiņas izmantotajos artefaktos (konfigurācijas faili, Docker bāzes attēli un palaišanas skripti). Un patiešām, sagatavojot materiālu, tika pārbaudītas versijas 2.3.0 un 2.4.5, uzvedība bija ievērojami atšķirīga.

Gaidīsim atjauninājumus - nesen tika izlaista jauna Spark versija (3.0.0), kas ienesa būtiskas izmaiņas Spark darbā uz Kubernetes, taču saglabāja šī resursa pārvaldnieka atbalsta eksperimentālo statusu. Iespējams, ka nākamie atjauninājumi patiešām ļaus pilnībā ieteikt atteikties no YARN un palaist Spark uzdevumus Kubernetes, nebaidoties par savas sistēmas drošību un bez nepieciešamības neatkarīgi modificēt funkcionālos komponentus.

Beigas.

Avots: www.habr.com