K8S ਮਲਟੀਕਲੱਸਟਰ ਯਾਤਰਾ

ਹੇ ਹਬਰ!

ਅਸੀਂ Exness ਪਲੇਟਫਾਰਮ ਟੀਮ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਦੇ ਹਾਂ। ਪਹਿਲਾਂ, ਸਾਡੇ ਸਾਥੀਆਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਇਸ ਬਾਰੇ ਇੱਕ ਲੇਖ ਲਿਖਿਆ ਸੀ k8s ਲਈ ਉਤਪਾਦਨ-ਤਿਆਰ ਚਿੱਤਰ. ਅੱਜ ਅਸੀਂ Kubernetes ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਦੇ ਸਾਡੇ ਅਨੁਭਵ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਤੁਹਾਨੂੰ ਇਸ ਗੱਲ ਦੀ ਬਿਹਤਰ ਸਮਝ ਲਈ ਕੁਝ ਨੰਬਰ ਪੇਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ ਕਿਸ ਬਾਰੇ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ:

• ਸਾਡੇ ਵਿਕਾਸ ਵਿਭਾਗ ਵਿੱਚ ਸਵੈ-ਨਿਰਭਰ QA, DevOps ਅਤੇ Scrum ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਾਲੀਆਂ 100 ਤੋਂ ਵੱਧ ਵੱਖ-ਵੱਖ ਟੀਮਾਂ ਸਮੇਤ 10+ ਲੋਕ ਸ਼ਾਮਲ ਹਨ। ਵਿਕਾਸ ਸਟੈਕ - Python, PHP, C++, Java ਅਤੇ Golang। 
• ਟੈਸਟ ਅਤੇ ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ ਦਾ ਆਕਾਰ ਲਗਭਗ 2000 ਕੰਟੇਨਰ ਹੈ. ਉਹ ਰੈਂਚਰ v1.6 ਨੂੰ ਆਪਣੇ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਅਤੇ VMware ਦੇ ਅਧੀਨ ਚਲਾ ਰਹੇ ਹਨ। 

ਪ੍ਰੇਰਣਾ

ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ, ਕੁਝ ਵੀ ਸਦਾ ਲਈ ਨਹੀਂ ਰਹਿੰਦਾ, ਅਤੇ ਰੈਂਚਰ ਨੇ ਬਹੁਤ ਸਮਾਂ ਪਹਿਲਾਂ ਸੰਸਕਰਣ 1.6 ਲਈ ਸਮਰਥਨ ਦੇ ਅੰਤ ਦੀ ਘੋਸ਼ਣਾ ਕੀਤੀ ਸੀ. ਹਾਂ, ਤਿੰਨ ਸਾਲਾਂ ਤੋਂ ਵੱਧ ਸਮੇਂ ਵਿੱਚ ਅਸੀਂ ਇਸ ਨੂੰ ਤਿਆਰ ਕਰਨਾ ਅਤੇ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਸਿੱਖ ਲਿਆ ਹੈ, ਪਰ ਅਕਸਰ ਸਾਨੂੰ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜੋ ਕਦੇ ਵੀ ਠੀਕ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ। ਰੈਂਚਰ 1.6 ਕੋਲ ਅਧਿਕਾਰਾਂ ਨੂੰ ਜਾਰੀ ਕਰਨ ਲਈ ਇੱਕ ਓਸੀਫਾਈਡ ਸਿਸਟਮ ਵੀ ਹੈ, ਜਿੱਥੇ ਤੁਸੀਂ ਜਾਂ ਤਾਂ ਲਗਭਗ ਸਭ ਕੁਝ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਕੁਝ ਵੀ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ।

