ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਟਿੰਡਰ ਤਬਦੀਲੀ

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਵਿਸ਼ਵ ਪ੍ਰਸਿੱਧ ਟਿੰਡਰ ਸੇਵਾ ਦੇ ਕਰਮਚਾਰੀਆਂ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਦੇ ਕੁਝ ਤਕਨੀਕੀ ਵੇਰਵੇ ਸਾਂਝੇ ਕੀਤੇ ਹਨ। ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਲਗਭਗ ਦੋ ਸਾਲ ਲੱਗ ਗਏ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ K8s 'ਤੇ ਇੱਕ ਬਹੁਤ ਵੱਡੇ ਪੱਧਰ ਦੇ ਪਲੇਟਫਾਰਮ ਦੀ ਸ਼ੁਰੂਆਤ ਹੋਈ, ਜਿਸ ਵਿੱਚ 200 ਹਜ਼ਾਰ ਕੰਟੇਨਰਾਂ 'ਤੇ ਹੋਸਟ ਕੀਤੀਆਂ 48 ਸੇਵਾਵਾਂ ਸ਼ਾਮਲ ਹਨ। ਟਿੰਡਰ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਕਿਹੜੀਆਂ ਦਿਲਚਸਪ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਅਤੇ ਉਹਨਾਂ ਦੇ ਕਿਹੜੇ ਨਤੀਜੇ ਆਏ? ਇਸ ਅਨੁਵਾਦ ਨੂੰ ਪੜ੍ਹੋ।

ਕਿਉਂ?

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

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

ਪ੍ਰਕਿਰਿਆ ਔਖੀ ਨਿਕਲੀ। 2019 ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਸਾਡੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੌਰਾਨ, ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨਾਜ਼ੁਕ ਪੁੰਜ ਤੱਕ ਪਹੁੰਚ ਗਿਆ ਅਤੇ ਸਾਨੂੰ ਟ੍ਰੈਫਿਕ ਵਾਲੀਅਮ, ਕਲੱਸਟਰ ਆਕਾਰ, ਅਤੇ DNS ਦੇ ਕਾਰਨ ਕਈ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ। ਰਸਤੇ ਦੇ ਨਾਲ, ਅਸੀਂ 200 ਸੇਵਾਵਾਂ ਨੂੰ ਮਾਈਗਰੇਟ ਕਰਨ ਅਤੇ 1000 ਨੋਡਸ, 15000 ਪੌਡਾਂ ਅਤੇ 48000 ਚੱਲ ਰਹੇ ਕੰਟੇਨਰਾਂ ਵਾਲੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਨਾਲ ਸਬੰਧਤ ਬਹੁਤ ਸਾਰੀਆਂ ਦਿਲਚਸਪ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ ਹੈ।

ਕਿਵੇਂ?

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

ਕੁਬਰਨੇਟਸ ਲਈ ਚਿੱਤਰ ਬਣਾਉਣਾ

ਸਾਡੇ ਕੋਲ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ 'ਤੇ ਚੱਲ ਰਹੀਆਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਲਈ 30 ਤੋਂ ਵੱਧ ਸਰੋਤ ਕੋਡ ਭੰਡਾਰ ਹਨ। ਇਹਨਾਂ ਰਿਪੋਜ਼ਟਰੀਆਂ ਵਿੱਚ ਕੋਡ ਵੱਖ-ਵੱਖ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, Node.js, Java, Scala, Go) ਇੱਕੋ ਭਾਸ਼ਾ ਲਈ ਮਲਟੀਪਲ ਰਨਟਾਈਮ ਵਾਤਾਵਰਨ ਦੇ ਨਾਲ।

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

ਚਿੱਤਰ 1-1. ਬਿਲਡਰ ਕੰਟੇਨਰ ਦੁਆਰਾ ਮਿਆਰੀ ਨਿਰਮਾਣ ਪ੍ਰਕਿਰਿਆ

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

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

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

ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ

ਕਲੱਸਟਰ ਆਕਾਰ ਪ੍ਰਬੰਧਨ

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

