ਕਨਵੇਅਰ ਤੋਂ ਕੰਟੇਨਰ: CRI-O ਹੁਣ ਓਪਨਸ਼ਿਫਟ ਕੰਟੇਨਰ ਪਲੇਟਫਾਰਮ 4 ਵਿੱਚ ਡਿਫੌਲਟ ਹੈ

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

ਸਪੱਸ਼ਟ ਹੱਲ Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux ਦਾ ਇੱਕ ਰੂਪ) ਅਤੇ CRI-O ਨੂੰ ਸਟੈਂਡਰਡ ਵਜੋਂ ਵਰਤਣਾ ਸੀ, ਅਤੇ ਇੱਥੇ ਕਿਉਂ ਹੈ...

ਕਿਉਂਕਿ ਕੁਬਰਨੇਟਸ ਅਤੇ ਕੰਟੇਨਰਾਂ ਦੇ ਕੰਮ ਦੀ ਵਿਆਖਿਆ ਕਰਦੇ ਸਮੇਂ ਸਮੁੰਦਰੀ ਸਫ਼ਰ ਦਾ ਵਿਸ਼ਾ ਸਮਾਨਤਾਵਾਂ ਲੱਭਣ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਆਓ ਇੱਕ ਉਦਾਹਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, CoreOS ਅਤੇ CRI-O ਹੱਲ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰੋਬਾਰੀ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ। ਰਿਗਿੰਗ ਬਲਾਕਾਂ ਦੇ ਉਤਪਾਦਨ ਲਈ ਬਰੂਨਲ ਦੀਆਂ ਕਾਢਾਂ. 1803 ਵਿੱਚ, ਮਾਰਕ ਬਰੂਨਲ ਨੂੰ ਵਧ ਰਹੀ ਬ੍ਰਿਟਿਸ਼ ਜਲ ਸੈਨਾ ਦੀਆਂ ਲੋੜਾਂ ਲਈ 100 ਰਿਗਿੰਗ ਬਲਾਕ ਬਣਾਉਣ ਦਾ ਕੰਮ ਸੌਂਪਿਆ ਗਿਆ ਸੀ। ਇੱਕ ਰਿਗਿੰਗ ਬਲਾਕ ਇੱਕ ਕਿਸਮ ਦੀ ਹੇਰਾਫੇਰੀ ਹੈ ਜੋ ਰੱਸੀਆਂ ਨੂੰ ਸਮੁੰਦਰੀ ਜਹਾਜ਼ਾਂ ਨਾਲ ਜੋੜਨ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। 19ਵੀਂ ਸਦੀ ਦੀ ਸ਼ੁਰੂਆਤ ਤੱਕ, ਇਹ ਬਲਾਕ ਹੱਥਾਂ ਨਾਲ ਬਣਾਏ ਗਏ ਸਨ, ਪਰ ਬਰੂਨਲ ਨੇ ਉਤਪਾਦਨ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਹੇ ਅਤੇ ਮਸ਼ੀਨ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮਿਆਰੀ ਬਲਾਕ ਬਣਾਉਣੇ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੇ। ਇਸ ਪ੍ਰਕਿਰਿਆ ਦੇ ਆਟੋਮੇਸ਼ਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨਤੀਜੇ ਵਾਲੇ ਬਲਾਕ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਇੱਕੋ ਜਿਹੇ ਸਨ, ਟੁੱਟਣ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਬਦਲੇ ਜਾ ਸਕਦੇ ਸਨ, ਅਤੇ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਪੈਦਾ ਕੀਤੇ ਜਾ ਸਕਦੇ ਸਨ।

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

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

