ਡਾਟਾਬੇਸ ਕਲੱਸਟਰਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਆਪਰੇਟਰ। ਵਲਾਦਿਸਲਾਵ ਕਲੀਮੇਂਕੋ (ਅਲਟੀਨਿਟੀ, 2019)

ਰਿਪੋਰਟ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇੱਕ ਆਪਰੇਟਰ ਨੂੰ ਵਿਕਸਤ ਕਰਨ, ਇਸਦੇ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਬੁਨਿਆਦੀ ਓਪਰੇਟਿੰਗ ਸਿਧਾਂਤਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੇ ਵਿਹਾਰਕ ਮੁੱਦਿਆਂ ਨੂੰ ਸਮਰਪਿਤ ਹੈ।

ਰਿਪੋਰਟ ਦੇ ਪਹਿਲੇ ਹਿੱਸੇ ਵਿੱਚ ਅਸੀਂ ਵਿਚਾਰ ਕਰਾਂਗੇ:

• ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇੱਕ ਆਪਰੇਟਰ ਕੀ ਹੈ ਅਤੇ ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਹੈ;
• ਓਪਰੇਟਰ ਗੁੰਝਲਦਾਰ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਪ੍ਰਬੰਧਨ ਨੂੰ ਕਿਵੇਂ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ;
• ਓਪਰੇਟਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਅੱਗੇ, ਆਉ ਆਪਰੇਟਰ ਦੀ ਅੰਦਰੂਨੀ ਬਣਤਰ ਬਾਰੇ ਚਰਚਾ ਕਰਨ ਲਈ ਅੱਗੇ ਵਧਦੇ ਹਾਂ। ਆਉ ਕਦਮ ਦਰ ਕਦਮ ਓਪਰੇਟਰ ਦੇ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਸੰਚਾਲਨ ਨੂੰ ਵੇਖੀਏ. ਆਓ ਇਸ ਨੂੰ ਵਿਸਥਾਰ ਵਿੱਚ ਵੇਖੀਏ:

• ਆਪਰੇਟਰ ਅਤੇ ਕੁਬਰਨੇਟਸ ਵਿਚਕਾਰ ਪਰਸਪਰ ਪ੍ਰਭਾਵ;
• ਓਪਰੇਟਰ ਕਿਹੜੇ ਫੰਕਸ਼ਨ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਕੁਬਰਨੇਟਸ ਨੂੰ ਕਿਹੜੇ ਫੰਕਸ਼ਨ ਸੌਂਪਦਾ ਹੈ।

ਆਉ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸ਼ਾਰਡਸ ਅਤੇ ਡੇਟਾਬੇਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੇ ਪ੍ਰਬੰਧਨ ਨੂੰ ਵੇਖੀਏ।
ਅੱਗੇ, ਅਸੀਂ ਡੇਟਾ ਸਟੋਰੇਜ ਮੁੱਦਿਆਂ 'ਤੇ ਚਰਚਾ ਕਰਾਂਗੇ:

• ਕਿਸੇ ਆਪਰੇਟਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਪਰਸਿਸਟੈਂਟ ਸਟੋਰੇਜ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ;
• ਸਥਾਨਕ ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਨੁਕਸਾਨ

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

ਵੀਡੀਓ:

ਮੇਰਾ ਨਾਮ Vladislav Klimenko ਹੈ. ਅੱਜ ਮੈਂ ਇੱਕ ਓਪਰੇਟਰ ਦੇ ਵਿਕਾਸ ਅਤੇ ਸੰਚਾਲਨ ਵਿੱਚ ਸਾਡੇ ਅਨੁਭਵ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ, ਅਤੇ ਇਹ ਡੇਟਾਬੇਸ ਕਲੱਸਟਰਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਆਪਰੇਟਰ ਹੈ। ਉਦਾਹਰਣ ਲਈ ਘਰ-ਆਪਰੇਟਰ 'ਤੇ ਕਲਿੱਕ ਕਰੋ ਕਲਿਕਹਾਊਸ ਕਲੱਸਟਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ।

ਸਾਡੇ ਕੋਲ ਓਪਰੇਟਰ ਅਤੇ ਕਲਿਕਹਾਊਸ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦਾ ਮੌਕਾ ਕਿਉਂ ਹੈ?

• ਅਸੀਂ ਕਲਿਕਹਾਊਸ ਦਾ ਸਮਰਥਨ ਅਤੇ ਵਿਕਾਸ ਕਰਦੇ ਹਾਂ।
• ਇਸ ਸਮੇਂ, ਅਸੀਂ ਹੌਲੀ ਹੌਲੀ ਕਲਿਕਹਾਊਸ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਆਪਣਾ ਯੋਗਦਾਨ ਪਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ। ਅਤੇ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਕੀਤੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਮਾਤਰਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਅਸੀਂ ਯਾਂਡੇਕਸ ਤੋਂ ਬਾਅਦ ਦੂਜੇ ਨੰਬਰ 'ਤੇ ਹਾਂ।
• ਅਸੀਂ ਕਲਿਕਹਾਊਸ ਈਕੋਸਿਸਟਮ ਲਈ ਵਾਧੂ ਪ੍ਰੋਜੈਕਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ।

ਮੈਂ ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਬਾਰੇ ਦੱਸਣਾ ਚਾਹਾਂਗਾ। ਇਹ ਕੁਬਰਨੇਟਸ ਲਈ ਕਲਿਕਹਾਊਸ-ਓਪਰੇਟਰ ਬਾਰੇ ਹੈ।

ਮੇਰੀ ਰਿਪੋਰਟ ਵਿੱਚ ਮੈਂ ਦੋ ਵਿਸ਼ਿਆਂ ਨੂੰ ਛੂਹਣਾ ਚਾਹਾਂਗਾ:

• ਪਹਿਲਾ ਵਿਸ਼ਾ ਇਹ ਹੈ ਕਿ ਸਾਡਾ ਕਲਿਕਹਾਊਸ ਡੇਟਾਬੇਸ ਪ੍ਰਬੰਧਨ ਆਪਰੇਟਰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।
• ਦੂਜਾ ਵਿਸ਼ਾ ਇਹ ਹੈ ਕਿ ਕੋਈ ਵੀ ਓਪਰੇਟਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਹ ਕੁਬਰਨੇਟਸ ਨਾਲ ਕਿਵੇਂ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ।

ਹਾਲਾਂਕਿ, ਇਹ ਦੋ ਸਵਾਲ ਮੇਰੀ ਸਾਰੀ ਰਿਪੋਰਟ ਵਿੱਚ ਆਪਸ ਵਿੱਚ ਹੋਣਗੇ।

ਮੈਂ ਜੋ ਦੱਸਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ ਉਸਨੂੰ ਸੁਣਨ ਵਿੱਚ ਕੌਣ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹੈ?

• ਇਹ ਉਹਨਾਂ ਲਈ ਸਭ ਤੋਂ ਵੱਧ ਦਿਲਚਸਪੀ ਵਾਲਾ ਹੋਵੇਗਾ ਜੋ ਆਪਰੇਟਰਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ.
• ਜਾਂ ਉਹਨਾਂ ਲਈ ਜੋ ਇਹ ਸਮਝਣ ਲਈ ਆਪਣਾ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਇਹ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਓਪਰੇਟਰ ਕੁਬਰਨੇਟਸ ਨਾਲ ਕਿਵੇਂ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੀਆਂ ਕਮੀਆਂ ਦਿਖਾਈ ਦੇ ਸਕਦੀਆਂ ਹਨ।

ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਅਸੀਂ ਅੱਜ ਕਿਸ ਬਾਰੇ ਚਰਚਾ ਕਰਾਂਗੇ, ਇਹ ਜਾਣਨਾ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਹੈ ਕਿ Kubernetes ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਬੁਨਿਆਦੀ ਕਲਾਉਡ ਸਿਖਲਾਈ ਪ੍ਰਾਪਤ ਕਰੋ।

ਕਲਿਕਹਾਊਸ ਕੀ ਹੈ? ਇਹ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਸਵਾਲਾਂ ਦੀ ਔਨਲਾਈਨ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਵਿਸ਼ੇਸ਼ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਾਲਾ ਇੱਕ ਕਾਲਮ ਡੇਟਾਬੇਸ ਹੈ। ਅਤੇ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਓਪਨ ਸੋਰਸ ਹੈ।

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

ਉਸ ਦੀ ਉੱਥੇ ਲੋੜ ਕਿਉਂ ਹੈ? ਅਸੀਂ ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਚਲਾਉਣਾ ਜਾਰੀ ਕਿਉਂ ਨਹੀਂ ਰੱਖ ਸਕਦੇ? ਅਤੇ ਜਵਾਬ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਤਕਨੀਕੀ ਅਤੇ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਸੰਗਠਨਾਤਮਕ ਹਨ।

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

ਇਹ ਕਿੰਨਾ ਸੌਖਾ ਜਾਂ ਔਖਾ ਹੈ? ਇਹ, ਬੇਸ਼ਕ, ਹੱਥ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਪਰ ਇਹ ਇੰਨਾ ਸੌਖਾ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਖੁਦ ਕੁਬਰਨੇਟਸ ਦੇ ਪ੍ਰਬੰਧਨ ਦੀ ਵਾਧੂ ਗੁੰਝਲਤਾ ਹੈ, ਪਰ ਉਸੇ ਸਮੇਂ ਕਲਿਕਹਾਊਸ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਉੱਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ. ਅਤੇ ਅਜਿਹੇ ਇੱਕਤਰਤਾ ਦੇ ਨਤੀਜੇ.

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

