GitLab.com ਨੂੰ Kubernetes ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨ ਦੇ ਇੱਕ ਸਾਲ ਤੋਂ ਸਾਡੀ ਖੋਜ

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਗਿਟਲੈਬ ਵਿਖੇ ਕੁਬਰਨੇਟਸ ਗੋਦ ਲੈਣ ਨੂੰ ਕੰਪਨੀ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲੇ ਦੋ ਮੁੱਖ ਕਾਰਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਹਾਲ ਹੀ ਵਿੱਚ, GitLab.com ਔਨਲਾਈਨ ਸੇਵਾ ਦਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਅਤੇ ਸਿਰਫ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ K8s ਵਿੱਚ ਇਸਦਾ ਪ੍ਰਵਾਸ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ, ਜੋ ਅਜੇ ਵੀ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ ਹੈ। ਅਸੀਂ ਇੱਕ GitLab SRE ਇੰਜੀਨੀਅਰ ਦੁਆਰਾ ਇੱਕ ਤਾਜ਼ਾ ਲੇਖ ਦਾ ਅਨੁਵਾਦ ਪੇਸ਼ ਕਰਦੇ ਹੋਏ ਖੁਸ਼ ਹਾਂ ਕਿ ਇਹ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਭਾਗ ਲੈਣ ਵਾਲੇ ਇੰਜੀਨੀਅਰ ਕੀ ਸਿੱਟੇ ਕੱਢਦੇ ਹਨ।

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

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

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

ਕੁਬਰਨੇਟਸ ਅਤੇ ਕਲਾਉਡ-ਨੇਟਿਵ GitLab ਲਈ ਪਹਿਲੇ ਕਦਮ

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

ਕਲਾਉਡ ਨੇਟਿਵ ਅਤੇ ਕੁਬਰਨੇਟਸ ਵੱਲ ਧੱਕਣ ਨੇ ਸਾਡੇ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਇੱਕ ਹੌਲੀ-ਹੌਲੀ ਤਬਦੀਲੀ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ, ਜਿਸ ਦੌਰਾਨ ਅਸੀਂ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਵਿਕਸਿਤ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹੋਏ ਨੈੱਟਵਰਕ ਸਟੋਰੇਜ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਕੁਝ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਛੱਡ ਦਿੱਤਾ। ਜਦੋਂ ਤੋਂ ਅਸੀਂ 2019 ਦੀਆਂ ਗਰਮੀਆਂ ਵਿੱਚ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਸ਼ੁਰੂ ਕੀਤੀ ਹੈ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ GitLab.com ਨੂੰ Kubernetes ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹੁਣ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚੱਲ ਰਹੀ ਹੈ!

ਕੁਬਰਨੇਟਸ ਵਿੱਚ GitLab.com ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

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

ਫਰੰਟਐਂਡ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹਨਾਂ ਕਿਸਮਾਂ ਨੂੰ ਵੈੱਬ, API, Git SSH/HTTPS ਅਤੇ ਰਜਿਸਟਰੀ ਲਈ ਬੇਨਤੀਆਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਬੈਕਐਂਡ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਅਸੀਂ ਵੱਖ-ਵੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਕਤਾਰ ਵਿੱਚ ਨੌਕਰੀਆਂ ਨੂੰ ਵੰਡਦੇ ਹਾਂ ਪੂਰਵ-ਪ੍ਰਭਾਸ਼ਿਤ ਸਰੋਤ ਸੀਮਾਵਾਂ, ਜੋ ਸਾਨੂੰ ਵੱਖ-ਵੱਖ ਵਰਕਲੋਡਾਂ ਲਈ ਸੇਵਾ-ਪੱਧਰ ਦੇ ਉਦੇਸ਼ (SLOs) ਸੈੱਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਇਹ ਸਾਰੀਆਂ GitLab.com ਸੇਵਾਵਾਂ ਨੂੰ ਇੱਕ ਅਣਸੋਧਿਆ GitLab ਹੈਲਮ ਚਾਰਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਬ-ਚਾਰਟ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨੂੰ ਚੋਣਵੇਂ ਤੌਰ 'ਤੇ ਸਮਰੱਥ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਅਸੀਂ ਹੌਲੀ-ਹੌਲੀ ਸੇਵਾਵਾਂ ਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰਦੇ ਹਾਂ। ਹਾਲਾਂਕਿ ਅਸੀਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਿੱਚ ਸਾਡੀਆਂ ਕੁਝ ਸਟੇਟਫੁੱਲ ਸੇਵਾਵਾਂ ਨੂੰ ਸ਼ਾਮਲ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਜਿਵੇਂ ਕਿ Redis, Postgres, GitLab Pages ਅਤੇ Gitaly, Kubernetes ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਸਾਨੂੰ ਸ਼ੈੱਫ ਵਰਤਮਾਨ ਵਿੱਚ ਪ੍ਰਬੰਧਿਤ ਕੀਤੇ ਗਏ VM ਦੀ ਸੰਖਿਆ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਘਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਕੁਬਰਨੇਟਸ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦ੍ਰਿਸ਼ਟੀ ਅਤੇ ਪ੍ਰਬੰਧਨ

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