ਅੰਤ ਵਿੱਚ ਅਸੀਂ ਇਸ 'ਤੇ ਸੈਟਲ ਹੋ ਗਏ:

• m5.4x ਵੱਡਾ - ਨਿਗਰਾਨੀ ਲਈ (ਪ੍ਰੋਮੀਥੀਅਸ);
• c5.4x ਵੱਡਾ - Node.js ਵਰਕਲੋਡ (ਸਿੰਗਲ-ਥਰਿੱਡਡ ਵਰਕਲੋਡ) ਲਈ;
• c5.2x ਵੱਡਾ - ਜਾਵਾ ਅਤੇ ਗੋ (ਮਲਟੀਥ੍ਰੈਡਡ ਵਰਕਲੋਡ) ਲਈ;
• c5.4x ਵੱਡਾ - ਕੰਟਰੋਲ ਪੈਨਲ ਲਈ (3 ਨੋਡਸ)।

ਪਰਵਾਸ

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

ਇਹ ਅੰਤ ਬਿੰਦੂ DNS ਰਿਕਾਰਡਾਂ ਦੇ ਭਾਰ ਵਾਲੇ ਸੈੱਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਏ ਗਏ ਸਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਹਰੇਕ ਨਵੇਂ ELB ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ CNAME ਸਨ। ਬਦਲਣ ਲਈ, ਅਸੀਂ 0 ਦੇ ਭਾਰ ਦੇ ਨਾਲ ਕੁਬਰਨੇਟਸ ਸੇਵਾ ਦੇ ਨਵੇਂ ELB ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੀ ਇੱਕ ਨਵੀਂ ਐਂਟਰੀ ਜੋੜੀ। ਫਿਰ ਅਸੀਂ ਐਂਟਰੀ ਸੈੱਟ ਦੇ ਟਾਈਮ ਟੂ ਲਾਈਵ (TTL) ਨੂੰ 0 'ਤੇ ਸੈੱਟ ਕੀਤਾ। ਇਸ ਤੋਂ ਬਾਅਦ, ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਵਜ਼ਨ ਸਨ। ਹੌਲੀ-ਹੌਲੀ ਐਡਜਸਟ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਅੰਤ ਵਿੱਚ 100% ਲੋਡ ਇੱਕ ਨਵੇਂ ਸਰਵਰ ਨੂੰ ਭੇਜਿਆ ਗਿਆ। ਸਵਿਚਿੰਗ ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, TTL ਮੁੱਲ ਇੱਕ ਹੋਰ ਢੁਕਵੇਂ ਪੱਧਰ 'ਤੇ ਵਾਪਸ ਆ ਗਿਆ।

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

ਸਬਕ

ਨੈੱਟਵਰਕ ਫੈਬਰਿਕ ਦੀਆਂ ਸੀਮਾਵਾਂ

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

ਏਆਰਪੀ ਕੈਸ਼ ਨਾਲ ਸਬੰਧਤ ਤਿੰਨ ਲੀਨਕਸ ਵਿਕਲਪ ਹਨ:

(ਸਰੋਤ)

gc_thresh3 - ਇਹ ਇੱਕ ਸਖ਼ਤ ਸੀਮਾ ਹੈ। ਲੌਗ ਵਿੱਚ "ਗੁਆਂਢੀ ਟੇਬਲ ਓਵਰਫਲੋ" ਐਂਟਰੀਆਂ ਦੀ ਦਿੱਖ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਮਕਾਲੀ ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ (GC) ਤੋਂ ਬਾਅਦ ਵੀ, ਗੁਆਂਢੀ ਐਂਟਰੀ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ARP ਕੈਸ਼ ਵਿੱਚ ਲੋੜੀਂਦੀ ਥਾਂ ਨਹੀਂ ਸੀ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਕਰਨਲ ਨੇ ਪੈਕੇਟ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੱਦ ਕਰ ਦਿੱਤਾ ਹੈ।

