ਕੁਬਰਨੇਟਸ 'ਤੇ ਅਪਾਚੇ ਸਪਾਰਕ ਚੱਲ ਰਿਹਾ ਹੈ

ਪਿਆਰੇ ਪਾਠਕ, ਸ਼ੁਭ ਦੁਪਹਿਰ। ਅੱਜ ਅਸੀਂ ਅਪਾਚੇ ਸਪਾਰਕ ਅਤੇ ਇਸਦੇ ਵਿਕਾਸ ਦੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਬਾਰੇ ਥੋੜੀ ਗੱਲ ਕਰਾਂਗੇ।

ਵੱਡੇ ਡੇਟਾ ਦੇ ਆਧੁਨਿਕ ਸੰਸਾਰ ਵਿੱਚ, ਅਪਾਚੇ ਸਪਾਰਕ ਬੈਚ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਕਾਰਜਾਂ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਅਸਲ ਮਿਆਰ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸਦੀ ਵਰਤੋਂ ਸਟ੍ਰੀਮਿੰਗ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਬਣਾਉਣ ਲਈ ਵੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੋ ਮਾਈਕ੍ਰੋ ਬੈਚ ਸੰਕਲਪ, ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਸ਼ਿਪਿੰਗ ਡੇਟਾ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ (ਸਪਾਰਕ ਸਟ੍ਰਕਚਰਡ ਸਟ੍ਰੀਮਿੰਗ) ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ। ਅਤੇ ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ ਇਹ ਸਰੋਤ ਮੈਨੇਜਰ ਦੇ ਤੌਰ 'ਤੇ YARN (ਜਾਂ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ Apache Mesos) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਮੁੱਚੇ Hadoop ਸਟੈਕ ਦਾ ਹਿੱਸਾ ਰਿਹਾ ਹੈ। 2020 ਤੱਕ, ਇਸਦੇ ਰਵਾਇਤੀ ਰੂਪ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਵਿਨੀਤ ਹੈਡੂਪ ਵੰਡਾਂ ਦੀ ਘਾਟ ਕਾਰਨ ਜ਼ਿਆਦਾਤਰ ਕੰਪਨੀਆਂ ਲਈ ਪ੍ਰਸ਼ਨ ਵਿੱਚ ਹੈ - ਐਚਡੀਪੀ ਅਤੇ ਸੀਡੀਐਚ ਦਾ ਵਿਕਾਸ ਰੁਕ ਗਿਆ ਹੈ, ਸੀਡੀਐਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਿਕਸਤ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸਦੀ ਉੱਚ ਕੀਮਤ ਹੈ, ਅਤੇ ਬਾਕੀ ਹੈਡੂਪ ਸਪਲਾਇਰ ਹਨ। ਜਾਂ ਤਾਂ ਹੋਂਦ ਖਤਮ ਹੋ ਗਈ ਹੈ ਜਾਂ ਇੱਕ ਮੱਧਮ ਭਵਿੱਖ ਹੈ। ਇਸ ਲਈ, ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਅਪਾਚੇ ਸਪਾਰਕ ਦੀ ਸ਼ੁਰੂਆਤ ਕਮਿਊਨਿਟੀ ਅਤੇ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਵਿੱਚ ਵੱਧਦੀ ਦਿਲਚਸਪੀ ਹੈ - ਨਿੱਜੀ ਅਤੇ ਜਨਤਕ ਕਲਾਉਡਾਂ ਵਿੱਚ ਕੰਟੇਨਰ ਆਰਕੈਸਟੇਸ਼ਨ ਅਤੇ ਸਰੋਤ ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਇੱਕ ਮਿਆਰ ਬਣਨਾ, ਇਹ 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

ਕੁਬਰਨੇਟਸ 'ਤੇ ਸਪਾਰਕ ਨੌਕਰੀਆਂ ਨੂੰ ਚਲਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਬੇਸ ਇਮੇਜ ਵਜੋਂ ਵਰਤਣ ਲਈ ਇੱਕ ਡੌਕਰ ਚਿੱਤਰ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਇੱਥੇ 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}