ਹਾਲਾਂਕਿ Kubernetes ਕਲੱਸਟਰ ਲਈ ਸਾਡੀਆਂ ਪਾਈਪਲਾਈਨਾਂ ਇੱਕ ਵੱਖਰੀ GitLab ਸਥਾਪਨਾ 'ਤੇ ਚੱਲਦੀਆਂ ਹਨ, ਕੋਡ ਰਿਪੋਜ਼ਟਰੀਆਂ ਦੇ ਸ਼ੀਸ਼ੇ ਹਨ ਜੋ ਹੇਠਾਂ ਦਿੱਤੇ ਪਤਿਆਂ 'ਤੇ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹਨ:

• k8s-workloads/gitlab-com — GitLab ਹੈਲਮ ਚਾਰਟ ਲਈ GitLab.com ਸੰਰਚਨਾ ਫਰੇਮਵਰਕ;
• k8s-workloads/gitlab-helmfiles - ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਲਈ ਸੰਰਚਨਾਵਾਂ ਸ਼ਾਮਲ ਹਨ ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ GitLab ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਸੰਬੰਧਿਤ ਨਹੀਂ ਹਨ। ਇਹਨਾਂ ਵਿੱਚ ਲੌਗਿੰਗ ਅਤੇ ਕਲੱਸਟਰ ਨਿਗਰਾਨੀ ਲਈ ਸੰਰਚਨਾ ਸ਼ਾਮਲ ਹਨ, ਨਾਲ ਹੀ PlantUML ਵਰਗੇ ਏਕੀਕ੍ਰਿਤ ਟੂਲ;
• Gitlab-com-infrastructure — ਕੁਬਰਨੇਟਸ ਅਤੇ ਪੁਰਾਤਨ VM ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਟੈਰਾਫਾਰਮ ਕੌਂਫਿਗਰੇਸ਼ਨ। ਇੱਥੇ ਤੁਸੀਂ ਕਲੱਸਟਰ ਨੂੰ ਚਲਾਉਣ ਲਈ ਲੋੜੀਂਦੇ ਸਾਰੇ ਸਰੋਤਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰਦੇ ਹੋ, ਜਿਸ ਵਿੱਚ ਕਲੱਸਟਰ ਖੁਦ, ਨੋਡ ਪੂਲ, ਸੇਵਾ ਖਾਤੇ, ਅਤੇ IP ਐਡਰੈੱਸ ਰਿਜ਼ਰਵੇਸ਼ਨ ਸ਼ਾਮਲ ਹਨ।

ਜਦੋਂ ਤਬਦੀਲੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਜਨਤਕ ਦ੍ਰਿਸ਼ ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ। ਛੋਟਾ ਸੰਖੇਪ ਵਿਸਤ੍ਰਿਤ ਅੰਤਰ ਦੇ ਲਿੰਕ ਦੇ ਨਾਲ ਜੋ ਕਿ ਕਲੱਸਟਰ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ SRE ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ।