ਹਾਲਾਂਕਿ ਮਲਕੀਅਤ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਨੇ ਡੇਟਾ ਸਟੋਰੇਜ ਅਤੇ ਇਸਦੀ ਸੁਰੱਖਿਆ 'ਤੇ ਵਧੇਰੇ ਨਿਯੰਤਰਣ ਪ੍ਰਦਾਨ ਕੀਤਾ, ਇਸਨੇ ਓਪਰੇਟਿੰਗ ਖਰਚੇ ਲਗਾਏ ਜੋ ਕੰਪਨੀ ਦੇ ਨਿਰੰਤਰ ਵਿਕਾਸ, ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਗਿਣਤੀ ਅਤੇ ਉਹਨਾਂ ਲਈ ਲੋੜਾਂ ਦੇ ਕਾਰਨ ਸਵੀਕਾਰ ਕਰਨਾ ਮੁਸ਼ਕਲ ਸਨ।

ਅਸੀਂ IaC ਮਾਪਦੰਡਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ ਅਤੇ, ਜੇ ਲੋੜ ਹੋਵੇ, ਕਿਸੇ ਵੀ ਭੂਗੋਲਿਕ ਸਥਿਤੀ ਵਿੱਚ ਅਤੇ ਵਿਕਰੇਤਾ ਲਾਕ ਤੋਂ ਬਿਨਾਂ, ਤੇਜ਼ੀ ਨਾਲ ਸਮਰੱਥਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ, ਅਤੇ ਇਸਨੂੰ ਤੁਰੰਤ ਛੱਡਣ ਦੇ ਯੋਗ ਵੀ ਹੋ ਸਕਦੇ ਸੀ।

ਪਹਿਲੇ ਕਦਮ

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

ਅੱਗੇ ਕਲੱਸਟਰ ਬਣਾਉਣ ਲਈ ਇੱਕ ਸਾਧਨ ਚੁਣਨ ਦਾ ਸਵਾਲ ਆਇਆ। ਅਸੀਂ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਹੱਲਾਂ ਦੀ ਤੁਲਨਾ ਕੀਤੀ: ਕੋਪਸ, ਕੁਬੇਸਪ੍ਰੇ, ਕੁਬੇਡਮ।

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, kubeadm ਸਾਨੂੰ ਇੱਕ ਮਾਰਗ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਜਾਪਦਾ ਸੀ, ਨਾ ਕਿ "ਸਾਈਕਲ" ਦੇ ਇੱਕ ਕਿਸਮ ਦੇ ਖੋਜੀ ਵਾਂਗ, ਅਤੇ ਕੋਪਸ ਕੋਲ ਲੋੜੀਂਦੀ ਲਚਕਤਾ ਨਹੀਂ ਸੀ।

ਅਤੇ ਜੇਤੂ ਸੀ:

ਅਸੀਂ ਆਪਣੇ ਖੁਦ ਦੇ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਅਤੇ AWS ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਸਾਡੇ ਪਿਛਲੇ ਸਰੋਤ ਪ੍ਰਬੰਧਨ ਪੈਟਰਨ ਦੇ ਸਮਾਨ ਕੁਝ ਮੁੜ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ, ਜਿੱਥੇ ਹਰ ਕਿਸੇ ਨੇ ਇੱਕੋ ਜਿਹਾ "ਕਲੱਸਟਰ" ਸਾਂਝਾ ਕੀਤਾ ਹੈ। ਅਤੇ ਹੁਣ ਸਾਡੇ ਕੋਲ 10 ਛੋਟੀਆਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦਾ ਪਹਿਲਾ ਕਲੱਸਟਰ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ AWS ਵਿੱਚ ਸਥਿਤ ਹਨ। ਅਸੀਂ ਉੱਥੇ ਟੀਮਾਂ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ, ਸਭ ਕੁਝ "ਚੰਗਾ" ਜਾਪਦਾ ਸੀ, ਅਤੇ ਕਹਾਣੀ ਖਤਮ ਹੋ ਸਕਦੀ ਸੀ, ਪਰ...

ਪਹਿਲੀ ਸਮੱਸਿਆ