ਇੱਕ ਗਤੀਸ਼ੀਲ ਸੰਰਚਨਾ ਦੇ ਨਾਲ, ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਕਾਫ਼ੀ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਮੁੱਦੇ ਹਨ ਜੋ DevOps 'ਤੇ ਇੱਕ ਨਿਰੰਤਰ ਲੋਡ ਬਣਾਉਂਦੇ ਹਨ:

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

ਇਹ ਰੁਟੀਨ ਕੰਮ ਹਨ ਜੋ ਮੈਂ ਅਸਲ ਵਿੱਚ ਵਰਤਣ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਣਾ ਚਾਹਾਂਗਾ।

ਕੁਬਰਨੇਟਸ ਆਪਣੇ ਆਪ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਬੁਨਿਆਦੀ ਪ੍ਰਣਾਲੀ ਦੀਆਂ ਚੀਜ਼ਾਂ 'ਤੇ.

ਕੁਬਰਨੇਟਸ ਚੀਜ਼ਾਂ ਦੀ ਸਹੂਲਤ ਅਤੇ ਸਵੈਚਾਲਤ ਕਰਨ ਵਿੱਚ ਚੰਗਾ ਹੈ ਜਿਵੇਂ ਕਿ:

• ਰਿਕਵਰੀ.
• ਰੀਸਟਾਰਟ ਕਰੋ।
• ਸਟੋਰੇਜ਼ ਸਿਸਟਮ ਪ੍ਰਬੰਧਨ.

ਇਹ ਚੰਗੀ ਗੱਲ ਹੈ, ਇਹ ਸਹੀ ਦਿਸ਼ਾ ਹੈ, ਪਰ ਉਹ ਇਸ ਬਾਰੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਜਾਣ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਕਲੱਸਟਰ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ।

ਅਸੀਂ ਹੋਰ ਚਾਹੁੰਦੇ ਹਾਂ, ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਸਾਰਾ ਡਾਟਾਬੇਸ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਕੰਮ ਕਰੇ।

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

ਅਤੇ ਅਸੀਂ ਇੱਕ ਅਜਿਹਾ ਹੱਲ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜੋ ਕੰਮ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ। ਇਹ Altinity ਤੋਂ Kubernetes ਲਈ ਇੱਕ ਕਲਿਕਹਾਊਸ-ਓਪਰੇਟਰ ਹੈ।

ਇੱਕ ਓਪਰੇਟਰ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਹੁੰਦਾ ਹੈ ਜਿਸਦਾ ਮੁੱਖ ਕੰਮ ਦੂਜੇ ਪ੍ਰੋਗਰਾਮਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਹੁੰਦਾ ਹੈ, ਭਾਵ ਇਹ ਇੱਕ ਪ੍ਰਬੰਧਕ ਹੁੰਦਾ ਹੈ।

ਅਤੇ ਇਸ ਵਿੱਚ ਵਿਵਹਾਰ ਦੇ ਨਮੂਨੇ ਸ਼ਾਮਲ ਹਨ. ਤੁਸੀਂ ਵਿਸ਼ੇ ਖੇਤਰ ਬਾਰੇ ਇਸ ਕੋਡਬੱਧ ਗਿਆਨ ਨੂੰ ਕਹਿ ਸਕਦੇ ਹੋ।

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

ਅਤੇ ਸਿਰਫ਼ ਆਪਰੇਟਰ ਇੱਕ ਰੋਬੋਟਿਕ ਸਹਾਇਕ ਹੈ ਜੋ ਮਾਈਕ੍ਰੋਟਾਸਕ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ DevOps ਦੀ ਮਦਦ ਕਰਦਾ ਹੈ।

ਤੁਹਾਨੂੰ ਇੱਕ ਆਪਰੇਟਰ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ? ਉਹ ਦੋ ਖੇਤਰਾਂ ਵਿੱਚ ਖਾਸ ਤੌਰ 'ਤੇ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦਾ ਹੈ:

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

ਇਹ ਜਾਂ ਤਾਂ ਉਹਨਾਂ ਦੁਆਰਾ ਸਭ ਤੋਂ ਵੱਧ ਲੋੜੀਂਦਾ ਹੈ ਜੋ ਆਪਣੀ ਯਾਤਰਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਨ, ਜਾਂ ਉਹਨਾਂ ਦੁਆਰਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਵੈਚਾਲਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਆਪਰੇਟਰ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਦੂਜੇ ਸਿਸਟਮਾਂ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰੀ ਹੈ? ਹੈਲਮ ਹੈ। ਇਹ ਕਲਿਕਹਾਊਸ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਵਿੱਚ ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ; ਤੁਸੀਂ ਹੈਲਮ ਚਾਰਟ ਬਣਾ ਸਕਦੇ ਹੋ, ਜੋ ਕਿ ਇੱਕ ਪੂਰਾ ਕਲਿਕਹਾਊਸ ਕਲੱਸਟਰ ਵੀ ਸਥਾਪਿਤ ਕਰੇਗਾ। ਫਿਰ ਓਪਰੇਟਰ ਅਤੇ ਇੱਕੋ ਵਿੱਚ ਕੀ ਅੰਤਰ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਹੇਲਮ?

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

ਇਹ ਸ਼ੁਰੂਆਤੀ ਹਿੱਸਾ ਸੀ, ਆਓ ਅੱਗੇ ਵਧੀਏ।

ਅਸੀਂ ਆਪਣੇ ਆਪਰੇਟਰ ਨੂੰ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹਾਂ? ਅਸੀਂ ਕਲਿਕਹਾਊਸ ਕਲੱਸਟਰ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਸਰੋਤ ਵਜੋਂ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ ਮੁੱਦੇ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ।

ਇੱਥੇ ਸਾਡੇ ਕੋਲ ਤਸਵੀਰ ਦੇ ਖੱਬੇ ਪਾਸੇ ਇਨਪੁਟ ਡੇਟਾ ਹੈ। ਇਹ ਇੱਕ ਕਲੱਸਟਰ ਨਿਰਧਾਰਨ ਦੇ ਨਾਲ YAML ਹੈ, ਜੋ ਕਿ kubectl ਦੁਆਰਾ ਕਲਾਸਿਕ ਤਰੀਕੇ ਨਾਲ Kubernetes ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਉੱਥੇ ਸਾਡਾ ਆਪਰੇਟਰ ਇਸਨੂੰ ਚੁੱਕਦਾ ਹੈ ਅਤੇ ਆਪਣਾ ਜਾਦੂ ਕਰਦਾ ਹੈ। ਅਤੇ ਆਉਟਪੁੱਟ 'ਤੇ ਸਾਨੂੰ ਹੇਠ ਦਿੱਤੀ ਸਕੀਮ ਮਿਲਦੀ ਹੈ। ਇਹ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਕਲਿਕਹਾਊਸ ਦਾ ਲਾਗੂਕਰਨ ਹੈ।

ਅਤੇ ਫਿਰ ਅਸੀਂ ਹੌਲੀ-ਹੌਲੀ ਦੇਖਾਂਗੇ ਕਿ ਓਪਰੇਟਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਕਿਹੜੇ ਖਾਸ ਕੰਮਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਸਿਰਫ਼ ਆਮ ਕੰਮਾਂ 'ਤੇ ਹੀ ਵਿਚਾਰ ਕਰਾਂਗੇ ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਸਮਾਂ ਸੀਮਤ ਹੈ। ਅਤੇ ਓਪਰੇਟਰ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰ ਸਕਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ 'ਤੇ ਚਰਚਾ ਨਹੀਂ ਕੀਤੀ ਜਾਵੇਗੀ।

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

ਜੇ ਤੁਸੀਂ ਵਿਸਥਾਰ ਵਿੱਚ ਸਮਝਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਅਸੀਂ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਘੱਟ ਜਾਂ ਘੱਟ ਵਿਨੀਤ ਰੂਪ ਵਿੱਚ ਬਣਾਈ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ।

ਆਉ ਇੱਕ ਵਿਹਾਰਕ ਸਮੱਸਿਆ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ. ਪਹਿਲਾ ਕੰਮ, ਜਿੱਥੇ ਅਸੀਂ ਸਾਰੇ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਪਹਿਲੀ ਉਦਾਹਰਣ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਚਲਾਉਣਾ ਹੈ। ਮੈਂ ਓਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਲਿਕਹਾਊਸ ਨੂੰ ਕਿਵੇਂ ਲਾਂਚ ਕਰ ਸਕਦਾ ਹਾਂ, ਭਾਵੇਂ ਮੈਨੂੰ ਅਸਲ ਵਿੱਚ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ? ਅਸੀਂ ਇੱਕ ਮੈਨੀਫੈਸਟੋ ਲਿਖ ਰਹੇ ਹਾਂ, ਕਿਉਂਕਿ... k8s ਨਾਲ ਸਾਰਾ ਸੰਚਾਰ ਮੈਨੀਫੈਸਟ ਰਾਹੀਂ ਸੰਚਾਰ ਹੁੰਦਾ ਹੈ।