ਅਸੀਂ ਵਰਤਦੇ ਹਾਂ ਫ਼ਲੈਨਾਲ Kubernetes ਵਿੱਚ ਇੱਕ ਨੈੱਟਵਰਕ ਫੈਬਰਿਕ ਦੇ ਰੂਪ ਵਿੱਚ. ਪੈਕੇਟ VXLAN ਉੱਤੇ ਪ੍ਰਸਾਰਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। VXLAN ਇੱਕ L2 ਸੁਰੰਗ ਹੈ ਜੋ ਇੱਕ L3 ਨੈੱਟਵਰਕ ਦੇ ਸਿਖਰ 'ਤੇ ਹੈ। ਤਕਨਾਲੋਜੀ MAC-in-UDP (MAC ਐਡਰੈੱਸ-ਇਨ-ਯੂਜ਼ਰ ਡੇਟਾਗ੍ਰਾਮ ਪ੍ਰੋਟੋਕੋਲ) ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਅਤੇ ਲੇਅਰ 2 ਨੈੱਟਵਰਕ ਹਿੱਸਿਆਂ ਦੇ ਵਿਸਤਾਰ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਭੌਤਿਕ ਡਾਟਾ ਸੈਂਟਰ ਨੈੱਟਵਰਕ 'ਤੇ ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ IP ਪਲੱਸ UDP ਹੈ।

ਚਿੱਤਰ 2-1। ਫਲੈਨਲ ਚਿੱਤਰ (ਸਰੋਤ)

ਚਿੱਤਰ 2-2. VXLAN ਪੈਕੇਜ (ਸਰੋਤ)

ਹਰੇਕ ਕੁਬਰਨੇਟਸ ਵਰਕਰ ਨੋਡ ਇੱਕ ਵੱਡੇ /24 ਬਲਾਕ ਤੋਂ /9 ਮਾਸਕ ਦੇ ਨਾਲ ਇੱਕ ਵਰਚੁਅਲ ਐਡਰੈੱਸ ਸਪੇਸ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਹਰੇਕ ਨੋਡ ਲਈ ਇਹ ਹੈ ਮਤਲਬ ਰੂਟਿੰਗ ਟੇਬਲ ਵਿੱਚ ਇੱਕ ਐਂਟਰੀ, ਏਆਰਪੀ ਟੇਬਲ ਵਿੱਚ ਇੱਕ ਐਂਟਰੀ (ਫਲਾਨੇਲ.1 ਇੰਟਰਫੇਸ ਉੱਤੇ), ਅਤੇ ਇੱਕ ਸਵਿਚਿੰਗ ਟੇਬਲ (FDB) ਵਿੱਚ ਇੱਕ ਐਂਟਰੀ। ਉਹਨਾਂ ਨੂੰ ਪਹਿਲੀ ਵਾਰ ਜਦੋਂ ਇੱਕ ਵਰਕਰ ਨੋਡ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਹਰ ਵਾਰ ਇੱਕ ਨਵਾਂ ਨੋਡ ਖੋਜਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ।

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

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

ਅਸਫਲਤਾ ਦੇ ਸਮੇਂ, ਕਲੱਸਟਰ ਵਿੱਚ 605 ਨੋਡ ਸਨ. ਉੱਪਰ ਦੱਸੇ ਕਾਰਨਾਂ ਕਰਕੇ, ਇਹ ਮਹੱਤਤਾ ਨੂੰ ਦੂਰ ਕਰਨ ਲਈ ਕਾਫੀ ਸੀ gc_thresh3, ਜੋ ਕਿ ਡਿਫਾਲਟ ਹੈ। ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਨਾ ਸਿਰਫ਼ ਪੈਕੇਟ ਛੱਡੇ ਜਾਣੇ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੇ ਹਨ, ਬਲਕਿ /24 ਮਾਸਕ ਵਾਲੀ ਪੂਰੀ ਫਲੈਨਲ ਵਰਚੁਅਲ ਐਡਰੈੱਸ ਸਪੇਸ ARP ਟੇਬਲ ਤੋਂ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ। ਨੋਡ-ਪੌਡ ਸੰਚਾਰ ਅਤੇ DNS ਸਵਾਲਾਂ ਵਿੱਚ ਵਿਘਨ ਪੈਂਦਾ ਹੈ (DNS ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਹੋਸਟ ਕੀਤਾ ਗਿਆ ਹੈ; ਵੇਰਵਿਆਂ ਲਈ ਇਸ ਲੇਖ ਵਿੱਚ ਬਾਅਦ ਵਿੱਚ ਪੜ੍ਹੋ)।

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਮੁੱਲ ਵਧਾਉਣ ਦੀ ਲੋੜ ਹੈ gc_thresh1, gc_thresh2 и gc_thresh3 ਅਤੇ ਗੁੰਮ ਹੋਏ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਮੁੜ-ਰਜਿਸਟਰ ਕਰਨ ਲਈ ਫਲੈਨਲ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ।