ਜਵਾਬਦੇਹ ਉਹ ਹੈ ਜਿਸ 'ਤੇ kubespray ਬਣਾਇਆ ਗਿਆ ਹੈ, ਇਹ ਇੱਕ ਅਜਿਹਾ ਸਾਧਨ ਨਹੀਂ ਹੈ ਜੋ ਤੁਹਾਨੂੰ IaC ਦੀ ਪਾਲਣਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ: ਜਦੋਂ ਨੋਡਾਂ ਨੂੰ ਚਾਲੂ/ਡੀਕਮਿਸ਼ਨ ਕਰਦੇ ਹੋਏ, ਕੁਝ ਲਗਾਤਾਰ ਗਲਤ ਹੁੰਦਾ ਗਿਆ ਅਤੇ ਕਿਸੇ ਕਿਸਮ ਦੀ ਦਖਲਅੰਦਾਜ਼ੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ, ਅਤੇ ਵੱਖ-ਵੱਖ OS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਪਲੇਬੁੱਕ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਵਿਹਾਰ ਕਰਦੀ ਸੀ। . ਜਿਵੇਂ-ਜਿਵੇਂ ਕਲੱਸਟਰ ਵਿੱਚ ਟੀਮਾਂ ਅਤੇ ਨੋਡਾਂ ਦੀ ਗਿਣਤੀ ਵਧਦੀ ਗਈ, ਅਸੀਂ ਧਿਆਨ ਦੇਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕਿ ਪਲੇਬੁੱਕ ਨੂੰ ਪੂਰਾ ਹੋਣ ਵਿੱਚ ਜ਼ਿਆਦਾ ਅਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗ ਰਿਹਾ ਸੀ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡਾ ਰਿਕਾਰਡ 3,5 ਘੰਟੇ ਸੀ, ਤੁਹਾਡਾ ਕੀ ਹੈ? 🙂

ਅਤੇ ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਕੁਬੇਸਪ੍ਰੇ ਸਿਰਫ ਜਵਾਬਦੇਹ ਹੈ, ਅਤੇ ਸਭ ਕੁਝ ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ ਸਪੱਸ਼ਟ ਹੈ, ਪਰ:

ਯਾਤਰਾ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਕੰਮ ਸਿਰਫ AWS ਅਤੇ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਵਿੱਚ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਲਾਂਚ ਕਰਨਾ ਸੀ, ਪਰ ਫਿਰ, ਜਿਵੇਂ ਕਿ ਅਕਸਰ ਹੁੰਦਾ ਹੈ, ਲੋੜਾਂ ਬਦਲਦੀਆਂ ਹਨ।
 


ਇਸ ਦੀ ਰੋਸ਼ਨੀ ਵਿੱਚ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਇੱਕ ਆਰਕੈਸਟ੍ਰੇਸ਼ਨ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਸਰੋਤਾਂ ਨੂੰ ਜੋੜਨ ਦਾ ਸਾਡਾ ਪੁਰਾਣਾ ਪੈਟਰਨ ਢੁਕਵਾਂ ਨਹੀਂ ਸੀ - ਉਸ ਸਥਿਤੀ ਵਿੱਚ ਜਿੱਥੇ ਕਲੱਸਟਰ ਬਹੁਤ ਰਿਮੋਟ ਹਨ ਅਤੇ ਵੱਖ-ਵੱਖ ਪ੍ਰਦਾਤਾਵਾਂ ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। 

ਹੋਰ ਅੱਗੇ. ਜਦੋਂ ਸਾਰੀਆਂ ਟੀਮਾਂ ਇੱਕੋ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਸਥਾਪਿਤ ਨੋਡਸਿਲੈਕਟਰ ਵਾਲੀਆਂ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ ਕਿਸੇ ਹੋਰ ਟੀਮ ਦੇ "ਵਿਦੇਸ਼ੀ" ਮੇਜ਼ਬਾਨ 'ਤੇ ਉੱਡ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਉੱਥੇ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਜੇਕਰ ਦਾਗ਼ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਲਗਾਤਾਰ ਬੇਨਤੀਆਂ ਹੁੰਦੀਆਂ ਸਨ ਕਿ ਇੱਕ ਜਾਂ ਦੂਜੀ ਸੇਵਾ ਕੰਮ ਨਹੀਂ ਕਰ ਰਹੀ ਸੀ, ਮਨੁੱਖੀ ਕਾਰਕ ਦੇ ਕਾਰਨ ਸਹੀ ਢੰਗ ਨਾਲ ਵੰਡਿਆ ਨਹੀਂ ਗਿਆ। ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਲਾਗਤ ਦੀ ਗਣਨਾ ਕਰ ਰਹੀ ਸੀ, ਖਾਸ ਕਰਕੇ ਨੋਡਾਂ ਵਿੱਚ ਸੇਵਾਵਾਂ ਨੂੰ ਵੰਡਣ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ।