ਇਹ ਅਜਿਹਾ ਗੁੰਝਲਦਾਰ ਮੈਨੀਫੈਸਟੋ ਹੈ। ਜੋ ਅਸੀਂ ਲਾਲ ਰੰਗ ਵਿੱਚ ਉਜਾਗਰ ਕੀਤਾ ਹੈ ਉਹ ਹੈ ਜਿਸ 'ਤੇ ਸਾਨੂੰ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਸੀਂ ਆਪਰੇਟਰ ਨੂੰ ਡੈਮੋ ਨਾਮਕ ਇੱਕ ਕਲੱਸਟਰ ਬਣਾਉਣ ਲਈ ਕਹਿੰਦੇ ਹਾਂ।

ਇਹ ਹੁਣ ਲਈ ਬੁਨਿਆਦੀ ਉਦਾਹਰਣ ਹਨ। ਸਟੋਰੇਜ ਦਾ ਅਜੇ ਵਰਣਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਅਸੀਂ ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ ਸਟੋਰੇਜ 'ਤੇ ਵਾਪਸ ਆਵਾਂਗੇ। ਫਿਲਹਾਲ, ਅਸੀਂ ਕਲੱਸਟਰ ਦੇ ਵਿਕਾਸ ਦੀ ਗਤੀਸ਼ੀਲਤਾ ਦਾ ਨਿਰੀਖਣ ਕਰਾਂਗੇ।

ਅਸੀਂ ਇਹ ਮੈਨੀਫੈਸਟੋ ਬਣਾਇਆ ਹੈ। ਅਸੀਂ ਇਸਨੂੰ ਆਪਣੇ ਆਪਰੇਟਰ ਨੂੰ ਖੁਆਉਂਦੇ ਹਾਂ। ਉਸਨੇ ਕੰਮ ਕੀਤਾ, ਉਸਨੇ ਜਾਦੂ ਕੀਤਾ.

ਅਸੀਂ ਕੰਸੋਲ ਨੂੰ ਦੇਖਦੇ ਹਾਂ। ਤਿੰਨ ਭਾਗਾਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਹੈ: ਇੱਕ ਪੌਡ, ਦੋ ਸੇਵਾਵਾਂ, ਅਤੇ ਇੱਕ ਸਟੇਟਫੁੱਲ ਸੈੱਟ।

ਆਪਰੇਟਰ ਨੇ ਕੰਮ ਕੀਤਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ ਕਿ ਉਸਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਬਣਾਇਆ ਹੈ।

ਉਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਉਂਦਾ ਹੈ। ਸਾਡੇ ਕੋਲ ਹਰੇਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਈ ਸਟੇਟਫੁਲਸੈੱਟ, ਪੋਡ, ਕੌਨਫਿਗਮੈਪ, ਪੂਰੇ ਕਲੱਸਟਰ ਲਈ ਕੌਨਫਿਗਮੈਪ ਹੈ। ਕਲੱਸਟਰ ਵਿੱਚ ਐਂਟਰੀ ਪੁਆਇੰਟਾਂ ਵਜੋਂ ਸੇਵਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸੇਵਾਵਾਂ ਕੇਂਦਰੀ ਲੋਡ ਬੈਲੈਂਸਰ ਸੇਵਾ ਹਨ ਅਤੇ ਹਰੇਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਈ, ਹਰੇਕ ਸ਼ਾਰਡ ਲਈ ਵੀ ਵਰਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।

ਸਾਡਾ ਮੂਲ ਕਲੱਸਟਰ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ। ਇਹ ਇੱਕ ਸਿੰਗਲ ਨੋਡ ਤੋਂ ਹੈ।

ਆਓ ਹੋਰ ਅੱਗੇ ਵਧੀਏ ਅਤੇ ਚੀਜ਼ਾਂ ਨੂੰ ਗੁੰਝਲਦਾਰ ਕਰੀਏ. ਸਾਨੂੰ ਕਲੱਸਟਰ ਨੂੰ ਕੱਟਣ ਦੀ ਲੋੜ ਹੈ।

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

ਇਹ ਉਹੀ ਫਾਈਲ ਹੈ ਜੋ ਸਿਸਟਮ ਦੇ ਵਾਧੇ ਦੇ ਨਾਲ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਵਿਕਸਤ ਹੁੰਦੀ ਹੈ। ਸਟੋਰੇਜ ਨੰਬਰ, ਸਟੋਰੇਜ ਬਾਰੇ ਅੱਗੇ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ, ਇਹ ਇੱਕ ਵੱਖਰਾ ਵਿਸ਼ਾ ਹੈ।

ਅਸੀਂ YAML ਆਪਰੇਟਰ ਨੂੰ ਭੋਜਨ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਦੇਖਦੇ ਹਾਂ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ।

ਆਪਰੇਟਰ ਨੇ ਸੋਚਿਆ ਅਤੇ ਹੇਠ ਲਿਖੀਆਂ ਸੰਸਥਾਵਾਂ ਬਣਾਈਆਂ। ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਦੋ ਪੌਡ, ਤਿੰਨ ਸੇਵਾਵਾਂ ਅਤੇ, ਅਚਾਨਕ, 2 ਸਟੇਟਫੁੱਲ ਸੈੱਟ ਹਨ। 2 ਸਟੇਟਫੁੱਲ ਸੈੱਟ ਕਿਉਂ?

ਚਿੱਤਰ 'ਤੇ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਸੀ - ਇਹ ਸਾਡੀ ਸ਼ੁਰੂਆਤੀ ਅਵਸਥਾ ਹੈ, ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਇੱਕ ਪੌਡ ਸੀ।

ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਬਣ ਗਿਆ. ਹੁਣ ਤੱਕ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ, ਇਸ ਨੂੰ ਡੁਪਲੀਕੇਟ ਕੀਤਾ ਗਿਆ ਹੈ.

ਅਤੇ ਦੋ ਸਟੇਟਫੁੱਲ ਸੈੱਟ ਕਿਉਂ ਬਣ ਗਏ? ਇੱਥੇ ਸਾਨੂੰ ਇਸ ਸਵਾਲ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਪੌਡਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਿਵੇਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਟੇਟਫੁਲਸੈੱਟ ਨਾਮਕ ਇੱਕ ਵਸਤੂ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਟੈਂਪਲੇਟ ਤੋਂ ਪੌਡਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਇੱਥੇ ਮੁੱਖ ਕਾਰਕ ਟੈਂਪਲੇਟ ਹੈ। ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਸਟੇਟਫੁਲਸੈੱਟ ਵਿੱਚ ਇੱਕ ਟੈਂਪਲੇਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਈ ਪੌਡ ਲਾਂਚ ਕਰ ਸਕਦੇ ਹੋ। ਅਤੇ ਇੱਥੇ ਮੁੱਖ ਵਾਕੰਸ਼ "ਇੱਕ ਟੈਂਪਲੇਟ ਲਈ ਬਹੁਤ ਸਾਰੇ ਪੌਡ" ਹੈ।

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

ਪਰ ਜੇਕਰ ਅਸੀਂ ਕੰਮ ਨੂੰ ਐਕਸਟਰਾਪੋਲੇਟ ਕਰਦੇ ਹਾਂ ਅਤੇ ਕਹਿੰਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਿਪਰੀਤ ਕਲੱਸਟਰ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਅਤੇ ਅਸੀਂ ਇੱਕ ਰੋਲਿੰਗ ਅਪਡੇਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਤੋਂ ਇੱਕ ਨਵੇਂ ਸੰਸਕਰਣ ਵਿੱਚ ਬਦਲਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ ਹਾਂ, ਪਰ ਅਸੀਂ ਸਿਰਫ਼ ਦੋਨਾਂ ਰੂਪਾਂ ਵਿੱਚ ਇੱਕ ਵਿਪਰੀਤ ਕਲੱਸਟਰ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਕਲਿਕਹਾਊਸ ਦੇ ਵੱਖ-ਵੱਖ ਸੰਸਕਰਣਾਂ ਅਤੇ ਵੱਖ-ਵੱਖ ਸਟੋਰੇਜ ਦੇ ਰੂਪ ਵਿੱਚ। ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, ਵੱਖ-ਵੱਖ ਡਿਸਕਾਂ 'ਤੇ, ਹੌਲੀ ਡਿਸਕਾਂ 'ਤੇ, ਆਮ ਤੌਰ 'ਤੇ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਿਭਿੰਨ ਕਲੱਸਟਰ ਬਣਾਉਣ ਲਈ ਕੁਝ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਬਣਾਉਣੀਆਂ। ਅਤੇ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ StatefulSet ਇੱਕ ਟੈਪਲੇਟ ਤੋਂ ਇੱਕ ਪ੍ਰਮਾਣਿਤ ਹੱਲ ਬਣਾਉਂਦਾ ਹੈ, ਅਜਿਹਾ ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ.

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