ਆਓ ਇਕੱਠੇ ਕੀਤੇ ਡੌਕਰ ਚਿੱਤਰ ਨੂੰ ਡੌਕਰ ਰਜਿਸਟਰੀ ਓਕੇਡੀ ਵਿੱਚ ਅਪਲੋਡ ਕਰੀਏ:

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

ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਲਈ, ਇੱਕ ਹੋਰ ਵਿਕਲਪ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਪਾਰਕ ਦਾ ਇੱਕ ਸਾਂਝਾ ਅਧਾਰ ਚਿੱਤਰ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਚਲਾਉਣ ਲਈ ਸਾਰੇ ਕਾਰਜਾਂ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲਾਂ ਦੇ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਬਾਹਰੀ ਸਟੋਰੇਜ (ਉਦਾਹਰਨ ਲਈ, ਹੈਡੂਪ) ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਾਲ ਕਰਨ ਵੇਲੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਪਾਰਕ-ਇੱਕ ਲਿੰਕ ਦੇ ਰੂਪ ਵਿੱਚ ਜਮ੍ਹਾਂ ਕਰੋ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਸੀਂ ਚਿੱਤਰਾਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ, ਉਦਾਹਰਨ ਲਈ, 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 ਵਜੋਂ ਅਪਾਚੇ ਲਿਵੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਚੋਣ ਕੀਤੀ ਹੈ। ਇਸਦੀ ਮਦਦ ਨਾਲ, ਤੁਸੀਂ ਨਿਯਮਤ cURL ਬੇਨਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ 'ਤੇ ਸਪਾਰਕ ਟਾਸਕ ਚਲਾ ਸਕਦੇ ਹੋ, ਜੋ ਕਿ ਕਿਸੇ ਵੀ CI ਹੱਲ ਦੇ ਅਧਾਰ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ Kubernetes ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਇਸਦਾ ਪਲੇਸਮੈਂਟ ਕੁਬਰਨੇਟਸ API ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦੇ ਸਮੇਂ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਮੁੱਦੇ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ।

ਚਲੋ ਇਸਨੂੰ ਦੂਜੇ ਵਰਤੋਂ ਦੇ ਕੇਸ ਵਜੋਂ ਉਜਾਗਰ ਕਰੀਏ - ਇੱਕ ਟੈਸਟ ਲੂਪ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ 'ਤੇ CI/CD ਪ੍ਰਕਿਰਿਆ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸਪਾਰਕ ਟਾਸਕਾਂ ਨੂੰ ਚਲਾਉਣਾ।

Apache Livy ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ - ਇਹ ਇੱਕ HTTP ਸਰਵਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਵੈੱਬ ਇੰਟਰਫੇਸ ਅਤੇ ਇੱਕ RESTful API ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੇ ਮਾਪਦੰਡਾਂ ਨੂੰ ਪਾਸ ਕਰਕੇ ਰਿਮੋਟਲੀ ਸਪਾਰਕ-ਸਬਮਿਟ ਨੂੰ ਲਾਂਚ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ ਇਸ ਨੂੰ ਇੱਕ 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 ਰਿਪੋਜ਼ਟਰੀ। ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੇ ਮੈਨੀਫੈਸਟ ਦੀ ਵਰਤੋਂ ਕਰੋ ({ਰਜਿਸਟਰੀ-url} - ਡੌਕਰ ਚਿੱਤਰ ਰਜਿਸਟਰੀ ਦਾ URL, {image-name} - ਡੌਕਰ ਚਿੱਤਰ ਦਾ ਨਾਮ, {tag} - ਡੌਕਰ ਚਿੱਤਰ ਟੈਗ, {livy-url} - ਲੋੜੀਂਦਾ URL ਜਿੱਥੇ ਸਰਵਰ ਪਹੁੰਚਯੋਗ ਲਿਵੀ ਹੋਵੇਗਾ; “ਰੂਟ” ਮੈਨੀਫੈਸਟ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੇਕਰ 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) ਵਿੱਚ ਇੱਕ ਸੈਸ਼ਨ ਦਿਖਾਈ ਦੇਵੇਗਾ, ਜਿਸ ਵਿੱਚ, Livy API ਜਾਂ ਗ੍ਰਾਫਿਕਲ ਇੰਟਰਫੇਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਤੁਸੀਂ ਕਾਰਜ ਦੀ ਪ੍ਰਗਤੀ ਨੂੰ ਟਰੈਕ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸੈਸ਼ਨ ਦਾ ਅਧਿਐਨ ਕਰ ਸਕਦੇ ਹੋ। ਲੌਗ

