ਮੇਰਾ ਨਾਮ ਵਿਕਟਰ ਯਾਗੋਫਾਰੋਵ ਹੈ, ਅਤੇ ਮੈਂ ਓਪਸ (ਓਪਰੇਸ਼ਨ) ਟੀਮ ਵਿੱਚ ਇੱਕ ਤਕਨੀਕੀ ਵਿਕਾਸ ਪ੍ਰਬੰਧਕ ਵਜੋਂ DomClick ਵਿਖੇ Kubernetes ਪਲੇਟਫਾਰਮ ਦਾ ਵਿਕਾਸ ਕਰ ਰਿਹਾ/ਰਹੀ ਹਾਂ। ਮੈਂ ਸਾਡੀਆਂ Dev <-> Ops ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਬਣਤਰ, ਰੂਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡੇ k8s ਕਲੱਸਟਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਚਲਾਉਣ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਅਤੇ ਨਾਲ ਹੀ DevOps/SRE ਅਭਿਆਸਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਚਾਹਾਂਗਾ ਜੋ ਸਾਡੀ ਟੀਮ ਲਾਗੂ ਕਰਦੀ ਹੈ।
ਓਪਸ ਟੀਮ
ਓਪਸ ਟੀਮ ਵਿੱਚ ਇਸ ਸਮੇਂ 15 ਲੋਕ ਹਨ। ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਤਿੰਨ ਦਫ਼ਤਰ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ, ਦੋ ਵੱਖਰੇ ਸਮਾਂ ਖੇਤਰ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਉਪਲਬਧ ਹਨ, ਰਾਤ ਨੂੰ ਵੀ ਸ਼ਾਮਲ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ, ਓਪਸ ਤੋਂ ਕੋਈ ਵਿਅਕਤੀ ਹਮੇਸ਼ਾਂ ਮਾਨੀਟਰ 'ਤੇ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਜਟਿਲਤਾ ਦੀ ਘਟਨਾ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਤਿਆਰ ਹੁੰਦਾ ਹੈ। ਸਾਡੇ ਕੋਲ ਰਾਤ ਦੀਆਂ ਸ਼ਿਫਟਾਂ ਨਹੀਂ ਹਨ, ਜੋ ਸਾਡੀ ਮਾਨਸਿਕਤਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਹਰ ਕਿਸੇ ਨੂੰ ਨਾ ਸਿਰਫ਼ ਕੰਪਿਊਟਰ 'ਤੇ ਕਾਫ਼ੀ ਨੀਂਦ ਲੈਣ ਅਤੇ ਵਿਹਲਾ ਸਮਾਂ ਬਿਤਾਉਣ ਦਾ ਮੌਕਾ ਦਿੰਦੀਆਂ ਹਨ।
ਹਰ ਕਿਸੇ ਕੋਲ ਵੱਖੋ ਵੱਖਰੀਆਂ ਯੋਗਤਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ: ਨੈੱਟਵਰਕਰ, DBAs, ELK ਸਟੈਕ ਮਾਹਰ, ਕੁਬਰਨੇਟਸ ਐਡਮਿਨ/ਡਿਵੈਲਪਰ, ਨਿਗਰਾਨੀ, ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ, ਹਾਰਡਵੇਅਰ ਮਾਹਰ, ਆਦਿ। ਇੱਕ ਚੀਜ਼ ਹਰ ਕਿਸੇ ਨੂੰ ਇੱਕਜੁੱਟ ਕਰਦੀ ਹੈ - ਹਰ ਕੋਈ ਸਾਡੇ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਕੁਝ ਹੱਦ ਤੱਕ ਬਦਲ ਸਕਦਾ ਹੈ: ਉਦਾਹਰਨ ਲਈ, k8s ਕਲੱਸਟਰ ਵਿੱਚ ਨਵੇਂ ਨੋਡ ਪੇਸ਼ ਕਰੋ, PostgreSQL ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ, ਇੱਕ CI/CD + Ansible ਪਾਈਪਲਾਈਨ ਲਿਖੋ, Python/Bash/Go ਵਿੱਚ ਕੁਝ ਸਵੈਚਾਲਿਤ ਕਰੋ, ਹਾਰਡਵੇਅਰ ਨੂੰ ਇਸ ਨਾਲ ਕਨੈਕਟ ਕਰੋ। ਡਾਟਾ ਸੈਂਟਰ। ਕਿਸੇ ਵੀ ਖੇਤਰ ਵਿੱਚ ਮਜ਼ਬੂਤ ਯੋਗਤਾਵਾਂ ਤੁਹਾਨੂੰ ਤੁਹਾਡੀ ਗਤੀਵਿਧੀ ਦੀ ਦਿਸ਼ਾ ਬਦਲਣ ਅਤੇ ਕਿਸੇ ਹੋਰ ਖੇਤਰ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਤੋਂ ਨਹੀਂ ਰੋਕਦੀਆਂ। ਉਦਾਹਰਨ ਲਈ, ਮੈਂ ਇੱਕ PostgreSQL ਮਾਹਰ ਵਜੋਂ ਇੱਕ ਕੰਪਨੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਇਆ, ਅਤੇ ਹੁਣ ਮੇਰੀ ਜ਼ਿੰਮੇਵਾਰੀ ਦਾ ਮੁੱਖ ਖੇਤਰ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਹੈ। ਟੀਮ ਵਿੱਚ, ਕਿਸੇ ਵੀ ਉਚਾਈ ਦਾ ਸਵਾਗਤ ਹੈ ਅਤੇ ਲੀਵਰ ਦੀ ਭਾਵਨਾ ਬਹੁਤ ਵਿਕਸਤ ਹੈ.
ਤਰੀਕੇ ਨਾਲ, ਅਸੀਂ ਸ਼ਿਕਾਰ ਕਰ ਰਹੇ ਹਾਂ. ਉਮੀਦਵਾਰਾਂ ਲਈ ਲੋੜਾਂ ਕਾਫ਼ੀ ਮਿਆਰੀ ਹਨ। ਮੇਰੇ ਲਈ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ, ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਇੱਕ ਵਿਅਕਤੀ ਟੀਮ ਵਿੱਚ ਫਿੱਟ ਹੋਵੇ, ਗੈਰ-ਵਿਰੋਧ ਹੈ, ਪਰ ਇਹ ਵੀ ਜਾਣਦਾ ਹੈ ਕਿ ਆਪਣੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਦਾ ਬਚਾਅ ਕਿਵੇਂ ਕਰਨਾ ਹੈ, ਵਿਕਾਸ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਨਵਾਂ ਕਰਨ ਤੋਂ ਡਰਦਾ ਨਹੀਂ, ਆਪਣੇ ਵਿਚਾਰ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਨਾਲ ਹੀ, ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮਿੰਗ ਹੁਨਰ, ਲੀਨਕਸ ਅਤੇ ਅੰਗਰੇਜ਼ੀ ਦੀਆਂ ਮੂਲ ਗੱਲਾਂ ਦਾ ਗਿਆਨ ਲੋੜੀਂਦਾ ਹੈ। ਅੰਗਰੇਜ਼ੀ ਦੀ ਲੋੜ ਸਿਰਫ਼ ਇਸ ਲਈ ਹੈ ਤਾਂ ਜੋ ਕੋਈ ਵਿਅਕਤੀ ਫੇਕੈਪ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਗੂਗਲ ਸਮੱਸਿਆ ਦਾ ਹੱਲ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਲੱਭ ਸਕੇ, ਨਾ ਕਿ 10 ਮਿੰਟਾਂ ਵਿੱਚ। ਲੀਨਕਸ ਦੇ ਡੂੰਘੇ ਗਿਆਨ ਵਾਲੇ ਮਾਹਰਾਂ ਨੂੰ ਲੱਭਣਾ ਹੁਣ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ: ਇਹ ਮਜ਼ਾਕੀਆ ਹੈ, ਪਰ ਤਿੰਨ ਵਿੱਚੋਂ ਦੋ ਉਮੀਦਵਾਰ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੇ ਹਨ "ਲੋਡ ਔਸਤ ਕੀ ਹੈ? ਇਹ ਕਿਸ ਚੀਜ਼ ਦਾ ਬਣਿਆ ਹੈ?", ਅਤੇ ਸਵਾਲ "ਇੱਕ C ਪ੍ਰੋਗਰਾਮ ਤੋਂ ਕੋਰ ਡੰਪ ਨੂੰ ਕਿਵੇਂ ਇਕੱਠਾ ਕਰਨਾ ਹੈ" ਨੂੰ ਸੁਪਰਮੈਨ... ਜਾਂ ਡਾਇਨਾਸੌਰਸ ਦੀ ਦੁਨੀਆ ਤੋਂ ਕੁਝ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਸਾਨੂੰ ਇਸ ਨੂੰ ਸਹਿਣਾ ਪਏਗਾ, ਕਿਉਂਕਿ ਆਮ ਤੌਰ 'ਤੇ ਲੋਕਾਂ ਨੇ ਹੋਰ ਯੋਗਤਾਵਾਂ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਕਸਤ ਕੀਤਾ ਹੈ, ਪਰ ਅਸੀਂ ਲੀਨਕਸ ਸਿਖਾਵਾਂਗੇ। ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ "ਇੱਕ DevOps ਇੰਜੀਨੀਅਰ ਨੂੰ ਬੱਦਲਾਂ ਦੀ ਆਧੁਨਿਕ ਦੁਨੀਆਂ ਵਿੱਚ ਇਹ ਸਭ ਜਾਣਨ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ" ਨੂੰ ਲੇਖ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਛੱਡਣਾ ਪਏਗਾ, ਪਰ ਤਿੰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਇਹ ਸਭ ਜ਼ਰੂਰੀ ਹੈ।
ਟੀਮ ਟੂਲ
ਟੂਲਜ਼ ਟੀਮ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੀ ਹੈ। ਉਹਨਾਂ ਦਾ ਮੁੱਖ ਕੰਮ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸੁਵਿਧਾਜਨਕ ਗ੍ਰਾਫਿਕਲ ਅਤੇ CLI ਟੂਲ ਬਣਾਉਣਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਸਾਡੀ ਅੰਦਰੂਨੀ ਵਿਕਾਸ ਕਾਨਫਰੰਸ ਤੁਹਾਨੂੰ ਕੁਬਰਨੇਟਸ ਲਈ ਸਿਰਫ਼ ਕੁਝ ਮਾਊਸ ਕਲਿੱਕਾਂ ਨਾਲ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਰੋਲ ਆਊਟ ਕਰਨ, ਇਸਦੇ ਸਰੋਤਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ, ਵਾਲਟ ਤੋਂ ਕੁੰਜੀਆਂ ਆਦਿ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਪਹਿਲਾਂ, ਜੇਨਕਿੰਸ + ਹੈਲਮ 2 ਸੀ, ਪਰ ਮੈਨੂੰ ਕਾਪੀ-ਪੇਸਟ ਨੂੰ ਖਤਮ ਕਰਨ ਅਤੇ ਸੌਫਟਵੇਅਰ ਜੀਵਨ ਚੱਕਰ ਵਿੱਚ ਇਕਸਾਰਤਾ ਲਿਆਉਣ ਲਈ ਆਪਣਾ ਖੁਦ ਦਾ ਟੂਲ ਵਿਕਸਿਤ ਕਰਨਾ ਪਿਆ।
ਓਪਸ ਟੀਮ ਡਿਵੈਲਪਰਾਂ ਲਈ ਪਾਈਪਲਾਈਨਾਂ ਨਹੀਂ ਲਿਖਦੀ, ਪਰ ਉਹਨਾਂ ਦੀ ਲਿਖਤ ਵਿੱਚ ਕਿਸੇ ਵੀ ਮੁੱਦੇ 'ਤੇ ਸਲਾਹ ਦੇ ਸਕਦੀ ਹੈ (ਕੁਝ ਲੋਕਾਂ ਕੋਲ ਅਜੇ ਵੀ ਹੈਲਮ 3 ਹੈ)।
DevOps
DevOps ਲਈ, ਅਸੀਂ ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੇਖਦੇ ਹਾਂ:
ਦੇਵ ਟੀਮਾਂ ਕੋਡ ਲਿਖਦੀਆਂ ਹਨ, ਇਸਨੂੰ Confer to dev -> qa/stage -> prod ਰਾਹੀਂ ਰੋਲ ਆਊਟ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕਿ ਕੋਡ ਹੌਲੀ ਨਾ ਹੋਵੇ ਅਤੇ ਇਸ ਵਿੱਚ ਤਰੁੱਟੀਆਂ ਨਾ ਹੋਣ ਦੇਵ ਅਤੇ ਓਪਸ ਟੀਮਾਂ ਦੀ ਹੈ। ਦਿਨ ਦੇ ਸਮੇਂ, ਓਪਸ ਟੀਮ ਤੋਂ ਡਿਊਟੀ 'ਤੇ ਮੌਜੂਦ ਵਿਅਕਤੀ ਨੂੰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਅਰਜ਼ੀ ਦੇ ਨਾਲ ਕਿਸੇ ਘਟਨਾ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸ਼ਾਮ ਨੂੰ ਅਤੇ ਰਾਤ ਨੂੰ, ਡਿਊਟੀ 'ਤੇ ਪ੍ਰਬੰਧਕ (ਓਪਸ) ਨੂੰ ਡਿਵੈਲਪਰ ਨੂੰ ਜਗਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜੇਕਰ ਉਹ ਜਾਣਦਾ ਹੈ. ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਮੱਸਿਆ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਨਹੀਂ ਹੈ। ਨਿਗਰਾਨੀ ਵਿੱਚ ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਚੇਤਾਵਨੀਆਂ ਆਪਣੇ ਆਪ ਜਾਂ ਅਰਧ-ਆਟੋਮੈਟਿਕ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।
ਓਪਸ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਦਾ ਖੇਤਰ ਉਸ ਪਲ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਦੇਵ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਉੱਥੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦੀ - ਅਸੀਂ ਉਹੀ ਕੰਮ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇੱਕੋ ਕਿਸ਼ਤੀ ਵਿੱਚ ਹਾਂ।
ਡਿਵੈਲਪਰ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਸਲਾਹ ਦਿੰਦੇ ਹਨ ਜੇਕਰ ਉਹਨਾਂ ਨੂੰ ਐਡਮਿਨ ਮਾਈਕ੍ਰੋਸਰਵਿਸ (ਉਦਾਹਰਨ ਲਈ, ਗੋ ਬੈਕਐਂਡ + HTML5) ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਪ੍ਰਸ਼ਾਸਕ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕਿਸੇ ਵੀ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਮੁੱਦਿਆਂ ਜਾਂ k8s ਨਾਲ ਸਬੰਧਤ ਮੁੱਦਿਆਂ 'ਤੇ ਸਲਾਹ ਦਿੰਦੇ ਹਨ।
ਤਰੀਕੇ ਨਾਲ, ਸਾਡੇ ਕੋਲ ਕੋਈ ਮੋਨੋਲਿਥ ਨਹੀਂ ਹੈ, ਸਿਰਫ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼. ਉਹਨਾਂ ਦੀ ਸੰਖਿਆ ਹੁਣ ਤੱਕ prod k900s ਕਲੱਸਟਰ ਵਿੱਚ 1000 ਅਤੇ 8 ਦੇ ਵਿਚਕਾਰ ਉਤਰਾਅ-ਚੜ੍ਹਾਅ ਹੁੰਦੀ ਹੈ, ਜੇਕਰ ਸੰਖਿਆ ਦੁਆਰਾ ਮਾਪੀ ਜਾਂਦੀ ਹੈ ਤੈਨਾਤੀ. ਫਲੀਆਂ ਦੀ ਗਿਣਤੀ 1700 ਅਤੇ 2000 ਦੇ ਵਿਚਕਾਰ ਉਤਰਾਅ-ਚੜ੍ਹਾਅ ਕਰਦੀ ਹੈ। ਇਸ ਸਮੇਂ ਉਤਪਾਦ ਕਲੱਸਟਰ ਵਿੱਚ ਲਗਭਗ 2000 ਪੌਡ ਹਨ।
ਮੈਂ ਸਹੀ ਸੰਖਿਆ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਕਿਉਂਕਿ ਅਸੀਂ ਬੇਲੋੜੀਆਂ ਮਾਈਕਰੋ ਸੇਵਾਵਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅਰਧ-ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਕੱਟਦੇ ਹਾਂ। K8s ਬੇਲੋੜੀਆਂ ਇਕਾਈਆਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕਰਦਾ ਹੈ , ਜਿਸ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਸਰੋਤ ਅਤੇ ਪੈਸੇ ਦੀ ਬਚਤ ਹੁੰਦੀ ਹੈ।
ਸਰੋਤ ਪ੍ਰਬੰਧਨ
ਨਿਗਰਾਨੀ
ਚੰਗੀ ਤਰ੍ਹਾਂ ਢਾਂਚਾਗਤ ਅਤੇ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਨਿਗਰਾਨੀ ਵੱਡੇ ਕਲੱਸਟਰ ਦੇ ਸੰਚਾਲਨ ਦਾ ਆਧਾਰ ਬਣ ਜਾਂਦੀ ਹੈ। ਸਾਨੂੰ ਅਜੇ ਤੱਕ ਇੱਕ ਵਿਆਪਕ ਹੱਲ ਨਹੀਂ ਲੱਭਿਆ ਹੈ ਜੋ ਸਾਰੀਆਂ ਨਿਗਰਾਨੀ ਲੋੜਾਂ ਦੇ 100% ਨੂੰ ਕਵਰ ਕਰੇਗਾ, ਇਸਲਈ ਅਸੀਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਇਸ ਵਾਤਾਵਰਣ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਕਸਟਮ ਹੱਲ ਬਣਾਉਂਦੇ ਹਾਂ।
- ਜ਼ੱਬਿਕਸ. ਚੰਗੀ ਪੁਰਾਣੀ ਨਿਗਰਾਨੀ, ਜਿਸਦਾ ਉਦੇਸ਼ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਸਮੁੱਚੀ ਸਥਿਤੀ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਹੈ। ਇਹ ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਜਦੋਂ ਕੋਈ ਨੋਡ ਪ੍ਰੋਸੈਸਿੰਗ, ਮੈਮੋਰੀ, ਡਿਸਕ, ਨੈੱਟਵਰਕ ਆਦਿ ਦੇ ਰੂਪ ਵਿੱਚ ਮਰ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਵੀ ਅਲੌਕਿਕ ਨਹੀਂ, ਪਰ ਸਾਡੇ ਕੋਲ ਏਜੰਟਾਂ ਦਾ ਇੱਕ ਵੱਖਰਾ ਡੈਮਨਸੈੱਟ ਵੀ ਹੈ, ਜਿਸ ਦੀ ਮਦਦ ਨਾਲ, ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਕਲੱਸਟਰ ਵਿੱਚ DNS ਦੀ ਸਥਿਤੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ: ਅਸੀਂ ਮੂਰਖ ਕੋਰਡਨ ਪੌਡਾਂ ਦੀ ਖੋਜ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਬਾਹਰੀ ਮੇਜ਼ਬਾਨਾਂ ਦੀ ਉਪਲਬਧਤਾ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ। ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਇਸ ਨਾਲ ਪਰੇਸ਼ਾਨ ਕਿਉਂ ਹੈ, ਪਰ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਆਵਾਜਾਈ ਦੇ ਨਾਲ ਇਹ ਭਾਗ ਅਸਫਲਤਾ ਦਾ ਇੱਕ ਗੰਭੀਰ ਬਿੰਦੂ ਹੈ. ਮੈਂ ਪਹਿਲਾਂ ਹੀ , ਮੈਂ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ DNS ਪ੍ਰਦਰਸ਼ਨ ਨਾਲ ਕਿਵੇਂ ਸੰਘਰਸ਼ ਕੀਤਾ।
- ਪ੍ਰੋਮੀਥੀਅਸ ਆਪਰੇਟਰ. ਵੱਖ-ਵੱਖ ਨਿਰਯਾਤਕਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਕਲੱਸਟਰ ਦੇ ਸਾਰੇ ਹਿੱਸਿਆਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਦਿੰਦਾ ਹੈ। ਅੱਗੇ, ਅਸੀਂ Grafana ਵਿੱਚ ਵੱਡੇ ਡੈਸ਼ਬੋਰਡਾਂ 'ਤੇ ਇਸ ਸਭ ਦੀ ਕਲਪਨਾ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਚੇਤਾਵਨੀਆਂ ਲਈ ਅਲਰਟਮੈਨੇਜਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।
ਸਾਡੇ ਲਈ ਇੱਕ ਹੋਰ ਉਪਯੋਗੀ ਸੰਦ ਸੀ . ਅਸੀਂ ਇਸਨੂੰ ਕਈ ਵਾਰ ਅਜਿਹੀ ਸਥਿਤੀ ਦਾ ਸਾਹਮਣਾ ਕਰਨ ਤੋਂ ਬਾਅਦ ਲਿਖਿਆ ਜਿੱਥੇ ਇੱਕ ਟੀਮ ਨੇ ਦੂਜੀ ਟੀਮ ਦੇ ਪ੍ਰਵੇਸ਼ ਮਾਰਗਾਂ ਨੂੰ ਓਵਰਲੈਪ ਕੀਤਾ, ਨਤੀਜੇ ਵਜੋਂ 50x ਗਲਤੀਆਂ ਹੋਈਆਂ। ਹੁਣ ਉਤਪਾਦਨ ਵਿੱਚ ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਡਿਵੈਲਪਰ ਇਹ ਜਾਂਚ ਕਰਦੇ ਹਨ ਕਿ ਕੋਈ ਵੀ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਮੇਰੀ ਟੀਮ ਲਈ ਇਹ ਇਨਗਰੇਸ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੇ ਸ਼ੁਰੂਆਤੀ ਨਿਦਾਨ ਲਈ ਇੱਕ ਵਧੀਆ ਸਾਧਨ ਹੈ। ਇਹ ਮਜ਼ਾਕੀਆ ਗੱਲ ਹੈ ਕਿ ਪਹਿਲਾਂ ਇਹ ਪ੍ਰਸ਼ਾਸਕਾਂ ਲਈ ਲਿਖਿਆ ਗਿਆ ਸੀ ਅਤੇ ਇਹ "ਅਢੁਕਵਾਂ" ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ, ਪਰ ਦੇਵ ਟੀਮਾਂ ਦੇ ਟੂਲ ਨਾਲ ਪਿਆਰ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇਹ ਬਹੁਤ ਬਦਲ ਗਿਆ ਅਤੇ ਅਜਿਹਾ ਨਹੀਂ ਦਿਖਣ ਲੱਗਾ ਜਿਵੇਂ "ਇੱਕ ਪ੍ਰਸ਼ਾਸਕ ਨੇ ਪ੍ਰਸ਼ਾਸਕਾਂ ਲਈ ਇੱਕ ਵੈੱਬ ਚਿਹਰਾ ਬਣਾਇਆ ਹੈ। " ਜਲਦੀ ਹੀ ਅਸੀਂ ਇਸ ਟੂਲ ਨੂੰ ਛੱਡ ਦੇਵਾਂਗੇ ਅਤੇ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਪਾਈਪਲਾਈਨ ਰੋਲ ਆਊਟ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਮਾਣਿਤ ਕੀਤਾ ਜਾਵੇਗਾ।
ਕਿਊਬ ਵਿੱਚ ਟੀਮ ਦੇ ਸਰੋਤ
ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਅਸੀਂ ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਮਝਾਉਣ ਦੇ ਯੋਗ ਹੈ ਕਿ ਅਸੀਂ ਸਰੋਤ ਕਿਵੇਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼.
ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਕਿਹੜੀਆਂ ਟੀਮਾਂ ਅਤੇ ਕਿਹੜੀਆਂ ਮਾਤਰਾਵਾਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਸਰੋਤ (ਪ੍ਰੋਸੈਸਰ, ਮੈਮੋਰੀ, ਸਥਾਨਕ SSD), ਅਸੀਂ ਹਰੇਕ ਕਮਾਂਡ ਨੂੰ ਆਪਣੀ ਖੁਦ ਦੀ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਨਾਮ ਜਗ੍ਹਾ "ਕਿਊਬ" ਵਿੱਚ ਅਤੇ ਪ੍ਰੋਸੈਸਰ, ਮੈਮੋਰੀ ਅਤੇ ਡਿਸਕ ਦੇ ਰੂਪ ਵਿੱਚ ਇਸਦੀਆਂ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਸੀਮਿਤ ਕਰੋ, ਪਹਿਲਾਂ ਟੀਮਾਂ ਦੀਆਂ ਲੋੜਾਂ ਬਾਰੇ ਚਰਚਾ ਕੀਤੀ ਗਈ ਸੀ। ਇਸ ਅਨੁਸਾਰ, ਇੱਕ ਕਮਾਂਡ, ਆਮ ਤੌਰ 'ਤੇ, ਹਜ਼ਾਰਾਂ ਕੋਰ ਅਤੇ ਟੈਰਾਬਾਈਟ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋਏ, ਤੈਨਾਤੀ ਲਈ ਪੂਰੇ ਕਲੱਸਟਰ ਨੂੰ ਨਹੀਂ ਰੋਕੇਗੀ। ਨੇਮਸਪੇਸ ਤੱਕ ਪਹੁੰਚ AD ਦੁਆਰਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ (ਅਸੀਂ RBAC ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ)। ਨੇਮਸਪੇਸ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਜੀਆਈਟੀ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਪੁੱਲ ਬੇਨਤੀ ਦੁਆਰਾ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਸਭ ਕੁਝ ਆਪਣੇ ਆਪ ਜਵਾਬੀ ਪਾਈਪਲਾਈਨ ਦੁਆਰਾ ਰੋਲ ਆਊਟ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਟੀਮ ਨੂੰ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਇੱਕ ਉਦਾਹਰਨ:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
ਬੇਨਤੀਆਂ ਅਤੇ ਸੀਮਾਵਾਂ
ਘਣ" ਬੇਨਤੀ ਲਈ ਗਾਰੰਟੀਸ਼ੁਦਾ ਰਾਖਵੇਂ ਸਰੋਤਾਂ ਦੀ ਸੰਖਿਆ ਹੈ ਪੌਡ (ਇੱਕ ਜਾਂ ਵਧੇਰੇ ਡੌਕਰ ਕੰਟੇਨਰ) ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ. ਸੀਮਾ ਇੱਕ ਗੈਰ-ਗਾਰੰਟੀਸ਼ੁਦਾ ਅਧਿਕਤਮ ਹੈ। ਤੁਸੀਂ ਅਕਸਰ ਗ੍ਰਾਫਾਂ 'ਤੇ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕਿਵੇਂ ਕੁਝ ਟੀਮ ਨੇ ਆਪਣੀਆਂ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਸੈਟ ਕੀਤੀਆਂ ਹਨ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ "ਕਿਊਬ" 'ਤੇ ਤਾਇਨਾਤ ਨਹੀਂ ਕਰ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਦੇ ਨਾਮ-ਸਥਾਨ ਦੇ ਅਧੀਨ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਪਹਿਲਾਂ ਹੀ "ਖਰਚ" ਗਈਆਂ ਹਨ।
ਇਸ ਸਥਿਤੀ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਸਹੀ ਤਰੀਕਾ ਅਸਲ ਸਰੋਤ ਖਪਤ ਨੂੰ ਵੇਖਣਾ ਅਤੇ ਬੇਨਤੀ ਕੀਤੀ ਰਕਮ (ਬੇਨਤੀ) ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ ਹੈ।
ਉੱਪਰ ਦਿੱਤੇ ਸਕ੍ਰੀਨਸ਼ੌਟਸ ਵਿੱਚ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ "ਬੇਨਤੀ ਕੀਤੇ" CPUs ਥਰਿੱਡਾਂ ਦੀ ਅਸਲ ਸੰਖਿਆ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਅਤੇ ਸੀਮਾਵਾਂ CPU ਥ੍ਰੈਡਾਂ ਦੀ ਅਸਲ ਸੰਖਿਆ ਤੋਂ ਵੱਧ ਸਕਦੀਆਂ ਹਨ =)
ਆਉ ਹੁਣ ਕੁਝ ਨੇਮਸਪੇਸ ਨੂੰ ਵਿਸਥਾਰ ਵਿੱਚ ਵੇਖੀਏ (ਮੈਂ ਨੇਮਸਪੇਸ ਕਿਊਬ-ਸਿਸਟਮ ਚੁਣਿਆ ਹੈ - "ਕਿਊਬ" ਦੇ ਭਾਗਾਂ ਲਈ ਸਿਸਟਮ ਨੇਮਸਪੇਸ) ਅਤੇ ਬੇਨਤੀ ਕੀਤੇ ਗਏ ਪ੍ਰੋਸੈਸਰ ਦੇ ਸਮੇਂ ਅਤੇ ਮੈਮੋਰੀ ਦਾ ਅਸਲ ਵਿੱਚ ਅਨੁਪਾਤ ਵੇਖੋ:
ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮੈਮੋਰੀ ਅਤੇ CPU ਸਿਸਟਮ ਸੇਵਾਵਾਂ ਲਈ ਰਾਖਵੀਂ ਹੈ। ਕਿਊਬ-ਸਿਸਟਮ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹ ਜਾਇਜ਼ ਹੈ: ਅਜਿਹਾ ਹੋਇਆ ਹੈ ਕਿ ਐਨਜੀਨੈਕਸ ਇਨਗਰੇਸ ਕੰਟਰੋਲਰ ਜਾਂ ਨੋਡੇਲੋਕਲਡਨਜ਼ ਨੇ ਆਪਣੇ ਸਿਖਰ 'ਤੇ ਸੀਪੀਯੂ ਨੂੰ ਮਾਰਿਆ ਅਤੇ ਬਹੁਤ ਸਾਰੀ ਰੈਮ ਦੀ ਖਪਤ ਕੀਤੀ, ਇਸ ਲਈ ਇੱਥੇ ਅਜਿਹਾ ਰਿਜ਼ਰਵ ਜਾਇਜ਼ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਪਿਛਲੇ 3 ਘੰਟਿਆਂ ਲਈ ਚਾਰਟ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ: ਸਮੇਂ ਦੀ ਇੱਕ ਵੱਡੀ ਮਿਆਦ ਵਿੱਚ ਇਤਿਹਾਸਕ ਮੈਟ੍ਰਿਕਸ ਦੇਖਣਾ ਫਾਇਦੇਮੰਦ ਹੈ।
"ਸਿਫ਼ਾਰਸ਼ਾਂ" ਦੀ ਇੱਕ ਪ੍ਰਣਾਲੀ ਵਿਕਸਿਤ ਕੀਤੀ ਗਈ ਸੀ। ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ "ਸੀਮਾਵਾਂ" (ਉੱਪਰੀ ਮਨਜ਼ੂਰ ਪੱਟੀ) ਨੂੰ ਵਧਾਉਣ ਲਈ ਕਿਹੜੇ ਸਰੋਤ ਬਿਹਤਰ ਹੋਣਗੇ ਤਾਂ ਜੋ "ਥਰੋਟਲਿੰਗ" ਨਾ ਹੋਵੇ: ਉਹ ਪਲ ਜਦੋਂ ਇੱਕ ਸਰੋਤ ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਤ ਸਮੇਂ ਦੇ ਟੁਕੜੇ ਵਿੱਚ CPU ਜਾਂ ਮੈਮੋਰੀ ਖਰਚ ਕਰ ਚੁੱਕਾ ਹੈ ਅਤੇ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ "ਅਨਫ੍ਰੀਜ਼" ਨਹੀਂ ਹੋ ਜਾਂਦਾ:
ਅਤੇ ਇੱਥੇ ਉਹ ਫਲੀਆਂ ਹਨ ਜੋ ਉਹਨਾਂ ਦੀ ਭੁੱਖ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ:
'ਤੇ ਥਰੋਟਲਿੰਗ + ਸਰੋਤ ਨਿਗਰਾਨੀ, ਤੁਸੀਂ ਇੱਕ ਤੋਂ ਵੱਧ ਲੇਖ ਲਿਖ ਸਕਦੇ ਹੋ, ਇਸ ਲਈ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਸਵਾਲ ਪੁੱਛੋ। ਕੁਝ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਮੈਂ ਕਹਿ ਸਕਦਾ ਹਾਂ ਕਿ ਅਜਿਹੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਦਾ ਕੰਮ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ ਅਤੇ "ਵਿੰਡੋ" ਫੰਕਸ਼ਨਾਂ ਅਤੇ "ਸੀਟੀਈ" ਪ੍ਰੋਮੀਥੀਅਸ / ਵਿਕਟੋਰੀਆ ਮੈਟ੍ਰਿਕਸ (ਇਹ ਸ਼ਬਦ ਕੋਟਸ ਵਿੱਚ ਹਨ, ਕਿਉਂਕਿ ਇੱਥੇ ਲਗਭਗ PromQL ਵਿੱਚ ਅਜਿਹਾ ਕੁਝ ਨਹੀਂ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਡਰਾਉਣੇ ਸਵਾਲਾਂ ਨੂੰ ਟੈਕਸਟ ਦੀਆਂ ਕਈ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚ ਵੰਡਣਾ ਪਵੇਗਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਹੋਵੇਗਾ).
ਨਤੀਜੇ ਵਜੋਂ, ਡਿਵੈਲਪਰ ਕੋਲ ਕਿਊਬ ਵਿੱਚ ਉਹਨਾਂ ਦੇ ਨਾਮ-ਸਥਾਨਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਟੂਲ ਹਨ, ਅਤੇ ਉਹ ਆਪਣੇ ਲਈ ਇਹ ਚੋਣ ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦੇ ਹਨ ਕਿ ਕਿੱਥੇ ਅਤੇ ਕਿਸ ਸਮੇਂ ਕਿਹੜੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਕੋਲ ਉਹਨਾਂ ਦੇ ਸਰੋਤ "ਕਟ" ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਸਰਵਰਾਂ ਨੂੰ ਸਾਰੀ ਰਾਤ ਪੂਰਾ CPU ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਵਿਧੀਆਂ
ਕੰਪਨੀ ਵਿੱਚ ਜਿਵੇਂ ਕਿ ਇਹ ਹੁਣ ਹੈ fashionable, ਅਸੀਂ DevOps- ਅਤੇ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਾਂ ਐਸ.ਆਰ.ਈ.- ਅਭਿਆਸੀ ਜਦੋਂ ਕਿਸੇ ਕੰਪਨੀ ਕੋਲ ਪੂਰੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ 1000 ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼, ਲਗਭਗ 350 ਡਿਵੈਲਪਰ ਅਤੇ 15 ਐਡਮਿਨ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ "ਫੈਸ਼ਨੇਬਲ" ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਇਹਨਾਂ ਸਾਰੇ "ਬੇਸਵਰਡਸ" ਦੇ ਪਿੱਛੇ ਹਰ ਚੀਜ਼ ਅਤੇ ਹਰ ਕਿਸੇ ਨੂੰ ਸਵੈਚਾਲਿਤ ਕਰਨ ਦੀ ਤੁਰੰਤ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਕੋਈ ਰੁਕਾਵਟ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ
ਓਪਸ ਵਜੋਂ, ਅਸੀਂ ਸੇਵਾ ਪ੍ਰਤੀਕਿਰਿਆ ਦਰਾਂ ਅਤੇ ਤਰੁੱਟੀਆਂ ਨਾਲ ਸਬੰਧਤ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ।
ਅਸੀਂ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ: , и ਉਹਨਾਂ ਨੂੰ ਇਕੱਠੇ ਜੋੜ ਕੇ। ਅਸੀਂ ਡੈਸ਼ਬੋਰਡਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਤਾਂ ਕਿ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਸਕੇ ਕਿ ਕਿਹੜੀ ਸੇਵਾ ਵਰਤਮਾਨ ਵਿੱਚ ਘਟੀਆ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰਤੀ ਸਕਿੰਟ ਪ੍ਰਤੀ ਜਵਾਬ ਕੋਡ, 99ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ ਦੁਆਰਾ ਜਵਾਬ ਸਮਾਂ), ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੋਰ। ਜਿਵੇਂ ਹੀ ਆਮ ਡੈਸ਼ਬੋਰਡਾਂ ਲਈ ਕੁਝ ਨਵੇਂ ਮੈਟ੍ਰਿਕਸ ਜ਼ਰੂਰੀ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਸੀਂ ਤੁਰੰਤ ਉਹਨਾਂ ਨੂੰ ਖਿੱਚਦੇ ਅਤੇ ਜੋੜਦੇ ਹਾਂ।
ਮੈਂ ਇੱਕ ਮਹੀਨੇ ਤੋਂ ਗ੍ਰਾਫ਼ ਨਹੀਂ ਖਿੱਚਿਆ ਹੈ। ਇਹ ਸ਼ਾਇਦ ਇੱਕ ਚੰਗਾ ਸੰਕੇਤ ਹੈ: ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ "ਚਾਹੁੰਦੇ" ਪਹਿਲਾਂ ਹੀ ਸਾਕਾਰ ਹੋ ਚੁੱਕੇ ਹਨ। ਅਜਿਹਾ ਹੋਇਆ ਕਿ ਹਫ਼ਤੇ ਦੇ ਦੌਰਾਨ ਮੈਂ ਦਿਨ ਵਿੱਚ ਘੱਟੋ ਘੱਟ ਇੱਕ ਵਾਰ ਕੁਝ ਨਵਾਂ ਗ੍ਰਾਫ ਖਿੱਚਾਂਗਾ.
ਨਤੀਜਾ ਨਤੀਜਾ ਕੀਮਤੀ ਹੈ ਕਿਉਂਕਿ ਹੁਣ ਡਿਵੈਲਪਰ ਬਹੁਤ ਘੱਟ ਹੀ ਸਵਾਲਾਂ ਦੇ ਨਾਲ ਪ੍ਰਸ਼ਾਸਕਾਂ ਕੋਲ ਜਾਂਦੇ ਹਨ "ਕਿਸੇ ਕਿਸਮ ਦੇ ਮੀਟ੍ਰਿਕ ਨੂੰ ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ."
ਲਾਗੂ ਕਰਨ ਸੇਵਾ ਜਾਲ ਬਿਲਕੁਲ ਕੋਨੇ ਦੇ ਆਸ ਪਾਸ ਹੈ ਅਤੇ ਹਰ ਕਿਸੇ ਲਈ ਜੀਵਨ ਨੂੰ ਬਹੁਤ ਸੌਖਾ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਟੂਲਸ ਦੇ ਸਹਿਯੋਗੀ ਪਹਿਲਾਂ ਤੋਂ ਹੀ "ਇੱਕ ਸਿਹਤਮੰਦ ਵਿਅਕਤੀ ਦਾ ਸਾਰ" ਲਾਗੂ ਕਰਨ ਦੇ ਨੇੜੇ ਹਨ: ਹਰੇਕ HTTP(s) ਬੇਨਤੀ ਦਾ ਜੀਵਨ ਚੱਕਰ ਨਿਗਰਾਨੀ ਵਿੱਚ ਦਿਖਾਈ ਦੇਵੇਗਾ, ਅਤੇ ਇਹ ਇੰਟਰ-ਸਰਵਿਸ (ਅਤੇ ਨਾ ਸਿਰਫ਼) ਆਪਸੀ ਤਾਲਮੇਲ ਦੌਰਾਨ "ਸਭ ਕੁਝ ਕਿਸ ਪੜਾਅ 'ਤੇ ਟੁੱਟ ਗਿਆ" ਨੂੰ ਸਮਝਣਾ ਹਮੇਸ਼ਾ ਸੰਭਵ ਹੋਵੇਗਾ। DomClick ਹੱਬ ਤੋਂ ਖਬਰਾਂ ਦੀ ਗਾਹਕੀ ਲਓ। =)
ਕੁਬਰਨੇਟਸ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸਮਰਥਨ
ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ, ਅਸੀਂ ਪੈਚ ਕੀਤੇ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਕੁਬੇਸਪ੍ਰੇ - ਕੁਬਰਨੇਟਸ ਨੂੰ ਤੈਨਾਤ ਕਰਨ, ਵਧਾਉਣ ਅਤੇ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਜਵਾਬਦੇਹ ਭੂਮਿਕਾ। ਕਿਸੇ ਸਮੇਂ, ਮੁੱਖ ਸ਼ਾਖਾ ਤੋਂ ਗੈਰ-ਕੁਬੀਡਮ ਸਥਾਪਨਾਵਾਂ ਲਈ ਸਮਰਥਨ ਕੱਟ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਅਤੇ kubeadm ਵਿੱਚ ਬਦਲਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਪ੍ਰਸਤਾਵ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਨਤੀਜੇ ਵਜੋਂ, ਸਾਊਥਬ੍ਰਿਜ ਕੰਪਨੀ ਨੇ ਆਪਣਾ ਫੋਰਕ ਬਣਾਇਆ (ਕੁਬੇਡਮ ਸਮਰਥਨ ਅਤੇ ਗੰਭੀਰ ਸਮੱਸਿਆਵਾਂ ਲਈ ਤੁਰੰਤ ਹੱਲ)।
ਸਾਰੇ k8s ਕਲੱਸਟਰਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:
- ਲਵੋ ਕੁਬੇਸਪ੍ਰੇ ਸਾਊਥਬ੍ਰਿਜ ਤੋਂ, ਸਾਡੇ ਥ੍ਰੈਡ, ਮਰਜਿਮ ਨਾਲ ਚੈੱਕ ਕਰੋ।
- ਅਸੀਂ ਅਪਡੇਟ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰ ਰਹੇ ਹਾਂ ਤਣਾਅ- "ਕਿਊਬ"।
- ਅਸੀਂ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਨੋਡ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹਾਂ (ਜਵਾਬ ਵਿੱਚ ਇਹ "ਸੀਰੀਅਲ: 1" ਹੈ) ਵਿੱਚ ਦੇਵ- "ਕਿਊਬ"।
- ਅਸੀਂ ਅਪਡੇਟ ਕਰਦੇ ਹਾਂ Prod ਸ਼ਨੀਵਾਰ ਸ਼ਾਮ ਨੂੰ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਨੋਡ.
ਭਵਿੱਖ ਵਿੱਚ ਇਸ ਨੂੰ ਬਦਲਣ ਦੀ ਯੋਜਨਾ ਹੈ ਕੁਬੇਸਪ੍ਰੇ ਕੁਝ ਤੇਜ਼ ਕਰਨ ਲਈ ਅਤੇ ਜਾਓ kubeadm.
ਕੁੱਲ ਮਿਲਾ ਕੇ ਸਾਡੇ ਕੋਲ ਤਿੰਨ "ਕਿਊਬਜ਼" ਹਨ: ਤਣਾਅ, ਦੇਵ ਅਤੇ ਉਤਪਾਦ। ਅਸੀਂ ਇੱਕ ਹੋਰ ਲਾਂਚ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ (ਗਰਮ ਸਟੈਂਡਬਾਏ) ਦੂਜੇ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਪ੍ਰੋਡ-“ਕਿਊਬ”। ਤਣਾਅ и ਦੇਵ "ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ" ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ (ਤਣਾਅ ਲਈ oVirt ਅਤੇ ਦੇਵ ਲਈ VMWare ਕਲਾਉਡ)। Prod- "ਕਿਊਬ" "ਬੇਅਰ ਮੈਟਲ" 'ਤੇ ਰਹਿੰਦਾ ਹੈ: ਇਹ 32 CPU ਥਰਿੱਡਾਂ, 64-128 GB ਮੈਮੋਰੀ ਅਤੇ 300 GB SSD RAID 10 ਦੇ ਨਾਲ ਇੱਕੋ ਜਿਹੇ ਨੋਡ ਹਨ - ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁੱਲ 50 ਹਨ। ਤਿੰਨ "ਪਤਲੇ" ਨੋਡ "ਮਾਸਟਰਾਂ" ਨੂੰ ਸਮਰਪਿਤ ਹਨ Prod- "ਕਿਊਬਾ": 16 GB ਮੈਮੋਰੀ, 12 CPU ਥ੍ਰੈਡ।
ਵਿਕਰੀ ਲਈ, ਅਸੀਂ "ਬੇਅਰ ਮੈਟਲ" ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਾਂ ਅਤੇ ਬੇਲੋੜੀਆਂ ਪਰਤਾਂ ਜਿਵੇਂ ਕਿ ਓਪਨਸਟੈਕ: ਸਾਨੂੰ "ਸ਼ੋਰ ਵਾਲੇ ਗੁਆਂਢੀਆਂ" ਅਤੇ CPU ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਸਮਾਂ ਚੋਰੀ. ਅਤੇ ਇਨ-ਹਾਊਸ ਓਪਨਸਟੈਕ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਪ੍ਰਸ਼ਾਸਨ ਦੀ ਗੁੰਝਲਤਾ ਲਗਭਗ ਦੁੱਗਣੀ ਹੋ ਜਾਂਦੀ ਹੈ।
CI/CD “ਕਿਊਬਿਕ” ਅਤੇ ਹੋਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਭਾਗਾਂ ਲਈ ਅਸੀਂ ਇੱਕ ਵੱਖਰੇ GIT ਸਰਵਰ, ਹੈਲਮ 3 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ (ਇਹ ਹੈਲਮ 2 ਤੋਂ ਇੱਕ ਬਹੁਤ ਹੀ ਦੁਖਦਾਈ ਤਬਦੀਲੀ ਸੀ, ਪਰ ਅਸੀਂ ਵਿਕਲਪਾਂ ਤੋਂ ਬਹੁਤ ਖੁਸ਼ ਹਾਂ। ਪ੍ਰਮਾਣੂ), ਜੇਨਕਿੰਸ, ਜਵਾਬਦੇਹ ਅਤੇ ਡੌਕਰ। ਸਾਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਖਾਵਾਂ ਅਤੇ ਇੱਕ ਭੰਡਾਰ ਤੋਂ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਤੈਨਾਤੀ ਪਸੰਦ ਹੈ।
ਸਿੱਟਾ
ਇਹ, ਆਮ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇੱਕ ਓਪਰੇਸ਼ਨ ਇੰਜੀਨੀਅਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ DomClick 'ਤੇ DevOps ਪ੍ਰਕਿਰਿਆ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ। ਲੇਖ ਮੇਰੀ ਉਮੀਦ ਨਾਲੋਂ ਘੱਟ ਤਕਨੀਕੀ ਨਿਕਲਿਆ: ਇਸ ਲਈ, ਹੈਬਰੇ 'ਤੇ ਡੋਮਕਲਿਕ ਖ਼ਬਰਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ: ਕੁਬਰਨੇਟਸ ਅਤੇ ਹੋਰ ਬਾਰੇ ਹੋਰ "ਹਾਰਡਕੋਰ" ਲੇਖ ਹੋਣਗੇ।
ਸਰੋਤ: www.habr.com