ਚਲੋ ਵਿਹਾਰਕ ਸਮੱਸਿਆਵਾਂ ਵੱਲ ਮੁੜਦੇ ਹਾਂ। ਸਾਡੇ ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਨੂੰ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਜਿਵੇਂ ਕਿ. ਤੁਹਾਨੂੰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਕਲਿਕਹਾਊਸ ਦੀ ਕੁਝ ਸੰਰਚਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਆਪਰੇਟਰ ਇਸ ਲਈ ਸਾਰੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਅਸੀਂ ਸਿੱਧੇ YAML ਵਿੱਚ ਉਹ ਲਿਖ ਸਕਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ। ਸਾਰੇ ਸੰਰਚਨਾ ਵਿਕਲਪਾਂ ਨੂੰ ਇਸ YAML ਤੋਂ ਸਿੱਧਾ ਕਲਿਕਹਾਊਸ ਕੌਂਫਿਗਸ ਵਿੱਚ ਮੈਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਫਿਰ ਸਾਰੇ ਕਲੱਸਟਰ ਵਿੱਚ ਵੰਡੇ ਜਾਂਦੇ ਹਨ।

ਤੁਸੀਂ ਇਸ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖ ਸਕਦੇ ਹੋ। ਇਹ ਉਦਾਹਰਨ ਲਈ ਹੈ. ਪਾਸਵਰਡ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਬਿਲਕੁਲ ਸਾਰੇ ਕਲਿਕਹਾਊਸ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿਕਲਪ ਸਮਰਥਿਤ ਹਨ। ਇੱਥੇ ਸਿਰਫ਼ ਇੱਕ ਉਦਾਹਰਨ ਹੈ.

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

ਆਉ ਕੰਮ ਨੂੰ ਗੁੰਝਲਦਾਰ ਕਰੀਏ. ਕਲੱਸਟਰ ਵਿਕਸਿਤ ਹੋ ਰਿਹਾ ਹੈ। ਅਸੀਂ ਡੇਟਾ ਨੂੰ ਦੁਹਰਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਭਾਵ, ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਦੋ ਸ਼ਾਰਡ ਹਨ, ਹਰ ਇੱਕ ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਅਤੇ ਉਪਭੋਗਤਾ ਸੰਰਚਿਤ ਹਨ। ਅਸੀਂ ਵਧ ਰਹੇ ਹਾਂ ਅਤੇ ਨਕਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਸਾਨੂੰ ਨਕਲ ਲਈ ਕੀ ਚਾਹੀਦਾ ਹੈ?

ਸਾਨੂੰ ZooKeeper ਦੀ ਲੋੜ ਹੈ। ਕਲਿਕਹਾਊਸ ਵਿੱਚ, ਜ਼ੂਕੀਪਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਬਣਾਈ ਜਾਂਦੀ ਹੈ। ZooKeeper ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਕਿ ਵੱਖ-ਵੱਖ ਕਲਿਕਹਾਊਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਸਹਿਮਤੀ ਹੋਵੇ ਕਿ ਕਿਹੜੇ ਡੇਟਾ ਬਲਾਕ ਕਿਹੜੇ ਕਲਿਕਹਾਊਸ 'ਤੇ ਹਨ।

ZooKeeper ਨੂੰ ਕੋਈ ਵੀ ਵਰਤ ਸਕਦਾ ਹੈ। ਜੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕੋਲ ਬਾਹਰੀ ਚਿੜੀਆਘਰ ਹੈ, ਤਾਂ ਇਸਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਸਾਡੇ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਇੰਸਟਾਲ ਕਰ ਸਕਦੇ ਹੋ। ਇੱਥੇ ਇੱਕ ਇੰਸਟੌਲਰ ਹੈ ਜੋ ਇਸ ਸਾਰੀ ਚੀਜ਼ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।

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

ਅਤੇ K8s ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਨਕਲ ਕਰਨ ਲਈ ਕਲਿਕਹਾਊਸ ਲਈ ਇਹ ਸਭ ਜ਼ਰੂਰੀ ਹੈ।

ਆਉ ਹੁਣ ਕੰਮ ਨੂੰ ਖੁਦ ਦੇਖੀਏ, ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਈ ਮੈਨੀਫੈਸਟ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦੇਵੇਗਾ।

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

ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਸੀ.

ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਬਣ ਜਾਂਦਾ ਹੈ। ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਜੋੜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਚੌਥਾ ਇੱਕ ਫਿੱਟ ਨਹੀਂ ਸੀ, ਅਸੀਂ ਵਿਸ਼ਵਾਸ ਕਰਦੇ ਹਾਂ ਕਿ ਉੱਥੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਹੋ ਸਕਦੇ ਹਨ. ਅਤੇ ZooKeeper ਨੂੰ ਪਾਸੇ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ। ਸਕੀਮਾਂ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੁੰਦੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ।

ਅਤੇ ਇਹ ਅਗਲਾ ਕੰਮ ਜੋੜਨ ਦਾ ਸਮਾਂ ਹੈ। ਅਸੀਂ ਪਰਸਿਸਟੈਂਟ ਸਟੋਰੇਜ ਜੋੜਾਂਗੇ।

ਪਰਸਿਸਟੈਂਟ ਸਟੋਰੇਜ ਲਈ ਸਾਡੇ ਕੋਲ ਕਈ ਵਿਕਲਪ ਹਨ।

ਜੇ ਅਸੀਂ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ਵਿੱਚ ਚੱਲ ਰਹੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, ਐਮਾਜ਼ਾਨ, ਗੂਗਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤਾਂ ਕਲਾਉਡ ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਪਰਤਾਵਾ ਹੈ. ਇਹ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ, ਇਹ ਵਧੀਆ ਹੈ.

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

ਆਓ ਦੇਖੀਏ ਕਿ ਕਲਾਉਡ ਸਟੋਰੇਜ ਬਾਰੇ ਸਾਡੇ ਕੋਲ ਕੀ ਹੈ।

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

ਅਤੇ ਇੱਕ ਕਮੀ ਹੈ. ਕੁਝ ਲਈ, ਇਹ ਇੱਕ ਗੈਰ-ਨਾਜ਼ੁਕ ਕਮੀ ਹੈ। ਬੇਸ਼ੱਕ, ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਕੁਝ ਮੁੱਦੇ ਹੋਣਗੇ. ਇਹ ਵਰਤਣ ਲਈ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਭਰੋਸੇਮੰਦ ਹੈ, ਪਰ ਕੁਝ ਸੰਭਾਵੀ ਪ੍ਰਦਰਸ਼ਨ ਕਮੀਆਂ ਹਨ.

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

ਅਤੇ ਇਸਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਲਾਭ ਲੈਣ ਲਈ, ਸਾਨੂੰ ਸਥਾਨਕ ਸਟੋਰੇਜ ਦੀ ਲੋੜ ਹੈ।

ਕੁਬਰਨੇਟਸ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਥਾਨਕ ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਤਿੰਨ ਐਬਸਟਰੈਕਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ:

• ਖਾਲੀ ਡਾਇਰ
• ਹੋਸਟਪਾਥ।
• ਸਥਾਨਕ

ਆਓ ਦੇਖੀਏ ਕਿ ਉਹ ਕਿਵੇਂ ਵੱਖਰੇ ਹਨ ਅਤੇ ਉਹ ਕਿਵੇਂ ਸਮਾਨ ਹਨ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਤਿੰਨੋਂ ਪਹੁੰਚਾਂ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਸਟੋਰੇਜ ਹੈ - ਇਹ ਲੋਕਲ ਡਿਸਕਾਂ ਹਨ ਜੋ ਇੱਕੋ ਭੌਤਿਕ k8s ਨੋਡ 'ਤੇ ਸਥਿਤ ਹਨ। ਪਰ ਉਹਨਾਂ ਵਿੱਚ ਕੁਝ ਅੰਤਰ ਹਨ।

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

ਅਭਿਆਸ ਵਿੱਚ, ਡੌਕਰ ਆਪਣੇ ਮਾਰਗਾਂ ਦੇ ਨਾਲ ਕਿਤੇ ਇੱਕ ਅਸਥਾਈ ਫੋਲਡਰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਲੰਬਾ ਹੈਸ਼ ਕਹਿੰਦਾ ਹੈ। ਅਤੇ ਇਸ ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਲਈ ਇੱਕ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਇਹ ਕੰਮ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਹਿਸਾਬ ਨਾਲ ਕਿਵੇਂ ਹੋਵੇਗਾ? ਇਹ ਲੋਕਲ ਡਿਸਕ ਸਪੀਡ 'ਤੇ ਕੰਮ ਕਰੇਗਾ, ਯਾਨੀ. ਇਹ ਤੁਹਾਡੇ ਪੇਚ ਤੱਕ ਪੂਰੀ ਪਹੁੰਚ ਹੈ.

ਪਰ ਇਸ ਮਾਮਲੇ 'ਚ ਇਸਦੀ ਕਮੀ ਹੈ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਪਰਸਿਸਟੈਂਟ ਕਾਫ਼ੀ ਸ਼ੱਕੀ ਹੈ। ਪਹਿਲੀ ਵਾਰ ਡੌਕਰ ਕੰਟੇਨਰਾਂ ਨਾਲ ਚਲਦਾ ਹੈ, ਪਰਸਿਸਟੈਂਟ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ. ਜੇਕਰ ਕੁਬਰਨੇਟਸ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਇਸ ਪੋਡ ਨੂੰ ਕਿਸੇ ਹੋਰ ਡਿਸਕ 'ਤੇ ਲਿਜਾਣਾ ਚਾਹੁੰਦਾ ਹੈ, ਤਾਂ ਡਾਟਾ ਖਤਮ ਹੋ ਜਾਵੇਗਾ।