ਆਓ ਹੁਣ ਦਿਖਾਉਂਦੇ ਹਾਂ ਕਿ ਲਿਵੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਆਓ ਲਿਵੀ ਸਰਵਰ ਨਾਲ ਪੌਡ ਦੇ ਅੰਦਰ ਲਿਵੀ ਕੰਟੇਨਰ ਦੇ ਲੌਗਸ ਦੀ ਜਾਂਚ ਕਰੀਏ - https://{OKD-WEBUI-URL}/console/project/{project}/browse/pods/{livy-pod-name }?tab=logs. ਉਹਨਾਂ ਤੋਂ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ ਕਿ ਜਦੋਂ "livy" ਨਾਮ ਦੇ ਕੰਟੇਨਰ ਵਿੱਚ Livy REST API ਨੂੰ ਕਾਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਪਾਰਕ-ਸਬਮਿਟ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਉੱਪਰ ਵਰਤਿਆ ਹੈ (ਇੱਥੇ {livy-pod-name} ਬਣਾਏ ਗਏ ਪੌਡ ਦਾ ਨਾਮ ਹੈ। ਲਿਵੀ ਸਰਵਰ ਨਾਲ)। ਸੰਗ੍ਰਹਿ ਇੱਕ ਦੂਜੀ ਪੁੱਛਗਿੱਛ ਵੀ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਕਾਰਜਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ Livy ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਰਿਮੋਟਲੀ ਇੱਕ ਸਪਾਰਕ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਹੋਸਟ ਕਰਦੇ ਹਨ।

ਤੀਜਾ ਵਰਤੋਂ ਕੇਸ - ਸਪਾਰਕ ਆਪਰੇਟਰ

ਹੁਣ ਜਦੋਂ ਕੰਮ ਦੀ ਜਾਂਚ ਹੋ ਚੁੱਕੀ ਹੈ, ਇਸ ਨੂੰ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਚਲਾਉਣ ਦਾ ਸਵਾਲ ਉੱਠਦਾ ਹੈ। ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਕਾਰਜਾਂ ਨੂੰ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਚਲਾਉਣ ਦਾ ਮੂਲ ਤਰੀਕਾ ਕ੍ਰੋਨਜੌਬ ਇਕਾਈ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਇਸ ਸਮੇਂ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਆਪਰੇਟਰਾਂ ਦੀ ਵਰਤੋਂ ਬਹੁਤ ਮਸ਼ਹੂਰ ਹੈ ਅਤੇ ਸਪਾਰਕ ਲਈ ਇੱਕ ਕਾਫ਼ੀ ਪਰਿਪੱਕ ਓਪਰੇਟਰ ਹੈ, ਜੋ ਕਿ ਇਹ ਵੀ ਹੈ। ਐਂਟਰਪ੍ਰਾਈਜ਼-ਪੱਧਰ ਦੇ ਹੱਲਾਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, Lightbend FastData ਪਲੇਟਫਾਰਮ)। ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ - ਸਪਾਰਕ (2.4.5) ਦੇ ਮੌਜੂਦਾ ਸਥਿਰ ਸੰਸਕਰਣ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਪਾਰਕ ਕਾਰਜਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਸੀਮਤ ਸੰਰਚਨਾ ਵਿਕਲਪ ਹਨ, ਜਦੋਂ ਕਿ ਅਗਲਾ ਪ੍ਰਮੁੱਖ ਸੰਸਕਰਣ (3.0.0) ਕੁਬਰਨੇਟਸ ਲਈ ਪੂਰਾ ਸਮਰਥਨ ਘੋਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਪਰ ਇਸਦੀ ਰਿਲੀਜ਼ ਮਿਤੀ ਅਣਜਾਣ ਹੈ। . ਸਪਾਰਕ ਆਪਰੇਟਰ ਮਹੱਤਵਪੂਰਨ ਸੰਰਚਨਾ ਵਿਕਲਪਾਂ (ਉਦਾਹਰਨ ਲਈ, ਸਪਾਰਕ ਪੌਡਜ਼ ਵਿੱਚ ਹੈਡੂਪ ਐਕਸੈਸ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੇ ਨਾਲ ਇੱਕ ਕੌਨਫਿਗਮੈਪ ਨੂੰ ਮਾਊਂਟ ਕਰਨਾ) ਅਤੇ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਨਿਯਤ ਕੰਮ ਨੂੰ ਚਲਾਉਣ ਦੀ ਯੋਗਤਾ ਨੂੰ ਜੋੜ ਕੇ ਇਸ ਕਮੀ ਦੀ ਭਰਪਾਈ ਕਰਦਾ ਹੈ।