ਇੱਕ ਵੱਖਰੀ ਕਹਾਣੀ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਅਧਿਕਾਰਾਂ ਨੂੰ ਜਾਰੀ ਕਰਨਾ ਸੀ: ਹਰੇਕ ਟੀਮ ਕਲੱਸਟਰ ਦੇ "ਸਿਰ 'ਤੇ" ਹੋਣਾ ਚਾਹੁੰਦੀ ਸੀ ਅਤੇ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਬੰਧਿਤ ਕਰਨਾ ਚਾਹੁੰਦੀ ਸੀ, ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਢਹਿ-ਢੇਰੀ ਹੋ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਟੀਮਾਂ ਅਸਲ ਵਿੱਚ ਇੱਕ ਦੂਜੇ ਤੋਂ ਸੁਤੰਤਰ ਹੁੰਦੀਆਂ ਹਨ।

ਕਿਵੇਂ?

ਉਪਰੋਕਤ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਅਤੇ ਟੀਮਾਂ ਦੇ ਵਧੇਰੇ ਸੁਤੰਤਰ ਹੋਣ ਦੀਆਂ ਇੱਛਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਅਸੀਂ ਇੱਕ ਸਧਾਰਨ ਸਿੱਟਾ ਕੱਢਿਆ: ਇੱਕ ਟੀਮ - ਇੱਕ ਸਮੂਹ। 

ਇਸ ਲਈ ਸਾਨੂੰ ਇੱਕ ਦੂਜਾ ਮਿਲਿਆ:

ਅਤੇ ਫਿਰ ਤੀਜਾ ਸਮੂਹ: 

ਫਿਰ ਅਸੀਂ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕੀਤਾ: ਆਓ ਇਹ ਕਹੀਏ ਕਿ ਇੱਕ ਸਾਲ ਵਿੱਚ ਸਾਡੀਆਂ ਟੀਮਾਂ ਕੋਲ ਇੱਕ ਤੋਂ ਵੱਧ ਕਲੱਸਟਰ ਹੋਣਗੇ? ਵੱਖ-ਵੱਖ ਭੂਗੋਲਿਕ ਖੇਤਰਾਂ ਵਿੱਚ, ਉਦਾਹਰਨ ਲਈ, ਜਾਂ ਵੱਖ-ਵੱਖ ਪ੍ਰਦਾਤਾਵਾਂ ਦੇ ਨਿਯੰਤਰਣ ਅਧੀਨ? ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਕੁਝ ਟੈਸਟਾਂ ਲਈ ਇੱਕ ਅਸਥਾਈ ਕਲੱਸਟਰ ਨੂੰ ਜਲਦੀ ਤੈਨਾਤ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੁਣਗੇ. 

ਪੂਰਾ ਕੁਬਰਨੇਟਸ ਆ ਜਾਵੇਗਾ! ਇਹ ਕਿਸੇ ਕਿਸਮ ਦਾ ਮਲਟੀਕੁਬਰਨੇਟਸ ਹੈ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ. 

ਇਸ ਦੇ ਨਾਲ ਹੀ, ਸਾਨੂੰ ਸਾਰਿਆਂ ਨੂੰ ਇਹਨਾਂ ਸਾਰੇ ਕਲੱਸਟਰਾਂ ਨੂੰ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਬਣਾਈ ਰੱਖਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਉਹਨਾਂ ਤੱਕ ਆਸਾਨੀ ਨਾਲ ਪਹੁੰਚ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੇ ਨਾਲ-ਨਾਲ ਨਵੇਂ ਬਣਾਉਣ ਅਤੇ ਪੁਰਾਣੇ ਨੂੰ ਦਸਤੀ ਦਖਲ ਤੋਂ ਬਿਨਾਂ ਖਤਮ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕੁਬਰਨੇਟਸ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਸਾਡੀ ਯਾਤਰਾ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਕੁਝ ਸਮਾਂ ਲੰਘ ਗਿਆ ਹੈ, ਅਤੇ ਅਸੀਂ ਉਪਲਬਧ ਹੱਲਾਂ ਦੀ ਦੁਬਾਰਾ ਜਾਂਚ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਇਹ ਮਾਰਕੀਟ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ - ਰੈਂਚਰ 2.2.