ਇਹ ਪਹੁੰਚ ਟੈਸਟਾਂ ਲਈ ਵਧੀਆ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ ਆਮ ਗਤੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਕਿਸੇ ਗੰਭੀਰ ਚੀਜ਼ ਲਈ ਇਹ ਵਿਕਲਪ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ।

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

ਇਸ ਵਿਧੀ ਦੇ ਫਾਇਦੇ ਹਨ. ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਅਸਲੀ ਸਥਾਈ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਇੱਕ ਕਲਾਸਿਕ ਹੈ. ਸਾਡੇ ਕੋਲ ਕਿਸੇ ਪਤੇ 'ਤੇ ਡਿਸਕ 'ਤੇ ਰਿਕਾਰਡ ਕੀਤਾ ਡੇਟਾ ਹੋਵੇਗਾ।

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

ਖਾਸ ਕਰਕੇ ਇਹਨਾਂ ਉਦੇਸ਼ਾਂ ਲਈ, ਅਸੀਂ ਇਸ ਸਾਰੀ ਗੁੰਝਲਤਾ ਨੂੰ ਛੁਪਾਉਣ ਲਈ ਆਪਣੇ ਆਪਰੇਟਰ ਵਿੱਚ ਟੈਂਪਲੇਟ ਬਣਾਏ ਹਨ। ਅਤੇ ਤੁਸੀਂ ਬਸ ਕਹਿ ਸਕਦੇ ਹੋ: "ਮੈਂ ਹਰੇਕ ਭੌਤਿਕ ਨੋਡ ਲਈ ਕਲਿਕਹਾਊਸ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਅਤੇ ਅਜਿਹੇ ਅਤੇ ਅਜਿਹੇ ਮਾਰਗ ਦੇ ਨਾਲ ਰੱਖਣਾ ਚਾਹੁੰਦਾ ਹਾਂ."

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

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

ਆਉ ਆਪਣੀ ਵਿਹਾਰਕ ਸਮੱਸਿਆ ਵੱਲ ਮੁੜਦੇ ਹਾਂ। ਚਲੋ YAML ਟੈਂਪਲੇਟ ਤੇ ਵਾਪਸ ਚਲੀਏ। ਇੱਥੇ ਸਾਡੇ ਕੋਲ ਅਸਲੀ ਸਟੋਰੇਜ ਹੈ। ਅਸੀਂ ਇਸ 'ਤੇ ਵਾਪਸ ਆ ਗਏ ਹਾਂ। ਅਸੀਂ k8s ਵਾਂਗ ਕਲਾਸਿਕ VolumeClaim ਟੈਂਪਲੇਟ ਸੈੱਟ ਕੀਤਾ ਹੈ। ਅਤੇ ਅਸੀਂ ਵਰਣਨ ਕਰਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਕਿਸ ਕਿਸਮ ਦੀ ਸਟੋਰੇਜ ਚਾਹੁੰਦੇ ਹਾਂ।

ਇਸ ਤੋਂ ਬਾਅਦ, k8s ਸਟੋਰੇਜ ਲਈ ਬੇਨਤੀ ਕਰੇਗਾ। ਸਟੇਟਫੁਲਸੈੱਟ ਵਿੱਚ ਸਾਨੂੰ ਇਸ ਨੂੰ ਅਲਾਟ ਕਰੇਗਾ। ਅਤੇ ਅੰਤ ਵਿੱਚ ਇਹ ਕਲਿਕਹਾਊਸ ਦੇ ਨਿਪਟਾਰੇ 'ਤੇ ਹੋਵੇਗਾ।

ਸਾਡੇ ਕੋਲ ਇਹ ਸਕੀਮ ਸੀ. ਸਾਡਾ ਸਥਾਈ ਸਟੋਰੇਜ ਲਾਲ ਸੀ, ਜੋ ਸੰਕੇਤ ਦਿੰਦਾ ਸੀ ਕਿ ਇਸਨੂੰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਅਤੇ ਇਹ ਹਰਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਹੁਣ k8s ਕਲੱਸਟਰ ਸਕੀਮ 'ਤੇ ਕਲਿਕਹਾਊਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅੰਤਿਮ ਰੂਪ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਸਾਡੇ ਕੋਲ ਸ਼ਾਰਡਜ਼, ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ, ਜ਼ੂਕੀਪਰ ਹਨ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਅਸਲੀ ਪਰਸਿਸਟੈਂਟ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਕੀਮ ਪਹਿਲਾਂ ਹੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਰਹੀ ਹੈ।

ਅਸੀਂ ਜਿਉਂਦੇ ਰਹਿੰਦੇ ਹਾਂ। ਸਾਡਾ ਕਲੱਸਟਰ ਵਿਕਸਿਤ ਹੋ ਰਿਹਾ ਹੈ। ਅਤੇ ਅਲੈਕਸੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਲਿਕਹਾਊਸ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਜਾਰੀ ਕਰਦਾ ਹੈ।

ਇੱਕ ਵਿਹਾਰਕ ਕੰਮ ਪੈਦਾ ਹੁੰਦਾ ਹੈ - ਸਾਡੇ ਕਲੱਸਟਰ 'ਤੇ ਕਲਿਕਹਾਊਸ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ। ਅਤੇ, ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ ਇਸ ਨੂੰ ਰੋਲ ਆਊਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ; ਤੁਸੀਂ ਦੂਰ ਕੋਨੇ ਵਿੱਚ ਕਿਤੇ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਸੰਸਕਰਣ ਲਗਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇੱਕ ਨਵਾਂ ਸੰਸਕਰਣ ਨਹੀਂ, ਪਰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਦੋ, ਕਿਉਂਕਿ ਉਹ ਅਕਸਰ ਬਾਹਰ ਆਉਂਦੇ ਹਨ।

ਅਸੀਂ ਇਸ ਬਾਰੇ ਕੀ ਕਹਿ ਸਕਦੇ ਹਾਂ?

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

ਆਓ ਥੋੜਾ ਹੋਰ ਡੂੰਘੇ ਅੰਦਰ ਜਾਈਏ। ਇਸ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਸੀ ਕਿ ਕਲਿਕਹਾਊਸ-ਓਪਰੇਟਰ ਕਲਿਕਹਾਊਸ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਸਬੰਧ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਹੁਣ ਮੈਂ ਇਸ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ ਕਹਿਣਾ ਚਾਹਾਂਗਾ ਕਿ ਕੋਈ ਵੀ ਓਪਰੇਟਰ ਆਮ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਨਾਲ ਹੀ ਇਹ K8s ਨਾਲ ਕਿਵੇਂ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ।

ਆਓ ਪਹਿਲਾਂ K8s ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀਏ। ਜਦੋਂ ਅਸੀਂ kubectl ਲਾਗੂ ਕਰਦੇ ਹਾਂ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ? ਸਾਡੀਆਂ ਵਸਤੂਆਂ API ਰਾਹੀਂ etcd ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।

ਉਦਾਹਰਨ ਲਈ, ਬੁਨਿਆਦੀ ਕੁਬਰਨੇਟਸ ਆਬਜੈਕਟ: ਪੌਡ, ਸਟੇਟਫੁਲਸੈੱਟ, ਸੇਵਾ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਸੂਚੀ ਹੇਠਾਂ।

ਉਸੇ ਸਮੇਂ, ਕੁਝ ਵੀ ਸਰੀਰਕ ਨਹੀਂ ਹੁੰਦਾ. ਇਹ ਵਸਤੂਆਂ ਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ ਉਦੇਸ਼ ਲਈ, ਇੱਕ ਕੰਟਰੋਲਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਕੰਟਰੋਲਰ ਇੱਕ ਖਾਸ k8s ਕੰਪੋਨੈਂਟ ਹੈ ਜੋ ਇਹਨਾਂ ਵੇਰਵਿਆਂ ਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ। ਉਹ ਜਾਣਦਾ ਹੈ ਕਿ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਅਤੇ ਕੀ ਕਰਨਾ ਹੈ। ਉਹ ਜਾਣਦਾ ਹੈ ਕਿ ਕੰਟੇਨਰਾਂ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ, ਸਰਵਰ ਦੇ ਕੰਮ ਕਰਨ ਲਈ ਉੱਥੇ ਕੀ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਅਤੇ ਇਹ ਸਾਡੀਆਂ ਵਸਤੂਆਂ ਨੂੰ K8s ਵਿੱਚ ਸਾਕਾਰ ਕਰਦਾ ਹੈ।

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

ਪਰ K8s ਕੋਲ ਹੇਠ ਲਿਖੀ ਚੰਗੀ ਚੀਜ਼ ਹੈ. ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਇਸ ਗੁੰਝਲਦਾਰ ਹਸਤੀ ਵਰਗੀ ਕਿਤੇ ਹੋਵੇ ਜਿਸ ਵਿੱਚ ਸਾਡੇ ਕਲੱਸਟਰ ਨੂੰ ਪੌਡਸ ਅਤੇ ਸਟੇਟਫੁਲਸੈੱਟ ਤੋਂ ਅਸੈਂਬਲ ਕੀਤਾ ਜਾਵੇਗਾ।