ਚਲੋ ਇਸਨੂੰ ਤੀਜੇ ਵਰਤੋਂ ਦੇ ਮਾਮਲੇ ਵਜੋਂ ਉਜਾਗਰ ਕਰੀਏ - ਇੱਕ ਉਤਪਾਦਨ ਲੂਪ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ 'ਤੇ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਸਪਾਰਕ ਟਾਸਕ ਚਲਾ ਰਹੇ ਹਨ।

ਸਪਾਰਕ ਆਪਰੇਟਰ ਓਪਨ ਸੋਰਸ ਹੈ ਅਤੇ ਗੂਗਲ ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਦੇ ਅੰਦਰ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਹੈ - 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) ਤੋਂ ਮੈਨੀਫੈਸਟ ਦੀ ਵਰਤੋਂ ਕਰਨਾ। ਇਹ ਹੇਠ ਲਿਖਿਆਂ ਨੂੰ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ - Cloudflow ਵਿੱਚ API ਸੰਸਕਰਣ v1beta1 ਵਾਲਾ ਇੱਕ ਆਪਰੇਟਰ ਸ਼ਾਮਲ ਹੈ। ਜੇਕਰ ਇਸ ਕਿਸਮ ਦੀ ਸਥਾਪਨਾ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸਪਾਰਕ ਐਪਲੀਕੇਸ਼ਨ ਮੈਨੀਫੈਸਟ ਵਰਣਨ Git ਵਿੱਚ ਉਚਿਤ API ਸੰਸਕਰਣ ਦੇ ਨਾਲ ਉਦਾਹਰਨ ਟੈਗਾਂ 'ਤੇ ਅਧਾਰਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, "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 ਪੜਾਅ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਹੈ ਅਤੇ ਇੱਕ ਟੈਸਟ ਕਲੱਸਟਰ 'ਤੇ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਹੈ;
• ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਤੋਂ ਪਹੁੰਚਯੋਗ ਰਜਿਸਟਰੀ ਲਈ ਇੱਕ ਡੌਕਰ ਚਿੱਤਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ;
• "ਸਪਾਰਕਐਪਲੀਕੇਸ਼ਨ" ਕਿਸਮ ਅਤੇ ਲਾਂਚ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਕਾਰਜ ਦੇ ਵੇਰਵੇ ਨਾਲ ਇੱਕ ਮੈਨੀਫੈਸਟ ਤਿਆਰ ਕਰੋ। ਉਦਾਹਰਨ ਮੈਨੀਫੈਸਟ ਅਧਿਕਾਰਤ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਉਪਲਬਧ ਹਨ (ਉਦਾਹਰਨ ਲਈ. 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” ਡਿਕਸ਼ਨਰੀ ਨੂੰ ਸੰਬੰਧਿਤ Kubernetes ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰ ਸੇਵਾ ਖਾਤਾ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਚਲਾਉਣ ਲਈ ਵਰਤਿਆ ਜਾਵੇਗਾ;
  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 ਫਾਈਲ ਵਿੱਚ ਸੇਵ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਸਾਡੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਲਾਗੂ ਕਰਦੇ ਹਾਂ:

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}