OpenShift 4 ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਬਣਾਇਆ ਗਿਆ ਸੀ ਕਿ ਸਾਰੇ ਪ੍ਰਮੁੱਖ ਕਲਾਉਡ ਕੰਪਿਊਟਿੰਗ ਪ੍ਰਦਾਤਾਵਾਂ, ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਪਲੇਟਫਾਰਮਾਂ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਬੇਅਰ ਮੈਟਲ ਸਿਸਟਮਾਂ ਲਈ ਪਲੇਟਫਾਰਮ ਦੇ ਪੂਰੇ ਜੀਵਨ ਚੱਕਰ (ਵਰਜਨ 4.X ਲਈ) ਦੌਰਾਨ ਸਿਸਟਮ ਨੂੰ ਸੁਵਿਧਾਜਨਕ ਤੌਰ 'ਤੇ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾ ਸਕੇ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਪਰਿਵਰਤਨਯੋਗ ਤੱਤਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਨੋਡ ਬਣਾਏ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ. ਜਦੋਂ ਇੱਕ ਕਲੱਸਟਰ ਨੂੰ Kubernetes ਦੇ ਇੱਕ ਨਵੇਂ ਸੰਸਕਰਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ CoreOS 'ਤੇ CRI-O ਦਾ ਅਨੁਸਾਰੀ ਸੰਸਕਰਣ ਵੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ CRI-O ਸੰਸਕਰਣ ਕੁਬਰਨੇਟਸ ਨਾਲ ਸਿੱਧਾ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਇਹ ਟੈਸਟਿੰਗ, ਸਮੱਸਿਆ-ਨਿਪਟਾਰਾ, ਜਾਂ ਸਹਾਇਤਾ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ ਕਿਸੇ ਵੀ ਕ੍ਰਮ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਪਹੁੰਚ ਅੰਤਮ ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ Red Hat ਲਈ ਲਾਗਤਾਂ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ।

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

ਖੁੱਲੇ ਕੰਟੇਨਰਾਂ ਦੀ ਦੁਨੀਆ

ਸੰਸਾਰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਖੁੱਲ੍ਹੇ ਕੰਟੇਨਰਾਂ ਵੱਲ ਵਧ ਰਿਹਾ ਹੈ. ਭਾਵੇਂ ਕੁਬਰਨੇਟਸ ਵਿੱਚ, ਜਾਂ ਹੇਠਲੇ ਪੱਧਰ 'ਤੇ, ਕੰਟੇਨਰ ਦੇ ਮਿਆਰ ਦਾ ਵਿਕਾਸ ਹਰ ਪੱਧਰ 'ਤੇ ਨਵੀਨਤਾ ਦੇ ਇੱਕ ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਨਤੀਜੇ.

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

ਕੁਬਰਨੇਟਸ ਕਮਿਊਨਿਟੀ ਨੇ ਫਿਰ ਇੱਕ ਪਲੱਗੇਬਲ ਇੰਟਰਫੇਸ ਲਈ ਇੱਕ ਸਿੰਗਲ ਸਟੈਂਡਰਡ ਵਿਕਸਿਤ ਕੀਤਾ, ਜਿਸਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਇੰਟਰਫੇਸ (CRI). ਇਸਦਾ ਧੰਨਵਾਦ, ਕੁਬਰਨੇਟਸ ਉਪਭੋਗਤਾ ਡੌਕਰ ਤੋਂ ਇਲਾਵਾ ਕੰਟੇਨਰਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਵੱਖ-ਵੱਖ ਇੰਜਣਾਂ ਨੂੰ ਜੋੜਨ ਦੇ ਯੋਗ ਸਨ.

Red Hat ਅਤੇ Google ਦੇ ਇੰਜੀਨੀਅਰਾਂ ਨੇ ਇੱਕ ਕੰਟੇਨਰ ਇੰਜਣ ਦੀ ਮਾਰਕੀਟ ਲੋੜ ਦੇਖੀ ਜੋ CRI ਪ੍ਰੋਟੋਕੋਲ ਉੱਤੇ ਕੁਬੇਲੇਟ ਬੇਨਤੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕੇ ਅਤੇ ਕੰਟੇਨਰ ਪੇਸ਼ ਕੀਤੇ ਜੋ ਉੱਪਰ ਦੱਸੇ ਗਏ OCI ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਅਨੁਕੂਲ ਸਨ। ਇਸ ਲਈ OCID ਪ੍ਰਗਟ ਹੋਇਆ. ਪਰ ਮਾਫ ਕਰਨਾ, ਕੀ ਅਸੀਂ ਇਹ ਨਹੀਂ ਕਿਹਾ ਕਿ ਇਹ ਸਮੱਗਰੀ CRI-O ਨੂੰ ਸਮਰਪਿਤ ਹੋਵੇਗੀ? ਅਸਲ ਵਿੱਚ ਇਹ ਹੈ, ਸਿਰਫ ਰਿਲੀਜ਼ ਦੇ ਨਾਲ ਸੰਸਕਰਣ 1.0 ਪ੍ਰੋਜੈਕਟ ਦਾ ਨਾਮ CRI-O ਰੱਖਿਆ ਗਿਆ ਸੀ।