ਅਤੇ ਇਸ ਲਈ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਪਹਿਲਾਂ, ਕਸਟਮ ਸਰੋਤ ਪਰਿਭਾਸ਼ਾ ਤਸਵੀਰ ਵਿੱਚ ਆਉਂਦੀ ਹੈ. ਇਹ ਕੀ ਹੈ? ਇਹ K8s ਲਈ ਇੱਕ ਵਰਣਨ ਹੈ, ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਹੋਰ ਡੇਟਾ ਕਿਸਮ ਹੋਵੇਗੀ, ਜੋ ਕਿ ਅਸੀਂ ਪੌਡ, ਸਟੇਟਫੁਲਸੈੱਟ ਵਿੱਚ ਇੱਕ ਕਸਟਮ ਸਰੋਤ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਜੋ ਅੰਦਰੋਂ ਗੁੰਝਲਦਾਰ ਹੋਵੇਗਾ। ਇਹ ਡੇਟਾ ਢਾਂਚੇ ਦਾ ਵਰਣਨ ਹੈ।

ਅਸੀਂ ਇਸਨੂੰ ਉੱਥੇ kubectl apply ਰਾਹੀਂ ਵੀ ਭੇਜਦੇ ਹਾਂ। ਕੁਬਰਨੇਟਸ ਨੇ ਖੁਸ਼ੀ ਨਾਲ ਇਸਨੂੰ ਲੈ ਲਿਆ।

ਅਤੇ ਹੁਣ ਸਾਡੇ ਸਟੋਰੇਜ਼ ਵਿੱਚ, etcd ਵਿੱਚ ਵਸਤੂ ਕੋਲ ClickHouseInstallation ਨਾਮਕ ਇੱਕ ਕਸਟਮ ਸਰੋਤ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨ ਦਾ ਮੌਕਾ ਹੈ।

ਪਰ ਫਿਲਹਾਲ ਹੋਰ ਕੁਝ ਨਹੀਂ ਹੋਵੇਗਾ। ਭਾਵ, ਜੇਕਰ ਅਸੀਂ ਹੁਣ YAML ਫਾਈਲ ਬਣਾਉਂਦੇ ਹਾਂ ਜੋ ਅਸੀਂ ਸ਼ਾਰਡਾਂ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋਏ ਵੇਖਦੇ ਹਾਂ ਅਤੇ ਕਹਿੰਦੇ ਹਾਂ "kubectl apply," ਤਾਂ Kubernetes ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰੇਗਾ, ਇਸਨੂੰ etcd ਵਿੱਚ ਪਾ ਦੇਵੇਗਾ ਅਤੇ ਕਹੇਗਾ: "ਬਹੁਤ ਵਧੀਆ, ਪਰ ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਕੀ ਕਰਨਾ ਹੈ ਇਸਦੇ ਨਾਲ. ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ClickHouseInstallation ਨੂੰ ਕਿਵੇਂ ਬਣਾਈ ਰੱਖਣਾ ਹੈ।

ਇਸ ਅਨੁਸਾਰ, ਸਾਨੂੰ ਕੁਬਰਨੇਟਸ ਦੀ ਨਵੀਂ ਡਾਟਾ ਕਿਸਮ ਦੀ ਸੇਵਾ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਕਿਸੇ ਦੀ ਲੋੜ ਹੈ। ਖੱਬੇ ਪਾਸੇ ਸਾਡੇ ਕੋਲ ਇੱਕ ਮੂਲ ਕੁਬਰਨੇਟਸ ਕੰਟਰੋਲਰ ਹੈ ਜੋ ਮੂਲ ਡਾਟਾ ਕਿਸਮਾਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਤੇ ਸੱਜੇ ਪਾਸੇ ਸਾਡੇ ਕੋਲ ਇੱਕ ਕਸਟਮ ਕੰਟਰੋਲਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਕਸਟਮ ਡੇਟਾ ਕਿਸਮਾਂ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ।

ਅਤੇ ਇੱਕ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਇਸਨੂੰ ਆਪਰੇਟਰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਮੈਂ ਇਸਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਇੱਥੇ ਕੁਬਰਨੇਟਸ ਵਜੋਂ ਸ਼ਾਮਲ ਕੀਤਾ ਹੈ, ਕਿਉਂਕਿ ਇਸਨੂੰ K8s ਤੋਂ ਬਾਹਰ ਵੀ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਬਹੁਤੇ ਅਕਸਰ, ਬੇਸ਼ੱਕ, ਸਾਰੇ ਓਪਰੇਟਰਾਂ ਨੂੰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਕੁਝ ਵੀ ਇਸ ਨੂੰ ਬਾਹਰ ਖੜ੍ਹੇ ਹੋਣ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ, ਇਸ ਲਈ ਇੱਥੇ ਇਸਨੂੰ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਬਾਹਰ ਲਿਜਾਇਆ ਜਾਂਦਾ ਹੈ।

ਅਤੇ ਬਦਲੇ ਵਿੱਚ, ਕਸਟਮ ਕੰਟਰੋਲਰ, ਜਿਸਨੂੰ ਆਪਰੇਟਰ ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, API ਦੁਆਰਾ ਕੁਬਰਨੇਟਸ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ। ਇਹ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਹੈ ਕਿ API ਨਾਲ ਕਿਵੇਂ ਗੱਲਬਾਤ ਕਰਨੀ ਹੈ. ਅਤੇ ਉਹ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਹੈ ਕਿ ਅਸੀਂ ਇੱਕ ਕਸਟਮ ਸਰੋਤ ਤੋਂ ਗੁੰਝਲਦਾਰ ਸਰਕਟ ਨੂੰ ਕਿਵੇਂ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ਆਪਰੇਟਰ ਕਰਦਾ ਹੈ।

ਆਪਰੇਟਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ? ਆਉ ਸੱਜੇ ਪਾਸੇ ਵੱਲ ਦੇਖੀਏ ਕਿ ਉਹ ਇਹ ਕਿਵੇਂ ਕਰਦਾ ਹੈ. ਆਉ ਇਹ ਪਤਾ ਕਰੀਏ ਕਿ ਓਪਰੇਟਰ ਇਸ ਸਭ ਨੂੰ ਕਿਵੇਂ ਸਾਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ K8s ਦੇ ਨਾਲ ਹੋਰ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਆਪਰੇਟਰ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਹੈ। ਉਹ ਘਟਨਾ-ਮੁਖੀ ਹੈ। ਆਪਰੇਟਰ ਕੁਬਰਨੇਟਸ API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇਵੈਂਟਾਂ ਦੀ ਗਾਹਕੀ ਲੈਂਦਾ ਹੈ। Kubernetes API ਵਿੱਚ ਐਂਟਰੀ ਪੁਆਇੰਟ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਇਵੈਂਟਸ ਦੀ ਗਾਹਕੀ ਲੈ ਸਕਦੇ ਹੋ। ਅਤੇ ਜੇ K8s ਵਿੱਚ ਕੁਝ ਬਦਲਦਾ ਹੈ, ਤਾਂ Kubernetes ਹਰ ਕਿਸੇ ਨੂੰ ਇਵੈਂਟ ਭੇਜਦਾ ਹੈ, i.e. ਜਿਸਨੇ ਵੀ ਇਸ API ਪੁਆਇੰਟ ਦੀ ਗਾਹਕੀ ਲਈ ਹੈ, ਉਸਨੂੰ ਸੂਚਨਾਵਾਂ ਪ੍ਰਾਪਤ ਹੋਣਗੀਆਂ।

ਆਪਰੇਟਰ ਇਵੈਂਟਾਂ ਦੀ ਗਾਹਕੀ ਲੈਂਦਾ ਹੈ ਅਤੇ ਉਸਨੂੰ ਕਿਸੇ ਕਿਸਮ ਦੀ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਇਸਦਾ ਕੰਮ ਉਭਰਦੀਆਂ ਘਟਨਾਵਾਂ ਦਾ ਜਵਾਬ ਦੇਣਾ ਹੈ.

ਇਵੈਂਟਸ ਕੁਝ ਅੱਪਡੇਟ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ClickHouseInstallation ਦੇ ਵੇਰਵੇ ਵਾਲੀ ਸਾਡੀ YAML ਫਾਈਲ ਆ ਗਈ ਹੈ। ਉਹ kubectl apply ਰਾਹੀਂ etcd ਗਿਆ। ਉੱਥੇ ਇੱਕ ਇਵੈਂਟ ਸ਼ੁਰੂ ਹੋਇਆ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਇਹ ਇਵੈਂਟ ਕਲਿਕਹਾਊਸ-ਓਪਰੇਟਰ ਕੋਲ ਆਇਆ। ਆਪਰੇਟਰ ਨੂੰ ਇਹ ਵੇਰਵਾ ਪ੍ਰਾਪਤ ਹੋਇਆ। ਅਤੇ ਉਸਨੂੰ ਕੁਝ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ClickHouseInstallation ਆਬਜੈਕਟ ਲਈ ਕੋਈ ਅੱਪਡੇਟ ਆ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਕਲੱਸਟਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਆਪਰੇਟਰ ਦਾ ਕੰਮ ਕਲੱਸਟਰ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਹੈ।