ਸਪਾਰਕ ਕਾਰਜਾਂ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਸਪਾਰਕਟੀਐਲ ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵੀ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਲਈ, ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਇਸਦੇ ਸਰੋਤ ਕੋਡ ਨਾਲ ਕਲੋਨ ਕਰੋ, ਗੋ ਨੂੰ ਸਥਾਪਿਤ ਕਰੋ ਅਤੇ ਇਸ ਉਪਯੋਗਤਾ ਨੂੰ ਬਣਾਓ:

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 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਸਾਨੂੰ ਪੂਰੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਕਿਸੇ ਕੰਮ ਵਿੱਚ ਸ਼ਾਮਲ ਡੇਟਾ ਨੂੰ ਲਿਜਾਣ ਦੀ ਲੋੜ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਜੇਕਰ ਉਹ ਕਾਫ਼ੀ ਵੱਡੇ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਟਾਸਕ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ ਕਾਫ਼ੀ ਵੱਧ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਅਸਥਾਈ ਸਟੋਰੇਜ ਲਈ ਸਪਾਰਕ ਟਾਸਕ ਉਦਾਹਰਨਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤੀ ਡਿਸਕ ਸਪੇਸ ਦੀ ਕਾਫ਼ੀ ਵੱਡੀ ਮਾਤਰਾ ਦੀ ਵੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਨੁਕਸਾਨ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਸੌਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਕੁਬਰਨੇਟਸ (ਉਦਾਹਰਣ ਵਜੋਂ, ਅਲੂਕਸੀਓ) ਵਿੱਚ ਡਾਟਾ ਸਥਾਨਿਕਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਇਸਦਾ ਅਸਲ ਵਿੱਚ ਮਤਲਬ ਹੈ ਕਿ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੇ ਨੋਡਾਂ 'ਤੇ ਡੇਟਾ ਦੀ ਇੱਕ ਪੂਰੀ ਕਾਪੀ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
2. ਦੂਜਾ ਮਹੱਤਵਪੂਰਨ ਨੁਕਸਾਨ ਸੁਰੱਖਿਆ ਹੈ. ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ, ਸਪਾਰਕ ਟਾਸਕਾਂ ਨੂੰ ਚਲਾਉਣ ਸੰਬੰਧੀ ਸੁਰੱਖਿਆ-ਸਬੰਧਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਸਮਰੱਥ ਹਨ, ਕਰਬੇਰੋਸ ਦੀ ਵਰਤੋਂ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ (ਹਾਲਾਂਕਿ ਸੰਬੰਧਿਤ ਵਿਕਲਪਾਂ ਨੂੰ ਵਰਜਨ 3.0.0 ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸ ਲਈ ਵਾਧੂ ਕੰਮ ਦੀ ਲੋੜ ਹੋਵੇਗੀ), ਅਤੇ ਸੁਰੱਖਿਆ ਦਸਤਾਵੇਜ਼ ਸਪਾਰਕ (https://spark.apache.org/docs/2.4.5/security.html) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਿਰਫ਼ YARN, Mesos ਅਤੇ ਸਟੈਂਡਅਲੋਨ ਕਲੱਸਟਰ ਹੀ ਮੁੱਖ ਸਟੋਰਾਂ ਵਜੋਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਉਸੇ ਸਮੇਂ, ਉਪਭੋਗਤਾ ਜਿਸ ਦੇ ਅਧੀਨ ਸਪਾਰਕ ਟਾਸਕ ਲਾਂਚ ਕੀਤੇ ਗਏ ਹਨ, ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ - ਅਸੀਂ ਸਿਰਫ ਉਹ ਸੇਵਾ ਖਾਤਾ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਜਿਸ ਦੇ ਤਹਿਤ ਇਹ ਕੰਮ ਕਰੇਗਾ, ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਕੌਂਫਿਗਰ ਕੀਤੀਆਂ ਸੁਰੱਖਿਆ ਨੀਤੀਆਂ ਦੇ ਅਧਾਰ ਤੇ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਸਬੰਧ ਵਿੱਚ, ਜਾਂ ਤਾਂ ਰੂਟ ਉਪਭੋਗਤਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਉਤਪਾਦਕ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ, ਜਾਂ ਇੱਕ ਬੇਤਰਤੀਬ UID ਵਾਲਾ ਉਪਭੋਗਤਾ, ਜੋ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਅਧਿਕਾਰਾਂ ਨੂੰ ਵੰਡਣ ਵੇਲੇ ਅਸੁਵਿਧਾਜਨਕ ਹੁੰਦਾ ਹੈ (ਇਸ ਨੂੰ PodSecurityPolicies ਬਣਾ ਕੇ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਲਿੰਕ ਕਰਕੇ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਅਨੁਸਾਰੀ ਸੇਵਾ ਖਾਤੇ)। ਵਰਤਮਾਨ ਵਿੱਚ, ਹੱਲ ਇਹ ਹੈ ਕਿ ਜਾਂ ਤਾਂ ਸਾਰੀਆਂ ਲੋੜੀਂਦੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਸਿੱਧੇ ਡੌਕਰ ਚਿੱਤਰ ਵਿੱਚ ਰੱਖੋ, ਜਾਂ ਤੁਹਾਡੀ ਸੰਸਥਾ ਵਿੱਚ ਅਪਣਾਏ ਗਏ ਰਾਜ਼ਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਸਪਾਰਕ ਲਾਂਚ ਸਕ੍ਰਿਪਟ ਨੂੰ ਸੋਧੋ।
3. ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਪਾਰਕ ਨੌਕਰੀਆਂ ਨੂੰ ਚਲਾਉਣਾ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਅਜੇ ਵੀ ਪ੍ਰਯੋਗਾਤਮਕ ਮੋਡ ਵਿੱਚ ਹੈ ਅਤੇ ਭਵਿੱਖ ਵਿੱਚ ਵਰਤੀਆਂ ਗਈਆਂ ਕਲਾਕ੍ਰਿਤੀਆਂ (ਸੰਰਚਨਾ ਫਾਈਲਾਂ, ਡੌਕਰ ਬੇਸ ਚਿੱਤਰ, ਅਤੇ ਲਾਂਚ ਸਕ੍ਰਿਪਟਾਂ) ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਅਤੇ ਵਾਸਤਵ ਵਿੱਚ, ਸਮੱਗਰੀ ਨੂੰ ਤਿਆਰ ਕਰਦੇ ਸਮੇਂ, ਸੰਸਕਰਣ 2.3.0 ਅਤੇ 2.4.5 ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ ਸੀ, ਵਿਹਾਰ ਕਾਫ਼ੀ ਵੱਖਰਾ ਸੀ।

ਆਉ ਅਪਡੇਟਸ ਦੀ ਉਡੀਕ ਕਰੀਏ - ਸਪਾਰਕ (3.0.0) ਦਾ ਇੱਕ ਨਵਾਂ ਸੰਸਕਰਣ ਹਾਲ ਹੀ ਵਿੱਚ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸ ਨੇ ਕੁਬਰਨੇਟਸ ਉੱਤੇ ਸਪਾਰਕ ਦੇ ਕੰਮ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਲਿਆਂਦੀਆਂ ਹਨ, ਪਰ ਇਸ ਸਰੋਤ ਪ੍ਰਬੰਧਕ ਲਈ ਸਮਰਥਨ ਦੀ ਪ੍ਰਯੋਗਾਤਮਕ ਸਥਿਤੀ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਿਆ ਹੈ। ਸ਼ਾਇਦ ਅਗਲੇ ਅੱਪਡੇਟ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਡਰੇ ਬਿਨਾਂ ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਭਾਗਾਂ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਸੋਧਣ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਕੁਬਰਨੇਟਸ 'ਤੇ YARN ਨੂੰ ਛੱਡਣ ਅਤੇ ਸਪਾਰਕ ਕਾਰਜਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਸਿਫ਼ਾਰਸ਼ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਣਗੇ।

ਅੰਤ.

ਸਰੋਤ: www.habr.com