ਅਣਕਿਆਸੀ DNS ਸਕੇਲਿੰਗ

ਮਾਈਗ੍ਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦੌਰਾਨ, ਅਸੀਂ ਟ੍ਰੈਫਿਕ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਸਰਗਰਮੀ ਨਾਲ DNS ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਪੁਰਾਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਤੋਂ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸੇਵਾਵਾਂ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ। ਅਸੀਂ Route53 ਵਿੱਚ ਸੰਬੰਧਿਤ ਰਿਕਾਰਡਸੈਟਾਂ ਲਈ ਮੁਕਾਬਲਤਨ ਘੱਟ TTL ਮੁੱਲ ਸੈਟ ਕਰਦੇ ਹਾਂ। ਜਦੋਂ ਪੁਰਾਣਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ EC2 ਮੌਕਿਆਂ 'ਤੇ ਚੱਲ ਰਿਹਾ ਸੀ, ਤਾਂ ਸਾਡੇ ਰੈਜ਼ੋਲਵਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੇ ਐਮਾਜ਼ਾਨ DNS ਵੱਲ ਇਸ਼ਾਰਾ ਕੀਤਾ। ਅਸੀਂ ਇਸ ਨੂੰ ਮਾਮੂਲੀ ਸਮਝ ਲਿਆ ਅਤੇ ਸਾਡੀਆਂ ਸੇਵਾਵਾਂ ਅਤੇ ਐਮਾਜ਼ਾਨ ਸੇਵਾਵਾਂ (ਜਿਵੇਂ ਕਿ ਡਾਇਨਾਮੋਡੀਬੀ) 'ਤੇ ਘੱਟ ਟੀਟੀਐਲ ਦਾ ਪ੍ਰਭਾਵ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਕਿਸੇ ਦਾ ਧਿਆਨ ਨਹੀਂ ਗਿਆ।

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਸੇਵਾਵਾਂ ਨੂੰ Kubernetes ਵਿੱਚ ਮਾਈਗਰੇਟ ਕੀਤਾ, ਅਸੀਂ ਪਾਇਆ ਕਿ DNS ਪ੍ਰਤੀ ਸਕਿੰਟ 250 ਹਜ਼ਾਰ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਰਿਹਾ ਸੀ। ਨਤੀਜੇ ਵਜੋਂ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੇ DNS ਸਵਾਲਾਂ ਲਈ ਨਿਰੰਤਰ ਅਤੇ ਗੰਭੀਰ ਸਮਾਂ ਸਮਾਪਤ ਹੋਣ ਦਾ ਅਨੁਭਵ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਇਹ DNS ਪ੍ਰਦਾਤਾ ਨੂੰ CoreDNS (ਜੋ ਪੀਕ ਲੋਡ 'ਤੇ 1000 ਕੋਰਾਂ 'ਤੇ ਚੱਲ ਰਹੇ 120 ਪੌਡਾਂ 'ਤੇ ਪਹੁੰਚ ਗਿਆ) ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਅਤੇ ਸਵਿਚ ਕਰਨ ਦੀਆਂ ਸ਼ਾਨਦਾਰ ਕੋਸ਼ਿਸ਼ਾਂ ਦੇ ਬਾਵਜੂਦ ਹੋਇਆ ਹੈ।

ਹੋਰ ਸੰਭਵ ਕਾਰਨਾਂ ਅਤੇ ਹੱਲਾਂ ਦੀ ਖੋਜ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਖੋਜ ਕੀਤੀ ਲੇਖ, ਪੈਕੇਟ ਫਿਲਟਰਿੰਗ ਫਰੇਮਵਰਕ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੀਆਂ ਨਸਲੀ ਸਥਿਤੀਆਂ ਦਾ ਵਰਣਨ ਕਰਨਾ netfilter ਲੀਨਕਸ ਵਿੱਚ. ਟਾਈਮਆਉਟ ਜੋ ਅਸੀਂ ਦੇਖਿਆ, ਇੱਕ ਵਧ ਰਹੇ ਕਾਊਂਟਰ ਦੇ ਨਾਲ insert_failed ਫਲੈਨਲ ਇੰਟਰਫੇਸ ਵਿੱਚ ਲੇਖ ਦੀਆਂ ਖੋਜਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਸੀ।

ਸਮੱਸਿਆ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਨੈੱਟਵਰਕ ਐਡਰੈੱਸ ਟ੍ਰਾਂਸਲੇਸ਼ਨ (SNAT ਅਤੇ DNAT) ਦੇ ਪੜਾਅ 'ਤੇ ਹੁੰਦੀ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸਾਰਣੀ ਵਿੱਚ ਐਂਟਰੀ ਹੁੰਦੀ ਹੈ। ਕੰਟਰੈਕ. ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਚਰਚਾ ਕੀਤੀ ਗਈ ਅਤੇ ਕਮਿਊਨਿਟੀ ਦੁਆਰਾ ਸੁਝਾਏ ਗਏ ਹੱਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ ਡੀਐਨਐਸ ਨੂੰ ਵਰਕਰ ਨੋਡ ਵਿੱਚ ਆਪਣੇ ਆਪ ਵਿੱਚ ਲਿਜਾਣਾ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ:

• SNAT ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਆਵਾਜਾਈ ਨੋਡ ਦੇ ਅੰਦਰ ਰਹਿੰਦੀ ਹੈ। ਇਸ ਨੂੰ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਰੂਟ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ eth0.
• DNAT ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਮੰਜ਼ਿਲ IP ਨੋਡ ਲਈ ਸਥਾਨਕ ਹੈ, ਅਤੇ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਬੇਤਰਤੀਬੇ ਤੌਰ 'ਤੇ ਚੁਣੀ ਗਈ ਪੌਡ ਨਹੀਂ ਹੈ। iptables.

ਅਸੀਂ ਇਸ ਪਹੁੰਚ ਨਾਲ ਜੁੜੇ ਰਹਿਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। CoreDNS ਨੂੰ Kubernetes ਵਿੱਚ ਇੱਕ ਡੈਮਨਸੈੱਟ ਵਜੋਂ ਤਾਇਨਾਤ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਅਸੀਂ ਇੱਕ ਸਥਾਨਕ ਨੋਡ DNS ਸਰਵਰ ਨੂੰ ਲਾਗੂ ਕੀਤਾ solve.conf ਇੱਕ ਝੰਡਾ ਸੈੱਟ ਕਰਕੇ ਹਰ ਇੱਕ ਪੌਡ --cluster-dns ਕਮਾਂਡਾਂ ਕੁਬੇਲੇਟ . ਇਹ ਹੱਲ DNS ਸਮਾਂ ਸਮਾਪਤੀ ਲਈ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਾਬਤ ਹੋਇਆ।

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

ਬਿਹਤਰ ਲੋਡ ਸੰਤੁਲਨ ਲਈ ਦੂਤ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

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

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

ਅਸੀਂ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਸ਼ੰਸਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਦੂਤ. ਮੌਜੂਦਾ ਸਥਿਤੀ ਨੇ ਸਾਨੂੰ ਇਸ ਨੂੰ ਬਹੁਤ ਹੀ ਸੀਮਤ ਤਰੀਕੇ ਨਾਲ ਤੈਨਾਤ ਕਰਨ ਅਤੇ ਤੁਰੰਤ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ। ਦੂਤ ਇੱਕ ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ, ਓਪਨ-ਸੋਰਸ, ਲੇਅਰ-XNUMX ਪ੍ਰੌਕਸੀ ਹੈ ਜੋ ਵੱਡੇ SOA ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹੈ। ਇਹ ਐਡਵਾਂਸ ਲੋਡ ਬੈਲੇਂਸਿੰਗ ਤਕਨੀਕਾਂ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਆਟੋਮੈਟਿਕ ਰੀਟ੍ਰੀਸ, ਸਰਕਟ ਬ੍ਰੇਕਰ, ਅਤੇ ਗਲੋਬਲ ਰੇਟ ਲਿਮਿਟਿੰਗ ਸ਼ਾਮਲ ਹਨ। (ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਇਸ ਲੇਖ Istio ਬਾਰੇ, ਜੋ ਕਿ ਰਾਜਦੂਤ 'ਤੇ ਅਧਾਰਤ ਹੈ।)

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

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

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

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

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

ਚਿੱਤਰ 3-1। ਦੂਤ ਵਿੱਚ ਤਬਦੀਲੀ ਦੌਰਾਨ ਇੱਕ ਸੇਵਾ ਦਾ CPU ਕਨਵਰਜੈਂਸ

ਅੰਤਮ ਨਤੀਜਾ

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

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

ਪਰਵਾਸ ਵਿੱਚ ਲਗਭਗ ਦੋ ਸਾਲ ਲੱਗ ਗਏ, ਪਰ ਅਸੀਂ ਇਸਨੂੰ ਮਾਰਚ 2019 ਵਿੱਚ ਪੂਰਾ ਕਰ ਲਿਆ। ਵਰਤਮਾਨ ਵਿੱਚ, ਟਿੰਡਰ ਪਲੇਟਫਾਰਮ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ 'ਤੇ ਚੱਲਦਾ ਹੈ ਜਿਸ ਵਿੱਚ 200 ਸੇਵਾਵਾਂ, 1000 ਨੋਡਸ, 15 ਪੌਡ ਅਤੇ 000 ਚੱਲ ਰਹੇ ਕੰਟੇਨਰ ਸ਼ਾਮਲ ਹਨ। ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਹੁਣ ਓਪਰੇਸ਼ਨ ਟੀਮਾਂ ਦਾ ਇਕਲੌਤਾ ਡੋਮੇਨ ਨਹੀਂ ਹੈ। ਸਾਡੇ ਸਾਰੇ ਇੰਜੀਨੀਅਰ ਇਸ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣ ਅਤੇ ਤੈਨਾਤ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ।

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

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਲੇਖਾਂ ਦੀ ਇੱਕ ਲੜੀ ਵੀ ਪੜ੍ਹੋ:

• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 1: ਈਬੇ ਤੋਂ 4200 ਹਾਰਥਸ ਅਤੇ ਟੈਸਮਾਸਟਰ".
• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 2: ਸਹਿਮਤੀ ਅਤੇ SAP".
• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 3: GitHub".
• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 4: SoundCloud (ਪ੍ਰੋਮੀਥੀਅਸ ਦੁਆਰਾ)".
• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 5: ਡਿਜੀਟਲ ਬੈਂਕ ਮੋਨਜ਼ੋ".
• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 6: ਬਲੇਬਲਾਕਾਰ".
• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 7: ਬਲੈਕਰੋਕ".
• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 8: ਇਸ ਨੇ".
• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 9: CERN ਅਤੇ 210 K8s ਕਲੱਸਟਰ".
• «ਉਤਪਾਦਨ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੀ ਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ। ਭਾਗ 10: Reddit".

ਸਰੋਤ: www.habr.com