ਉਹ ਕੀ ਕਰ ਰਿਹਾ ਹੈ? ਪਹਿਲਾਂ, ਸਾਨੂੰ ਇਸ ਅੱਪਡੇਟ ਨਾਲ ਅਸੀਂ ਕੀ ਕਰਾਂਗੇ ਇਸ ਲਈ ਇੱਕ ਕਾਰਜ ਯੋਜਨਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਅੱਪਡੇਟ ਬਹੁਤ ਛੋਟੇ ਹੋ ਸਕਦੇ ਹਨ, i.e. YAML ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵਿੱਚ ਛੋਟਾ ਹੈ, ਪਰ ਕਲੱਸਟਰ ਵਿੱਚ ਬਹੁਤ ਵੱਡੀਆਂ ਤਬਦੀਲੀਆਂ ਲਿਆ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਓਪਰੇਟਰ ਇੱਕ ਯੋਜਨਾ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਉਹ ਇਸ ਨਾਲ ਜੁੜਦਾ ਹੈ.

ਇਸ ਯੋਜਨਾ ਦੇ ਅਨੁਸਾਰ, ਉਹ ਇਸ ਢਾਂਚੇ ਨੂੰ ਅੰਦਰ ਪਕਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਫਲੀਆਂ, ਸੇਵਾਵਾਂ, ਯਾਨੀ. ਉਸ ਦਾ ਮੁੱਖ ਕੰਮ ਕੀ ਹੈ. ਇਹ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇੱਕ ਕਲਿਕਹਾਊਸ ਕਲੱਸਟਰ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਹੈ।

ਆਓ ਹੁਣ ਅਜਿਹੀ ਦਿਲਚਸਪ ਗੱਲ ਨੂੰ ਛੂਹੀਏ. ਇਹ ਕੁਬਰਨੇਟਸ ਅਤੇ ਆਪਰੇਟਰ ਵਿਚਕਾਰ ਜ਼ਿੰਮੇਵਾਰੀ ਦੀ ਵੰਡ ਹੈ, ਯਾਨੀ. ਕੁਬਰਨੇਟਸ ਕੀ ਕਰਦਾ ਹੈ, ਆਪਰੇਟਰ ਕੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਇੱਕ ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ।

ਕੁਬਰਨੇਟਸ ਸਿਸਟਮ ਦੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਯਾਨੀ. ਵਸਤੂਆਂ ਦੇ ਇੱਕ ਬੁਨਿਆਦੀ ਸਮੂਹ ਲਈ ਜਿਸਦੀ ਵਿਆਖਿਆ ਸਿਸਟਮ-ਸਕੋਪ ਵਜੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਕੁਬਰਨੇਟਸ ਜਾਣਦਾ ਹੈ ਕਿ ਪੌਡਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਂਚ ਕਰਨਾ ਹੈ, ਕੰਟੇਨਰਾਂ ਨੂੰ ਕਿਵੇਂ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਹੈ, ਵਾਲੀਅਮ ਕਿਵੇਂ ਮਾਊਂਟ ਕਰਨਾ ਹੈ, ConfigMap ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ, ਜਿਵੇਂ ਕਿ. ਹਰ ਚੀਜ਼ ਜਿਸਨੂੰ ਸਿਸਟਮ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ।

ਓਪਰੇਟਰ ਡੋਮੇਨ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ। ਹਰੇਕ ਆਪਰੇਟਰ ਨੂੰ ਇਸਦੇ ਆਪਣੇ ਵਿਸ਼ੇ ਖੇਤਰ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਅਸੀਂ ਇਸਨੂੰ ਕਲਿਕਹਾਊਸ ਲਈ ਕੀਤਾ ਹੈ।

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

ਆਉ ਇੱਕ ਵਿਹਾਰਕ ਉਦਾਹਰਨ ਵੇਖੀਏ ਕਿ ਜਦੋਂ ਅਸੀਂ ਐਡ ਰਿਪਲੀਕਾ ਐਕਸ਼ਨ ਕਰਦੇ ਹਾਂ ਤਾਂ ਜ਼ਿੰਮੇਵਾਰੀ ਦੀ ਇਹ ਵੰਡ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ।

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

ਉਸਨੇ ਇਹ ਸਭ ਤਿਆਰ ਕੀਤਾ ਅਤੇ ਇਸਨੂੰ K8s ਨੂੰ ਭੇਜ ਦਿੱਤਾ। ਉਹ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਸਨੂੰ ConfigMap, StatefulSet, Volume ਦੀ ਲੋੜ ਹੈ। ਕੁਬਰਨੇਟਸ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਉਹ ਬੁਨਿਆਦੀ ਇਕਾਈਆਂ ਨੂੰ ਸਾਕਾਰ ਕਰਦਾ ਹੈ ਜਿਸ ਨਾਲ ਉਹ ਕੰਮ ਕਰਦਾ ਹੈ।

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

ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਕਲਿਕਹਾਊਸ ਆਪਣੇ ਆਪ ਵਿਚ ਆਉਂਦਾ ਹੈ, ਯਾਨੀ. ਇੱਕ ਹੋਰ ਉੱਚ ਪੱਧਰੀ ਸੰਸਥਾ। ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਡੇਟਾਬੇਸ ਹੈ। ਇਸਦਾ ਆਪਣਾ ਉਦਾਹਰਣ ਹੈ, ਇੱਕ ਹੋਰ ਸੰਰਚਿਤ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਜੋ ਕਲੱਸਟਰ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਲਈ ਤਿਆਰ ਹੈ।

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਜੋੜਦੇ ਸਮੇਂ ਲਾਗੂ ਕਰਨ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਦੀ ਵੰਡ ਦੀ ਇੱਕ ਲੜੀ ਕਾਫ਼ੀ ਲੰਬੀ ਹੈ।

ਅਸੀਂ ਆਪਣੇ ਵਿਹਾਰਕ ਕੰਮਾਂ ਨੂੰ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਕਲੱਸਟਰ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸੰਰਚਨਾ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰ ਸਕਦੇ ਹੋ।

ਅਸੀਂ ਇਸਨੂੰ ਇਸ ਲਈ ਬਣਾਇਆ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਮੌਜੂਦਾ xml ਵਿੱਚ ਪੇਸਟ ਕਰ ਸਕੋ, ਜਿਸਨੂੰ ਕਲਿਕਹਾਊਸ ਸਮਝਦਾ ਹੈ।

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

ਅਗਲਾ ਵਿਹਾਰਕ ਕੰਮ ਨਿਗਰਾਨੀ ਹੈ.

ਜੇਕਰ ਸਾਡਾ ਕਲੱਸਟਰ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਨਿਗਰਾਨੀ ਦੀ ਸੰਰਚਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਆਉ ਰੇਖਾ-ਚਿੱਤਰ ਦੇਖੀਏ। ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇੱਥੇ ਹਰੇ ਤੀਰ ਦੇਖ ਚੁੱਕੇ ਹਾਂ। ਹੁਣ ਆਉ ਲਾਲ ਤੀਰ ਵੱਲ ਵੇਖੀਏ. ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਆਪਣੇ ਕਲੱਸਟਰ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਕਲਿਕਹਾਊਸ ਕਲੱਸਟਰ ਤੋਂ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰੋਮੀਥੀਅਸ ਅਤੇ ਫਿਰ ਗ੍ਰਾਫਾਨਾ ਵਿੱਚ ਕਿਵੇਂ ਆਉਂਦੇ ਹਨ।

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

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

ਸਾਡੇ ਕਲੱਸਟਰ ਦਾ ਵਿਕਾਸ ਕਿਵੇਂ ਹੋਇਆ? ਸ਼ੁਰੂ ਵਿਚ ਉਹ ਅਜਿਹਾ ਹੀ ਸੀ।

ਫਿਰ ਉਹ ਇਸ ਤਰ੍ਹਾਂ ਸੀ।

ਅੰਤ ਵਿੱਚ, ਉਹ ਇਸ ਤਰ੍ਹਾਂ ਬਣ ਗਿਆ.

ਅਤੇ ਨਿਗਰਾਨੀ ਆਪਰੇਟਰ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਦਾਖਲੇ ਦਾ ਸਿੰਗਲ ਪੁਆਇੰਟ।

ਅਤੇ ਬਾਹਰ ਨਿਕਲਣ 'ਤੇ ਅਸੀਂ ਇਹ ਦੇਖਣ ਲਈ ਗ੍ਰਾਫਾਨਾ ਡੈਸ਼ਬੋਰਡ ਨੂੰ ਦੇਖਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕਲੱਸਟਰ ਦਾ ਜੀਵਨ ਅੰਦਰ ਕਿਵੇਂ ਉਬਾਲ ਰਿਹਾ ਹੈ।

ਤਰੀਕੇ ਨਾਲ, Grafana ਡੈਸ਼ਬੋਰਡ ਵੀ ਸਾਡੇ ਆਪਰੇਟਰ ਨਾਲ ਸਿੱਧੇ ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਜੁੜ ਸਕਦੇ ਹੋ ਅਤੇ ਵਰਤ ਸਕਦੇ ਹੋ। ਸਾਡੇ DevOps ਨੇ ਮੈਨੂੰ ਇਹ ਸਕ੍ਰੀਨਸ਼ੌਟ ਦਿੱਤਾ ਹੈ।