ਸਾਡੀ ਖੋਜ ਦੇ ਪਹਿਲੇ ਪੜਾਅ 'ਤੇ, ਰੈਂਚਰ ਲੈਬਜ਼ ਨੇ ਪਹਿਲਾਂ ਹੀ ਸੰਸਕਰਣ 2 ਦੀ ਪਹਿਲੀ ਰੀਲੀਜ਼ ਕੀਤੀ ਸੀ, ਪਰ ਹਾਲਾਂਕਿ ਇਸ ਨੂੰ ਕੁਝ ਮਾਪਦੰਡਾਂ ਦੇ ਨਾਲ ਬਾਹਰੀ ਨਿਰਭਰਤਾ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਕੰਟੇਨਰ ਲਾਂਚ ਕਰਕੇ ਜਾਂ ਅਧਿਕਾਰਤ HELM ਚਾਰਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਉਭਾਰਿਆ ਜਾ ਸਕਦਾ ਸੀ, ਇਹ ਕੱਚਾ ਲੱਗਦਾ ਸੀ। ਸਾਡੇ ਲਈ, ਅਤੇ ਸਾਨੂੰ ਨਹੀਂ ਪਤਾ ਸੀ ਕਿ ਕੀ ਅਸੀਂ ਇਸ ਫੈਸਲੇ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹ ਵਿਕਸਤ ਕੀਤਾ ਜਾਵੇਗਾ ਜਾਂ ਜਲਦੀ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇਗਾ। UI ਵਿੱਚ ਕਲੱਸਟਰ = ਕਲਿਕਸ ਪੈਰਾਡਾਈਮ ਵੀ ਸਾਡੇ ਲਈ ਅਨੁਕੂਲ ਨਹੀਂ ਸੀ, ਅਤੇ ਅਸੀਂ RKE ਨਾਲ ਬੰਨ੍ਹਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ ਸੀ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਘੱਟ ਫੋਕਸ ਟੂਲ ਹੈ। 

ਸੰਸਕਰਣ ਰੈਂਚਰ 2.2 ਦੀ ਪਹਿਲਾਂ ਹੀ ਵਧੇਰੇ ਕਾਰਜਸ਼ੀਲ ਦਿੱਖ ਸੀ ਅਤੇ, ਪਿਛਲੀਆਂ ਦੇ ਨਾਲ, ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਦਿਲਚਸਪ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਸੀ, ਜਿਵੇਂ ਕਿ ਬਹੁਤ ਸਾਰੇ ਬਾਹਰੀ ਪ੍ਰਦਾਤਾਵਾਂ ਨਾਲ ਏਕੀਕਰਣ, ਅਧਿਕਾਰਾਂ ਦੀ ਵੰਡ ਦਾ ਇੱਕ ਬਿੰਦੂ ਅਤੇ kubeconfig ਫਾਈਲਾਂ, ਇੱਕ kubectl ਲਾਂਚ ਕਰਨਾ। UI ਵਿੱਚ ਤੁਹਾਡੇ ਅਧਿਕਾਰਾਂ ਨਾਲ ਚਿੱਤਰ, ਨੇਸਟਡ ਨੇਮਸਪੇਸ ਉਰਫ਼ ਪ੍ਰੋਜੈਕਟ। 