ਅੰਜੀਰ. 1.

CRI-O ਅਤੇ CoreOS ਨਾਲ ਨਵੀਨਤਾ

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

ਉਡੀਕ ਕਰੋ, ਇਹ ਕਿਵੇਂ ਹੈ?

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

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

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

ਚੱਲ ਰਹੇ ਕੰਟੇਨਰ

ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਓਪਨਸ਼ਿਫਟ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਟੈਕ ਪੂਰਵਦਰਸ਼ਨ ਸਥਿਤੀ ਵਿੱਚ ਸੰਸਕਰਣ 3.7 ਤੋਂ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਸਥਿਤੀ (ਵਰਤਮਾਨ ਵਿੱਚ ਸਮਰਥਿਤ) ਵਿੱਚ ਸੰਸਕਰਣ 3.9 ਤੋਂ CRI-O ਇੰਜਣ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਮੌਕਾ ਮਿਲਿਆ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, Red Hat ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਵਰਤਦਾ ਹੈ ਉਤਪਾਦਨ ਵਰਕਲੋਡ ਨੂੰ ਚਲਾਉਣ ਲਈ CRI-O ਵਰਜਨ 3.10 ਤੋਂ OpenShift ਔਨਲਾਈਨ ਵਿੱਚ। ਇਸ ਸਭ ਨੇ CRI-O 'ਤੇ ਕੰਮ ਕਰ ਰਹੀ ਟੀਮ ਨੂੰ ਵੱਡੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ 'ਤੇ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਲਾਂਚ ਕਰਨ ਦਾ ਵਿਆਪਕ ਅਨੁਭਵ ਹਾਸਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ। ਕੁਬਰਨੇਟਸ CRI-O ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਦਾ ਹੈ, ਇਸਦੀ ਮੁਢਲੀ ਸਮਝ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਆਓ ਹੇਠਾਂ ਦਿੱਤੇ ਦ੍ਰਿਸ਼ਟਾਂਤ ਨੂੰ ਵੇਖੀਏ, ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਆਰਕੀਟੈਕਚਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਚੌਲ. 2. ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਕੰਟੇਨਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ

CRI-O ਨਵੇਂ ਨੋਡਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵੇਲੇ, ਅਤੇ OpenShift ਪਲੇਟਫਾਰਮ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਨੂੰ ਜਾਰੀ ਕਰਨ ਵੇਲੇ ਪੂਰੇ ਸਿਖਰਲੇ ਪੱਧਰ ਨੂੰ ਸਮਕਾਲੀ ਕਰਕੇ ਨਵੇਂ ਕੰਟੇਨਰ ਹੋਸਟਾਂ ਦੀ ਰਚਨਾ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ। ਪੂਰੇ ਪਲੇਟਫਾਰਮ ਦਾ ਸੰਸ਼ੋਧਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਅੱਪਡੇਟਾਂ/ਰੋਲਬੈਕਸ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੰਟੇਨਰ ਟੇਲ ਕੋਰ, ਕੰਟੇਨਰ ਇੰਜਣ, ਨੋਡਸ (ਕੁਬੇਲੇਟਸ) ਅਤੇ ਕੁਬਰਨੇਟਸ ਮਾਸਟਰ ਨੋਡ ਵਿਚਕਾਰ ਨਿਰਭਰਤਾ ਵਿੱਚ ਰੁਕਾਵਟਾਂ ਨੂੰ ਵੀ ਰੋਕਦਾ ਹੈ। ਕੰਟਰੋਲ ਅਤੇ ਸੰਸਕਰਣ ਦੇ ਨਾਲ, ਸਾਰੇ ਪਲੇਟਫਾਰਮ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਕੇਂਦਰੀ ਤੌਰ 'ਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਨਾਲ, ਸਟੇਟ A ਤੋਂ ਸਟੇਟ B ਤੱਕ ਹਮੇਸ਼ਾ ਇੱਕ ਸਪਸ਼ਟ ਮਾਰਗ ਹੁੰਦਾ ਹੈ। ਇਹ ਅਪਡੇਟ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ, ਸੁਰੱਖਿਆ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ, ਪ੍ਰਦਰਸ਼ਨ ਰਿਪੋਰਟਿੰਗ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਦੇ ਅੱਪਡੇਟ ਅਤੇ ਸਥਾਪਨਾ ਦੀ ਲਾਗਤ ਨੂੰ ਘਟਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। .