ਅਸੀਂ ਅੱਗੇ ਕਿੱਥੇ ਜਾਣਾ ਚਾਹਾਂਗੇ? ਇਹ:

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

ਚਲੋ ਕੁਝ ਵਿਚਕਾਰਲੇ ਨਤੀਜੇ ਲੈਂਦੇ ਹਾਂ।

ਨਤੀਜੇ ਵਜੋਂ ਸਾਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ? ਅਤੇ ਕੀ ਇਹ ਕਰਨ ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ? ਕੀ ਡੇਟਾਬੇਸ ਨੂੰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਖਿੱਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਆਪਰੇਟਰ ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਅਲਿਟਨਿਟੀ ਆਪਰੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਵੀ ਜ਼ਰੂਰੀ ਹੈ?

ਆਉਟਪੁੱਟ 'ਤੇ ਸਾਨੂੰ ਮਿਲਦਾ ਹੈ:

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

ਸਿਰਫ਼ ਇੱਕ ਆਖਰੀ ਸਵਾਲ ਬਾਕੀ ਹੈ। ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੁਬਰਨੇਟਸ, ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਵਿੱਚ ਇੱਕ ਡੇਟਾਬੇਸ ਹੈ। ਅਜਿਹੇ ਹੱਲ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਬਾਰੇ ਕੀ, ਖਾਸ ਕਰਕੇ ਕਿਉਂਕਿ ਕਲਿਕਹਾਊਸ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਅਨੁਕੂਲ ਹੈ?

ਜਵਾਬ ਹੈ ਸਭ ਕੁਝ ਠੀਕ ਹੈ! ਮੈਂ ਵਿਸਥਾਰ ਵਿੱਚ ਨਹੀਂ ਜਾਵਾਂਗਾ; ਇਹ ਇੱਕ ਵੱਖਰੀ ਰਿਪੋਰਟ ਦਾ ਵਿਸ਼ਾ ਹੈ।

ਪਰ TSBS ਵਰਗਾ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਹੈ. ਇਸ ਦਾ ਮੁੱਖ ਕੰਮ ਕੀ ਹੈ? ਇਹ ਇੱਕ ਡਾਟਾਬੇਸ ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟ ਹੈ। ਇਹ ਗਰਮ ਨਾਲ ਗਰਮ, ਨਰਮ ਨਾਲ ਨਰਮ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਹੈ.

ਉਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ? ਇੱਕ ਡਾਟਾ ਸੈੱਟ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਫਿਰ ਡੇਟਾ ਦਾ ਇਹ ਸੈੱਟ ਟੈਸਟਾਂ ਦੇ ਇੱਕੋ ਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸਾਂ 'ਤੇ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਹਰੇਕ ਡੇਟਾਬੇਸ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕਰਦਾ ਹੈ ਜਿਸ ਤਰ੍ਹਾਂ ਇਹ ਜਾਣਦਾ ਹੈ ਕਿ ਕਿਵੇਂ. ਅਤੇ ਫਿਰ ਤੁਸੀਂ ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹੋ.

ਇਹ ਪਹਿਲਾਂ ਹੀ ਡੇਟਾਬੇਸ ਦੇ ਇੱਕ ਵੱਡੇ ਸਮੂਹ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ. ਮੈਂ ਤਿੰਨ ਮੁੱਖ ਪਛਾਣੇ ਹਨ। ਇਹ:

• ਟਾਈਮਸਕੇਲDB।
• InfluxDB।
• ਕਲਿਕ ਹਾਊਸ.

ਇੱਕ ਹੋਰ ਸਮਾਨ ਹੱਲ ਨਾਲ ਤੁਲਨਾ ਵੀ ਕੀਤੀ ਗਈ ਸੀ। RedShift ਨਾਲ ਤੁਲਨਾ. ਅਮੇਜ਼ਨ 'ਤੇ ਤੁਲਨਾ ਕੀਤੀ ਗਈ ਸੀ। ਕਲਿਕਹਾਊਸ ਵੀ ਇਸ ਮਾਮਲੇ 'ਚ ਸਭ ਤੋਂ ਅੱਗੇ ਹੈ।

ਮੈਂ ਜੋ ਕਿਹਾ ਉਸ ਤੋਂ ਕੀ ਸਿੱਟਾ ਕੱਢਿਆ ਜਾ ਸਕਦਾ ਹੈ?

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

ਓਪਨ ਸੋਰਸ - ਸਾਡੇ ਨਾਲ ਜੁੜੋ!

ਜਿਵੇਂ ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਹੈ, ਓਪਰੇਟਰ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਓਪਨ ਸੋਰਸ ਉਤਪਾਦ ਹੈ, ਇਸ ਲਈ ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੋਵੇਗਾ ਜੇਕਰ ਵੱਧ ਤੋਂ ਵੱਧ ਲੋਕ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ. ਸਾਡੇ ਨਾਲ ਸ਼ਾਮਲ! ਅਸੀਂ ਤੁਹਾਡੇ ਸਾਰਿਆਂ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਾਂ!

ਤੁਹਾਡਾ ਧੰਨਵਾਦ!

ਤੁਹਾਡੇ ਸਵਾਲ

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

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

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

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

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

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

ਮੇਰਾ ਇਸ ਨਾਲ ਜੁੜਿਆ ਇੱਕ ਦੂਜਾ ਸਵਾਲ ਹੈ। ਕੁਬਰਨੇਟਸ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਸੀ ਕਿ ਸਾਡੇ ਲਈ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਅਸੀਂ ਨੋਡ ਗੁਆਉਂਦੇ ਹਾਂ ਜਾਂ ਨਹੀਂ। ਸਾਨੂੰ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੇਕਰ ਅਸੀਂ ਨੋਡ ਗੁਆ ਚੁੱਕੇ ਹਾਂ ਜਿੱਥੇ ਸਾਡਾ ਸ਼ਾਰਡ ਲਟਕਦਾ ਹੈ?

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

ਹੁਣ ਇੱਕ ਵਿਹਾਰਕ ਸਵਾਲ ਲਈ. ਕੀ ਕਰਨਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਨੋਡ ਗੁਆ ਦਿੱਤਾ ਹੈ ਜਿਸ 'ਤੇ ਡਿਸਕ ਸੀ? ਇੱਥੇ ਉੱਚ ਪੱਧਰ 'ਤੇ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਕਲਿਕਹਾਊਸ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਹਨ ਜੋ ਉੱਚ ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਯਾਨੀ. ਕਲਿਕਹਾਊਸ ਪੱਧਰ 'ਤੇ।

ਨਤੀਜਾ ਸੁਭਾਅ ਕੀ ਹੈ? DevOps ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਕਿ ਡੇਟਾ ਗੁੰਮ ਨਾ ਹੋਵੇ। ਉਸਨੂੰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਸਥਾਪਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਚੱਲ ਰਹੀ ਹੈ। ਕਲਿਕਹਾਊਸ ਪੱਧਰ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿੱਚ ਡੁਪਲੀਕੇਟ ਡੇਟਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਉਹ ਕੰਮ ਨਹੀਂ ਹੈ ਜੋ ਆਪਰੇਟਰ ਹੱਲ ਕਰਦਾ ਹੈ। ਅਤੇ ਉਹ ਸਮੱਸਿਆ ਨਹੀਂ ਜੋ ਕੁਬਰਨੇਟਸ ਖੁਦ ਹੱਲ ਕਰਦਾ ਹੈ. ਇਹ ਕਲਿਕਹਾਊਸ ਪੱਧਰ 'ਤੇ ਹੈ।

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

ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਜਦੋਂ ਹਰ ਤਰ੍ਹਾਂ ਦੀਆਂ ਭੈੜੀਆਂ ਚੀਜ਼ਾਂ ਵਾਪਰਦੀਆਂ ਹਨ, ਓਪਰੇਟਰ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮੁੜ ਚਾਲੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਸ ਸਮੇਂ ਘਟਨਾਵਾਂ ਆਉਂਦੀਆਂ ਹਨ, ਕੀ ਤੁਸੀਂ ਇਸ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਸੰਭਾਲਦੇ ਹੋ?

ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਓਪਰੇਟਰ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮੁੜ ਚਾਲੂ ਹੁੰਦਾ ਹੈ, ਠੀਕ ਹੈ?

ਹਾਂ। ਅਤੇ ਉਸੇ ਸਮੇਂ ਘਟਨਾਵਾਂ ਆ ਗਈਆਂ.

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

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

ਕੀ ਤੁਸੀਂ ਇੰਦਰਾਜ਼ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹੋ?

ਹਾਂ, Ingress ਨੂੰ haproxy ਨਾਲ ਬਦਲੋ। ਹੈਪਰੋਕਸੀ ਵਿੱਚ ਤੁਸੀਂ ਕਲੱਸਟਰ ਦੀ ਟੌਪੋਲੋਜੀ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ ਜਿੱਥੇ ਇਸਦੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ।

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

ਪਹਿਲਾਂ ਹੀ ਹੈ।

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

ਸਰੋਤ: www.habr.com