ਰੈਂਚਰ 2 ਦੇ ਆਲੇ-ਦੁਆਲੇ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਕਮਿਊਨਿਟੀ ਬਣਾਈ ਗਈ ਸੀ, ਅਤੇ ਇਸਨੂੰ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ HashiCorp Terraform ਨਾਮਕ ਇੱਕ ਪ੍ਰਦਾਤਾ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਜਿਸ ਨੇ ਸਾਨੂੰ ਸਭ ਕੁਝ ਇਕੱਠੇ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ।

ਕੀ ਹੋਇਆ

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਰੈਂਚਰ ਚਲਾਉਣ ਵਾਲੇ ਇੱਕ ਛੋਟੇ ਕਲੱਸਟਰ ਦੇ ਨਾਲ ਸਮਾਪਤ ਕੀਤਾ, ਜੋ ਹੋਰ ਸਾਰੇ ਕਲੱਸਟਰਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਇਸ ਨਾਲ ਜੁੜੇ ਬਹੁਤ ਸਾਰੇ ਕਲੱਸਟਰ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ldap ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਉਪਭੋਗਤਾ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਕੋਈ ਵੀ ਹੋਵੇ। ਇਹ ਕਿੱਥੇ ਸਥਿਤ ਹੈ ਅਤੇ ਇਹ ਕਿਸ ਪ੍ਰਦਾਤਾ ਦੇ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

gitlab-ci ਅਤੇ Terraform ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਇੱਕ ਸਿਸਟਮ ਬਣਾਇਆ ਗਿਆ ਸੀ ਜੋ ਤੁਹਾਨੂੰ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ ਜਾਂ ਸਾਡੇ ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਕਿਸੇ ਵੀ ਸੰਰਚਨਾ ਦਾ ਇੱਕ ਕਲੱਸਟਰ ਬਣਾਉਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਰੈਂਚਰ ਨਾਲ ਜੋੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇਹ ਸਭ IaC ਸ਼ੈਲੀ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿੱਥੇ ਹਰੇਕ ਕਲੱਸਟਰ ਨੂੰ ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਦੁਆਰਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ, ਅਤੇ ਇਸਦੀ ਸਥਿਤੀ ਨੂੰ ਸੰਸਕਰਣ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਜ਼ਿਆਦਾਤਰ ਮੋਡੀਊਲ ਬਾਹਰੀ ਰਿਪੋਜ਼ਟਰੀਆਂ ਤੋਂ ਜੁੜੇ ਹੁੰਦੇ ਹਨ ਤਾਂ ਕਿ ਜੋ ਕੁਝ ਬਚਦਾ ਹੈ ਉਹ ਵੇਰੀਏਬਲ ਨੂੰ ਪਾਸ ਕਰਨਾ ਜਾਂ ਉਦਾਹਰਣਾਂ ਲਈ ਤੁਹਾਡੀ ਕਸਟਮ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਨਾ ਹੈ, ਜੋ ਕੋਡ ਦੁਹਰਾਉਣ ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਨੂੰ ਘਟਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਬੇਸ਼ੱਕ, ਸਾਡੀ ਯਾਤਰਾ ਬਹੁਤ ਦੂਰ ਹੈ ਅਤੇ ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੇ ਦਿਲਚਸਪ ਕੰਮ ਹਨ, ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਵੀ ਕਲੱਸਟਰ ਦੇ ਲੌਗਸ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦੇ ਨਾਲ ਕੰਮ ਦਾ ਇੱਕ ਬਿੰਦੂ, ਸੇਵਾ ਜਾਲ, ਮਲਟੀਕਲੱਸਟਰ ਵਿੱਚ ਲੋਡ ਪ੍ਰਬੰਧਨ ਲਈ ਗੀਟੌਪ ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ। ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਤੁਹਾਨੂੰ ਸਾਡਾ ਅਨੁਭਵ ਦਿਲਚਸਪ ਲੱਗੇਗਾ! 

ਲੇਖ ਏ. ਐਂਟੀਪੋਵ, ਏ. ਗਾਨੁਸ਼, ਪਲੇਟਫਾਰਮ ਇੰਜੀਨੀਅਰ ਦੁਆਰਾ ਲਿਖਿਆ ਗਿਆ ਸੀ। 

ਸਰੋਤ: www.habr.com