ਬਦਲਣ ਵਾਲੇ ਤੱਤਾਂ ਦੀ ਸ਼ਕਤੀ ਦਾ ਪ੍ਰਦਰਸ਼ਨ

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

ਪਹਿਲਾਂ, ਆਓ ਉਹ ਬਣਾਓ ਜਿਸਨੂੰ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਕੌਂਫਿਗਰੇਸ਼ਨ ਕਿਹਾ ਜਾਂਦਾ ਹੈ - ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਕੌਂਫਿਗਰੇਸ਼ਨ। ਇਸ ਨੂੰ ਕੁਬਰਨੇਟਸ ਸਰੋਤ ਵਜੋਂ ਸੋਚੋ ਜੋ CRI-O ਲਈ ਸੰਰਚਨਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ, ਇਹ MachineConfig ਨਾਮਕ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸੰਸਕਰਣ ਹੈ, ਜੋ ਕਿ ਕੋਈ ਵੀ ਸੰਰਚਨਾ ਹੈ ਜੋ ਇੱਕ ਓਪਨਸ਼ਿਫਟ ਕਲੱਸਟਰ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਇੱਕ RHEL CoreOS ਮਸ਼ੀਨ ਵਿੱਚ ਤੈਨਾਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਇਹ ਕਸਟਮ ਸਰੋਤ, ਜਿਸਨੂੰ ContainerRuntimeConfig ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਨੂੰ ਕਲੱਸਟਰ ਪ੍ਰਸ਼ਾਸਕਾਂ ਲਈ CRI-O ਕੌਂਫਿਗਰ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਇਹ ਟੂਲ ਇੰਨਾ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ ਕਿ ਇਹ MachineConfigPool ਸੈਟਿੰਗਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਸਿਰਫ਼ ਕੁਝ ਨੋਡਾਂ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ ਮਸ਼ੀਨਾਂ ਦੇ ਸਮੂਹ ਵਜੋਂ ਸੋਚੋ ਜੋ ਇੱਕੋ ਉਦੇਸ਼ ਦੀ ਪੂਰਤੀ ਕਰਦੀਆਂ ਹਨ।

ਆਖਰੀ ਦੋ ਲਾਈਨਾਂ ਵੱਲ ਧਿਆਨ ਦਿਓ ਜੋ ਅਸੀਂ /etc/crio/crio.conf ਫਾਈਲ ਵਿੱਚ ਬਦਲਣ ਜਾ ਰਹੇ ਹਾਂ। ਇਹ ਦੋ ਲਾਈਨਾਂ crio.conf ਫਾਈਲ ਦੀਆਂ ਲਾਈਨਾਂ ਨਾਲ ਬਹੁਤ ਮਿਲਦੀਆਂ-ਜੁਲਦੀਆਂ ਹਨ, ਉਹ ਹਨ:

vi ContainerRuntimeConfig.yaml

ਸਿੱਟਾ:

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: set-log-and-pid
spec:
 machineConfigPoolSelector:
   matchLabels:
     debug-crio: config-log-and-pid
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug

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

oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig

ਸਿੱਟਾ:

NAME              AGE
set-log-and-pid   22h

ਇੱਕ ਵਾਰ ਜਦੋਂ ਅਸੀਂ ContainerRuntimeConfig ਬਣਾ ਲੈਂਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ Kubernetes ਨੂੰ ਸੰਕੇਤ ਦੇਣ ਲਈ MachineConfigPools ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਸੋਧਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਅਸੀਂ ਇਸ ਸੰਰਚਨਾ ਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚ ਮਸ਼ੀਨਾਂ ਦੇ ਇੱਕ ਖਾਸ ਸਮੂਹ 'ਤੇ ਲਾਗੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਅਸੀਂ ਮਾਸਟਰ ਨੋਡਾਂ ਲਈ MachineConfigPool ਨੂੰ ਬਦਲਾਂਗੇ:

oc edit MachineConfigPool/master

ਸਿੱਟਾ (ਸਪਸ਼ਟਤਾ ਲਈ, ਮੁੱਖ ਤੱਤ ਬਾਕੀ ਹੈ):

...
metadata:
 creationTimestamp: 2019-04-10T23:42:28Z
 generation: 1
 labels:
   debug-crio: config-log-and-pid
   operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...

ਇਸ ਸਮੇਂ, MCO ਕਲੱਸਟਰ ਲਈ ਇੱਕ ਨਵੀਂ crio.conf ਫਾਈਲ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੁਕੰਮਲ ਹੋਈ ਸੰਰਚਨਾ ਫਾਈਲ ਨੂੰ Kubernetes API ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਯਾਦ ਰੱਖੋ, ContainerRuntimeConfig MachineConfig ਦਾ ਸਿਰਫ਼ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸੰਸਕਰਣ ਹੈ, ਇਸਲਈ ਅਸੀਂ MachineConfigs ਵਿੱਚ ਸੰਬੰਧਿਤ ਲਾਈਨਾਂ ਨੂੰ ਦੇਖ ਕੇ ਨਤੀਜਾ ਦੇਖ ਸਕਦੇ ਹਾਂ:

oc get MachineConfigs | grep rendered

ਸਿੱਟਾ:

rendered-master-c923f24f01a0e38c77a05acfd631910b                  4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626                  4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62                  4.0.22-201904011459-dirty 2.2.0 16h

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

python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid

ਸਿੱਟਾ:

pids_limit = 2048

ਹੁਣ ਇਹ ਯਕੀਨੀ ਬਣਾਉ ਕਿ ਸੰਰਚਨਾ ਸਾਰੇ ਮਾਸਟਰ ਨੋਡਾਂ 'ਤੇ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ। ਪਹਿਲਾਂ ਸਾਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚ ਨੋਡਾਂ ਦੀ ਸੂਚੀ ਮਿਲਦੀ ਹੈ:

oc get node | grep master

Output:

ip-10-0-135-153.us-east-2.compute.internal   Ready master 23h v1.12.4+509916ce1

ip-10-0-154-0.us-east-2.compute.internal     Ready master 23h v1.12.4+509916ce1

ip-10-0-166-79.us-east-2.compute.internal    Ready master 23h v1.12.4+509916ce1

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

oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’

ਸਿੱਟਾ:

...
pids_limit = 2048
...
log_level = "debug"
...

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

ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਤਿੰਨ ਉਤਪਾਦਨ ਨੋਡਾਂ ਵਾਲੇ ਇੱਕ ਛੋਟੇ ਓਪਨਸ਼ਿਫਟ ਕੰਟੇਨਰ ਪਲੇਟਫਾਰਮ 4 ਕਲੱਸਟਰ ਵਿੱਚ ਜਾਂ 3000 ਨੋਡਾਂ ਵਾਲੇ ਇੱਕ ਵਿਸ਼ਾਲ ਉਤਪਾਦਨ ਕਲੱਸਟਰ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ। ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ, ਕੰਮ ਦੀ ਮਾਤਰਾ ਇੱਕੋ ਜਿਹੀ ਹੋਵੇਗੀ - ਅਤੇ ਬਹੁਤ ਘੱਟ - ਸਿਰਫ਼ ContainerRuntimeConfig ਫਾਈਲ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ, ਅਤੇ MachineConfigPool ਵਿੱਚ ਇੱਕ ਲੇਬਲ ਬਦਲੋ। ਅਤੇ ਤੁਸੀਂ ਇਹ ਓਪਨਸ਼ਿਫਟ ਕੰਟੇਨਰ ਪਲੇਟਫਾਰਮ 4.X ਦੇ ਕਿਸੇ ਵੀ ਸੰਸਕਰਣ ਦੇ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਕੁਬਰਨੇਟਸ ਨੂੰ ਇਸਦੇ ਪੂਰੇ ਜੀਵਨ ਚੱਕਰ ਵਿੱਚ ਚਲਾ ਰਿਹਾ ਹੈ।

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

ਸਰੋਤ: www.habr.com