SRE ਲਈ, ਲਿੰਕ GitLab ਸਥਾਪਨਾ ਵਿੱਚ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਅੰਤਰ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਉਤਪਾਦਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜਿਸ ਤੱਕ ਪਹੁੰਚ ਸੀਮਿਤ ਹੈ। ਇਹ ਕਰਮਚਾਰੀਆਂ ਅਤੇ ਕਮਿਊਨਿਟੀ ਨੂੰ, ਸੰਚਾਲਨ ਪ੍ਰੋਜੈਕਟ (ਜੋ ਸਿਰਫ SREs ਲਈ ਖੁੱਲ੍ਹਾ ਹੈ) ਤੱਕ ਪਹੁੰਚ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਸਤਾਵਿਤ ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ ਨੂੰ ਦੇਖਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਕੋਡ ਲਈ ਇੱਕ ਜਨਤਕ GitLab ਉਦਾਹਰਨ ਨੂੰ CI ਪਾਈਪਲਾਈਨਾਂ ਲਈ ਇੱਕ ਨਿੱਜੀ ਉਦਾਹਰਣ ਦੇ ਨਾਲ ਜੋੜ ਕੇ, ਅਸੀਂ ਸੰਰਚਨਾ ਅੱਪਡੇਟ ਲਈ GitLab.com ਤੋਂ ਸੁਤੰਤਰਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋਏ ਇੱਕ ਸਿੰਗਲ ਵਰਕਫਲੋ ਬਣਾਈ ਰੱਖਦੇ ਹਾਂ।

ਪਰਵਾਸ ਦੌਰਾਨ ਸਾਨੂੰ ਕੀ ਪਤਾ ਲੱਗਾ

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

1. ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਦੇ ਵਿਚਕਾਰ ਆਵਾਜਾਈ ਦੇ ਕਾਰਨ ਵਧੀਆਂ ਲਾਗਤਾਂ

GitLab.com 'ਤੇ Git ਰਿਪੋਜ਼ਟਰੀ ਫਲੀਟ ਲਈ ਰੋਜ਼ਾਨਾ ਨਿਕਾਸੀ ਅੰਕੜੇ (ਬਾਈਟ ਪ੍ਰਤੀ ਦਿਨ)

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

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

2. ਸੀਮਾਵਾਂ, ਸਰੋਤ ਬੇਨਤੀਆਂ ਅਤੇ ਸਕੇਲਿੰਗ

registry.gitlab.com 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪ੍ਰੋਸੈਸਿੰਗ ਉਤਪਾਦਨ ਟ੍ਰੈਫਿਕ ਦੀ ਗਿਣਤੀ। ~15:00 UTC 'ਤੇ ਟਰੈਫ਼ਿਕ ਸਿਖਰ 'ਤੇ ਹੈ।

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

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

3. ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਲੌਗਸ

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਡਿਵੀਜ਼ਨ ਲੇਟੈਂਸੀ, ਗਲਤੀ ਦਰਾਂ ਅਤੇ ਇੰਸਟਾਲ ਦੇ ਨਾਲ ਸੰਤ੍ਰਿਪਤਾ 'ਤੇ ਕੇਂਦ੍ਰਤ ਕਰਦਾ ਹੈ ਸੇਵਾ ਪੱਧਰ ਦੇ ਟੀਚੇ (SLO) ਨਾਲ ਜੁੜਿਆ ਹੈ ਸਾਡੇ ਸਿਸਟਮ ਦੀ ਆਮ ਉਪਲਬਧਤਾ.

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

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

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

4. ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੱਕ ਨਵੇਂ ਕਲੱਸਟਰ ਵਿੱਚ ਬਦਲਣਾ

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

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

5. ਫਲੀਆਂ ਦੀ ਰਾਖਵੀਂ ਸਮਰੱਥਾ ਅਤੇ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ

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

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

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

ਸਿੱਟਾ

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

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

• «ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਵੱਲ ਕਿਉਂ ਜਾ ਰਹੇ ਹਾਂ?";
• «ਕੁਬਰਨੇਟਸ 'ਤੇ GitLab.com";
• GitLab.com ਨੂੰ Kubernetes ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰਨ ਬਾਰੇ ਐਪਿਕ.

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੇ ਨਾਲ 3 ਸਾਲ: ਇੱਥੇ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਸਮਝਦੇ ਹਾਂ";
• «ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ 10 ਆਮ ਗਲਤੀਆਂ";
• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 3: GitHub";
• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਟਿੰਡਰ ਤਬਦੀਲੀ".

ਸਰੋਤ: www.habr.com