ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਕਾਫਕਾ ਕਲੱਸਟਰ ਲਈ ਉਚਿਤ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰੋ

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

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

ਆਪਣੇ ਕਲੱਸਟਰ ਵਿੱਚ Supertubes ਅਜ਼ਮਾਓ:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

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

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

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

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

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

Supertubes ਉਪਭੋਗਤਾਵਾਂ ਲਈ, ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਹੇਠਾਂ ਦਿੱਤੀ ਪਹੁੰਚ ਅਪਣਾਉਂਦੇ ਹਾਂ: ਅਸੀਂ ਕੁਝ ਸੰਰਚਨਾ (ਬੁਨਿਆਦੀ ਢਾਂਚਾ + ਸੈਟਿੰਗਾਂ) ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ, ਫਿਰ ਇਸਦੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਮਾਪਦੇ ਹਾਂ, ਬ੍ਰੋਕਰ ਸੈਟਿੰਗਾਂ ਨੂੰ ਵਿਵਸਥਿਤ ਕਰਦੇ ਹਾਂ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦੁਬਾਰਾ ਦੁਹਰਾਉਂਦੇ ਹਾਂ। ਇਹ ਉਦੋਂ ਤੱਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਸਭ ਤੋਂ ਹੌਲੀ ਹਿੱਸੇ ਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।

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

ਇਹ ਲੇਖ ਉਹਨਾਂ ਕਦਮਾਂ ਬਾਰੇ ਗੱਲ ਕਰੇਗਾ ਜੋ ਅਸੀਂ ਸ਼ੁਰੂਆਤੀ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਹੌਲੀ ਭਾਗਾਂ ਤੋਂ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਲੈਂਦੇ ਹਾਂ ਅਤੇ ਕਾਫਕਾ ਕਲੱਸਟਰ ਦੇ ਥ੍ਰੁਪੁੱਟ ਨੂੰ ਮਾਪਦੇ ਹਾਂ। ਇੱਕ ਬਹੁਤ ਹੀ ਲਚਕਦਾਰ ਸੰਰਚਨਾ ਲਈ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਚੱਲ ਰਹੇ ਦਲਾਲਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (min.insync.replicas=3), ਤਿੰਨ ਵੱਖ-ਵੱਖ ਪਹੁੰਚਯੋਗਤਾ ਜ਼ੋਨਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ। ਕੁਬਰਨੇਟਸ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ, ਸਕੇਲ ਕਰਨ ਅਤੇ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ, ਅਸੀਂ ਹਾਈਬ੍ਰਿਡ ਕਲਾਉਡਸ ਲਈ ਆਪਣੇ ਖੁਦ ਦੇ ਕੰਟੇਨਰ ਪ੍ਰਬੰਧਨ ਪਲੇਟਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ - ਪਾਈਪਲਾਈਨ. ਇਹ ਆਨ-ਪ੍ਰੀਮਿਸ (ਬੇਅਰ ਮੈਟਲ, VMware) ਅਤੇ ਪੰਜ ਕਿਸਮਾਂ ਦੇ ਬੱਦਲਾਂ (ਅਲੀਬਾਬਾ, AWS, Azure, Google, Oracle) ਦੇ ਨਾਲ-ਨਾਲ ਉਹਨਾਂ ਦੇ ਕਿਸੇ ਵੀ ਸੁਮੇਲ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

ਕਾਫਕਾ ਕਲੱਸਟਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਅਤੇ ਸੰਰਚਨਾ ਬਾਰੇ ਵਿਚਾਰ

ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਉਦਾਹਰਨਾਂ ਲਈ, ਅਸੀਂ AWS ਨੂੰ ਕਲਾਊਡ ਪ੍ਰਦਾਤਾ ਵਜੋਂ ਅਤੇ EKS ਨੂੰ Kubernetes ਵੰਡ ਵਜੋਂ ਚੁਣਿਆ ਹੈ। ਇੱਕ ਸਮਾਨ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਪੀ.ਕੇ.ਈ. - ਬੰਜ਼ਾਈ ਕਲਾਉਡ ਤੋਂ ਕੁਬਰਨੇਟਸ ਦੀ ਵੰਡ, CNCF ਦੁਆਰਾ ਪ੍ਰਮਾਣਿਤ।

ਡ੍ਰਾਈਵ

ਐਮਾਜ਼ਾਨ ਵੱਖ-ਵੱਖ ਪੇਸ਼ਕਸ਼ਾਂ ਕਰਦਾ ਹੈ EBS ਵਾਲੀਅਮ ਕਿਸਮ. ਕੋਰ 'ਤੇ gpx NUMX и io1 ਹਾਲਾਂਕਿ, ਉੱਚ ਥ੍ਰੋਪੁੱਟ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ SSD ਡਰਾਈਵਾਂ ਹਨ gpx NUMX ਇਕੱਠੇ ਕੀਤੇ ਕ੍ਰੈਡਿਟ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ (I/O ਕ੍ਰੈਡਿਟ), ਇਸ ਲਈ ਅਸੀਂ ਕਿਸਮ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ io1, ਜੋ ਲਗਾਤਾਰ ਉੱਚ ਥ੍ਰੁਪੁੱਟ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ।

ਉਦਾਹਰਣ ਦੀਆਂ ਕਿਸਮਾਂ

ਕਾਫਕਾ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਪੇਜ ਕੈਸ਼ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਇਸਲਈ ਸਾਨੂੰ ਦਲਾਲਾਂ (JVM) ਅਤੇ ਪੇਜ ਕੈਸ਼ ਲਈ ਲੋੜੀਂਦੀ ਮੈਮੋਰੀ ਵਾਲੇ ਉਦਾਹਰਣਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਨ c5.2x ਵੱਡਾ - ਇੱਕ ਚੰਗੀ ਸ਼ੁਰੂਆਤ, ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ 16 GB ਦੀ ਮੈਮੋਰੀ ਹੈ ਅਤੇ EBS ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਅਨੁਕੂਲਿਤ. ਇਸਦਾ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਇਹ ਸਿਰਫ ਹਰ 30 ਘੰਟਿਆਂ ਵਿੱਚ 24 ਮਿੰਟਾਂ ਤੋਂ ਵੱਧ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੈ. ਜੇਕਰ ਤੁਹਾਡੇ ਕੰਮ ਦੇ ਬੋਝ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਿਖਰ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹੋਰ ਉਦਾਹਰਣ ਕਿਸਮਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹ ਸਕਦੇ ਹੋ। ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ਅਸੀਂ ਕੀਤਾ, ਰੁਕ ਕੇ c5.4x ਵੱਡਾ. ਇਹ ਵੱਧ ਤੋਂ ਵੱਧ ਥ੍ਰੁਪੁੱਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ 593,75 Mb/s. ਇੱਕ EBS ਵਾਲੀਅਮ ਦਾ ਅਧਿਕਤਮ ਥ੍ਰੋਪੁੱਟ io1 ਉਦਾਹਰਣ ਨਾਲੋਂ ਉੱਚਾ c5.4x ਵੱਡਾ, ਇਸ ਲਈ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਸਭ ਤੋਂ ਧੀਮਾ ਤੱਤ ਇਸ ਉਦਾਹਰਨ ਕਿਸਮ ਦਾ I/O ਥ੍ਰੁਪੁੱਟ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ (ਜਿਸਦੀ ਸਾਡੇ ਲੋਡ ਟੈਸਟਾਂ ਨੂੰ ਵੀ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ)।

ਨੈੱਟ

VM ਇੰਸਟੈਂਸ ਅਤੇ ਡਿਸਕ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੇ ਮੁਕਾਬਲੇ ਨੈੱਟਵਰਕ ਥ੍ਰਰੂਪੁਟ ਕਾਫ਼ੀ ਵੱਡਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਨੈੱਟਵਰਕ ਇੱਕ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦਾ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ c5.4x ਵੱਡਾ 10 Gb/s ਤੱਕ ਦੀ ਸਪੀਡ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ VM ਉਦਾਹਰਨ ਦੇ I/O ਥਰੂਪੁੱਟ ਨਾਲੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹੈ।

ਬ੍ਰੋਕਰ ਤੈਨਾਤੀ

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

ਜਾਵਾ ਸੰਸਕਰਣ

ਲਾਜ਼ੀਕਲ ਵਿਕਲਪ Java 11 ਹੈ ਕਿਉਂਕਿ ਇਹ ਡੌਕਰ ਨਾਲ ਇਸ ਅਰਥ ਵਿੱਚ ਅਨੁਕੂਲ ਹੈ ਕਿ JVM ਉਸ ਕੰਟੇਨਰ ਲਈ ਉਪਲਬਧ ਪ੍ਰੋਸੈਸਰਾਂ ਅਤੇ ਮੈਮੋਰੀ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਬ੍ਰੋਕਰ ਚੱਲ ਰਿਹਾ ਹੈ। ਇਹ ਜਾਣਦੇ ਹੋਏ ਕਿ CPU ਸੀਮਾਵਾਂ ਮਹੱਤਵਪੂਰਨ ਹਨ, JVM ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਅਤੇ ਪਾਰਦਰਸ਼ੀ ਤੌਰ 'ਤੇ GC ਥਰਿੱਡਾਂ ਅਤੇ JIT ਥ੍ਰੈੱਡਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਕਾਫਕਾ ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ banzaicloud/kafka:2.13-2.4.0, ਜਿਸ ਵਿੱਚ Java 2.4.0 'ਤੇ ਕਾਫਕਾ ਸੰਸਕਰਣ 2.13 (ਸਕਾਲਾ 11) ਸ਼ਾਮਲ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਕੁਬਰਨੇਟਸ 'ਤੇ Java/JVM ਬਾਰੇ ਹੋਰ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਾਡੀਆਂ ਹੇਠ ਲਿਖੀਆਂ ਪੋਸਟਾਂ ਦੇਖੋ:

• ਮੇਰੀ ਜਾਵਾ ਐਪਲੀਕੇਸ਼ਨ OOMKilled ਕਿਉਂ ਹੈ;
• Java 10 ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਕੰਟੇਨਰਾਂ ਦਾ ਸਹੀ ਆਕਾਰ ਕਿਵੇਂ ਕਰਨਾ ਹੈ.

ਬ੍ਰੋਕਰ ਮੈਮੋਰੀ ਸੈਟਿੰਗਜ਼

ਬ੍ਰੋਕਰ ਮੈਮੋਰੀ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੇ ਦੋ ਮੁੱਖ ਪਹਿਲੂ ਹਨ: ਜੇਵੀਐਮ ਲਈ ਸੈਟਿੰਗਾਂ ਅਤੇ ਕੁਬਰਨੇਟਸ ਪੌਡ ਲਈ। ਇੱਕ ਪੌਡ ਲਈ ਨਿਰਧਾਰਤ ਕੀਤੀ ਮੈਮੋਰੀ ਸੀਮਾ ਅਧਿਕਤਮ ਹੀਪ ਸਾਈਜ਼ ਤੋਂ ਵੱਧ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ JVM ਕੋਲ ਜਾਵਾ ਮੈਟਾਸਪੇਸ ਲਈ ਜਗ੍ਹਾ ਹੋਵੇ, ਜੋ ਕਿ ਇਸਦੀ ਆਪਣੀ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਪੇਜ ਕੈਸ਼ ਲਈ, ਜਿਸਨੂੰ ਕਾਫਕਾ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤਦਾ ਹੈ। ਸਾਡੇ ਟੈਸਟਾਂ ਵਿੱਚ ਅਸੀਂ ਮਾਪਦੰਡਾਂ ਦੇ ਨਾਲ ਕਾਫਕਾ ਬ੍ਰੋਕਰ ਲਾਂਚ ਕੀਤੇ -Xmx4G -Xms2G, ਅਤੇ ਪੌਡ ਲਈ ਮੈਮੋਰੀ ਸੀਮਾ ਸੀ 10 Gi. ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ JVM ਲਈ ਮੈਮੋਰੀ ਸੈਟਿੰਗਾਂ ਨੂੰ ਆਟੋਮੈਟਿਕਲੀ ਵਰਤ ਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ -XX:MaxRAMPercentage и -X:MinRAMPercentage, ਪੌਡ ਲਈ ਮੈਮੋਰੀ ਸੀਮਾ ਦੇ ਅਧਾਰ ਤੇ।

ਬ੍ਰੋਕਰ ਪ੍ਰੋਸੈਸਰ ਸੈਟਿੰਗਾਂ

ਆਮ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ ਕਾਫਕਾ ਦੁਆਰਾ ਵਰਤੇ ਗਏ ਥਰਿੱਡਾਂ ਦੀ ਗਿਣਤੀ ਵਧਾ ਕੇ ਸਮਾਨਤਾ ਨੂੰ ਵਧਾ ਕੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਸੁਧਾਰ ਸਕਦੇ ਹੋ। ਕਾਫਕਾ ਲਈ ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਪ੍ਰੋਸੈਸਰ ਉਪਲਬਧ ਹਨ, ਉੱਨਾ ਹੀ ਬਿਹਤਰ। ਸਾਡੇ ਟੈਸਟ ਵਿੱਚ, ਅਸੀਂ 6 ਪ੍ਰੋਸੈਸਰਾਂ ਦੀ ਸੀਮਾ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕੀਤੀ ਅਤੇ ਹੌਲੀ-ਹੌਲੀ (ਦੁਹਰਾਓ ਦੁਆਰਾ) ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਵਧਾ ਕੇ 15 ਕਰ ਦਿੱਤੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਸੈੱਟ num.network.threads=12 ਬ੍ਰੋਕਰ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਉਹਨਾਂ ਥਰਿੱਡਾਂ ਦੀ ਗਿਣਤੀ ਵਧਾਉਣ ਲਈ ਜੋ ਨੈੱਟਵਰਕ ਤੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਅਤੇ ਇਸਨੂੰ ਭੇਜਦੇ ਹਨ। ਤੁਰੰਤ ਖੋਜ ਕੀਤੀ ਕਿ ਅਨੁਯਾਈ ਦਲਾਲ ਕਾਫ਼ੀ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸਨ, ਉਨ੍ਹਾਂ ਨੇ ਉਠਾਇਆ num.replica.fetchers 4 ਤੱਕ ਉਸ ਗਤੀ ਨੂੰ ਵਧਾਉਣ ਲਈ ਜਿਸ 'ਤੇ ਪੈਰੋਕਾਰ ਦਲਾਲ ਨੇਤਾਵਾਂ ਦੇ ਸੰਦੇਸ਼ਾਂ ਦੀ ਨਕਲ ਕਰਦੇ ਹਨ।

ਜਨਰੇਸ਼ਨ ਟੂਲ ਲੋਡ ਕਰੋ

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

ਬੈਂਚਮਾਰਕਿੰਗ

ਪ੍ਰਦਰਸ਼ਨ ਮਾਪ ਇੱਕ ਦੁਹਰਾਓ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਸ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਪੜਾਅ ਸ਼ਾਮਲ ਹਨ:

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

ਅਗਲਾ ਭਾਗ ਉਹਨਾਂ ਕਦਮਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਟੈਸਟ ਕਲੱਸਟਰ ਬੈਂਚਮਾਰਕਿੰਗ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਕੀਤੇ ਗਏ ਸਨ।

ਸੰਦ

ਹੇਠਲੇ ਟੂਲਜ਼ ਦੀ ਵਰਤੋਂ ਇੱਕ ਬੇਸਲਾਈਨ ਸੰਰਚਨਾ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਤੈਨਾਤ ਕਰਨ, ਲੋਡ ਪੈਦਾ ਕਰਨ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਮਾਪਣ ਲਈ ਕੀਤੀ ਗਈ ਸੀ:

• ਬਨਜ਼ਾਈ ਕਲਾਉਡ ਪਾਈਪਲਾਈਨ ਐਮਾਜ਼ਾਨ c ਤੋਂ EKS ਕਲੱਸਟਰ ਦੇ ਆਯੋਜਨ ਲਈ Prometheus (ਕਾਫਕਾ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਲਈ) ਅਤੇ ਗ੍ਰਾਫਨਾ (ਇਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਦੀ ਕਲਪਨਾ ਕਰਨ ਲਈ)। ਅਸੀਂ ਫਾਇਦਾ ਉਠਾਇਆ ਏਕੀਕ੍ਰਿਤ в ਪਾਈਪਲਾਈਨ ਸੇਵਾਵਾਂ ਜੋ ਸੰਘੀ ਨਿਗਰਾਨੀ, ਕੇਂਦਰੀਕ੍ਰਿਤ ਲਾਗ ਸੰਗ੍ਰਹਿ, ਕਮਜ਼ੋਰੀ ਸਕੈਨਿੰਗ, ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ, ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਸੁਰੱਖਿਆ ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ।
• ਸੰਗਰੇਨੇਲ — ਕਾਫਕਾ ਕਲੱਸਟਰ ਨੂੰ ਲੋਡ ਕਰਨ ਲਈ ਇੱਕ ਟੂਲ।
• ਕਾਫਕਾ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਕਲਪਨਾ ਕਰਨ ਲਈ ਗ੍ਰਾਫਾਨਾ ਡੈਸ਼ਬੋਰਡ: ਕੁਬਰਨੇਟਸ ਕਾਫਕਾ, ਨੋਡ ਨਿਰਯਾਤਕ.
• ਕੁਬਰਨੇਟਸ 'ਤੇ ਕਾਫਕਾ ਕਲੱਸਟਰ ਸਥਾਪਤ ਕਰਨ ਦੇ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕੇ ਲਈ ਸੁਪਰਟਿਊਬ CLI। ਜੂਕੀਪਰ, ਕਾਫਕਾ ਆਪਰੇਟਰ, ਦੂਤ ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਹਿੱਸੇ ਸਥਾਪਤ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਕੁਬਰਨੇਟਸ 'ਤੇ ਉਤਪਾਦਨ ਲਈ ਤਿਆਰ ਕਾਫਕਾ ਕਲੱਸਟਰ ਨੂੰ ਚਲਾਉਣ ਲਈ ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਰਚਿਤ ਕੀਤੇ ਗਏ ਹਨ।
  • ਸਥਾਪਤ ਕਰਨ ਲਈ ਸੁਪਰਟਿਊਬ CLI ਦਿੱਤੀਆਂ ਹਦਾਇਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ ਇੱਥੇ.

EKS ਕਲੱਸਟਰ

ਸਮਰਪਿਤ ਵਰਕਰ ਨੋਡਸ ਦੇ ਨਾਲ ਇੱਕ EKS ਕਲੱਸਟਰ ਤਿਆਰ ਕਰੋ c5.4x ਵੱਡਾ ਕਾਫਕਾ ਦਲਾਲਾਂ ਦੇ ਨਾਲ ਪੌਡਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਵਿੱਚ, ਨਾਲ ਹੀ ਲੋਡ ਜਨਰੇਟਰ ਅਤੇ ਨਿਗਰਾਨੀ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਸਮਰਪਿਤ ਨੋਡਸ।

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

ਇੱਕ ਵਾਰ EKS ਕਲੱਸਟਰ ਚਾਲੂ ਅਤੇ ਚੱਲ ਰਿਹਾ ਹੈ, ਇਸਦੇ ਏਕੀਕ੍ਰਿਤ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ ਨਿਗਰਾਨੀ ਸੇਵਾ - ਉਹ ਪ੍ਰੋਮੀਥੀਅਸ ਅਤੇ ਗ੍ਰਾਫਾਨਾ ਨੂੰ ਇੱਕ ਸਮੂਹ ਵਿੱਚ ਤਾਇਨਾਤ ਕਰੇਗੀ।

ਕਾਫਕਾ ਸਿਸਟਮ ਦੇ ਹਿੱਸੇ

ਸੁਪਰਟਿਊਬ CLI ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ EKS ਵਿੱਚ ਕਾਫਕਾ ਸਿਸਟਮ ਕੰਪੋਨੈਂਟਸ (ਜ਼ੂਕੀਪਰ, ਕਾਫਕਾ-ਓਪਰੇਟਰ) ਸਥਾਪਿਤ ਕਰੋ:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

ਕਾਫਕਾ ਕਲੱਸਟਰ

ਮੂਲ ਰੂਪ ਵਿੱਚ, EKS ਕਿਸਮ ਦੇ EBS ਵਾਲੀਅਮ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ gpx NUMX, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਵਾਲੀਅਮ ਦੇ ਆਧਾਰ 'ਤੇ ਇੱਕ ਵੱਖਰੀ ਸਟੋਰੇਜ ਕਲਾਸ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ io1 ਕਾਫਕਾ ਕਲੱਸਟਰ ਲਈ:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

ਦਲਾਲਾਂ ਲਈ ਪੈਰਾਮੀਟਰ ਸੈੱਟ ਕਰੋ min.insync.replicas=3 ਅਤੇ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਵਿੱਚ ਨੋਡਾਂ 'ਤੇ ਬ੍ਰੋਕਰ ਪੌਡ ਤਾਇਨਾਤ ਕਰੋ:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

ਵਿਸ਼ੇ

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

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

ਹਰੇਕ ਵਿਸ਼ੇ ਲਈ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਾਰਕ 3 ਹੈ—ਉੱਚ ਉਪਲਬਧ ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀਆਂ ਲਈ ਘੱਟੋ-ਘੱਟ ਸਿਫ਼ਾਰਸ਼ ਕੀਤਾ ਮੁੱਲ।

ਜਨਰੇਸ਼ਨ ਟੂਲ ਲੋਡ ਕਰੋ

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

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

ਨੋਟ ਕਰਨ ਲਈ ਕੁਝ ਨੁਕਤੇ:

• ਲੋਡ ਜਨਰੇਟਰ 512 ਬਾਈਟ ਲੰਬਾਈ ਦੇ ਸੁਨੇਹੇ ਤਿਆਰ ਕਰਦਾ ਹੈ ਅਤੇ 500 ਸੰਦੇਸ਼ਾਂ ਦੇ ਬੈਚਾਂ ਵਿੱਚ ਕਾਫਕਾ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ।
• ਇੱਕ ਦਲੀਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ -required-acks=all ਪ੍ਰਕਾਸ਼ਨ ਨੂੰ ਸਫਲ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਸੰਦੇਸ਼ ਦੀਆਂ ਸਾਰੀਆਂ ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਕਾਫਕਾ ਦਲਾਲਾਂ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਅਤੇ ਪੁਸ਼ਟੀ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬੈਂਚਮਾਰਕ ਵਿੱਚ ਅਸੀਂ ਨਾ ਸਿਰਫ਼ ਸੰਦੇਸ਼ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਨੇਤਾਵਾਂ ਦੀ ਗਤੀ ਨੂੰ ਮਾਪਿਆ, ਸਗੋਂ ਉਹਨਾਂ ਦੇ ਪੈਰੋਕਾਰ ਸੰਦੇਸ਼ਾਂ ਦੀ ਨਕਲ ਵੀ ਕਰਦੇ ਹਨ। ਇਸ ਟੈਸਟ ਦਾ ਉਦੇਸ਼ ਖਪਤਕਾਰਾਂ ਦੀ ਪੜ੍ਹਨ ਦੀ ਗਤੀ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਨਹੀਂ ਹੈ (ਖਪਤਕਾਰ) ਹਾਲ ਹੀ ਵਿੱਚ ਪ੍ਰਾਪਤ ਹੋਏ ਸੁਨੇਹੇ ਜੋ ਅਜੇ ਵੀ OS ਪੇਜ ਕੈਸ਼ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਡਿਸਕ ਉੱਤੇ ਸਟੋਰ ਕੀਤੇ ਸੁਨੇਹਿਆਂ ਦੀ ਪੜ੍ਹਨ ਦੀ ਗਤੀ ਨਾਲ ਇਸਦੀ ਤੁਲਨਾ।
• ਲੋਡ ਜਨਰੇਟਰ 20 ਕਾਮਿਆਂ ਨੂੰ ਸਮਾਨਾਂਤਰ ਚਲਾਉਂਦਾ ਹੈ (-workers=20). ਹਰੇਕ ਵਰਕਰ ਵਿੱਚ 5 ਉਤਪਾਦਕ ਹੁੰਦੇ ਹਨ ਜੋ ਕਾਫਕਾ ਕਲੱਸਟਰ ਨਾਲ ਵਰਕਰ ਦੇ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਹਰੇਕ ਜਨਰੇਟਰ ਦੇ 100 ਉਤਪਾਦਕ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਹ ਸਾਰੇ ਕਾਫਕਾ ਕਲੱਸਟਰ ਨੂੰ ਸੰਦੇਸ਼ ਭੇਜਦੇ ਹਨ।

ਕਲੱਸਟਰ ਦੀ ਸਿਹਤ ਦੀ ਨਿਗਰਾਨੀ

ਕਾਫਕਾ ਕਲੱਸਟਰ ਦੇ ਲੋਡ ਟੈਸਟਿੰਗ ਦੌਰਾਨ, ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇਸਦੀ ਸਿਹਤ ਦੀ ਵੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਕਿ ਕੋਈ ਪੌਡ ਰੀਸਟਾਰਟ ਨਹੀਂ ਹੈ, ਕੋਈ ਆਊਟ-ਆਫ-ਸਿੰਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨਹੀਂ ਹਨ, ਅਤੇ ਘੱਟੋ-ਘੱਟ ਉਤਰਾਅ-ਚੜ੍ਹਾਅ ਦੇ ਨਾਲ ਵੱਧ ਤੋਂ ਵੱਧ ਥ੍ਰੋਪੁੱਟ ਹਨ:

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

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• ISR ਪੱਧਰ ("ਇਨ-ਸਿੰਕ" ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਗਿਣਤੀ) ਸੁੰਗੜਨਾ ਅਤੇ ਵਿਸਤਾਰ 0 ਦੇ ਬਰਾਬਰ ਹੈ।

ਮਾਪ ਨਤੀਜੇ

3 ਦਲਾਲ, ਸੰਦੇਸ਼ ਦਾ ਆਕਾਰ - 512 ਬਾਈਟਸ

ਤਿੰਨ ਦਲਾਲਾਂ ਵਿੱਚ ਸਮਾਨ ਰੂਪ ਵਿੱਚ ਵੰਡੇ ਗਏ ਭਾਗਾਂ ਦੇ ਨਾਲ, ਅਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ ~500 Mb/s (ਲਗਭਗ 990 ਹਜ਼ਾਰ ਸੁਨੇਹੇ ਪ੍ਰਤੀ ਸਕਿੰਟ):

JVM ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੀ ਮੈਮੋਰੀ ਖਪਤ 2 GB ਤੋਂ ਵੱਧ ਨਹੀਂ ਸੀ:

ਡਿਸਕ ਥ੍ਰੋਪੁੱਟ ਉਹਨਾਂ ਤਿੰਨਾਂ ਮੌਕਿਆਂ 'ਤੇ ਅਧਿਕਤਮ I/O ਨੋਡ ਥ੍ਰਰੂਪੁਟ 'ਤੇ ਪਹੁੰਚ ਗਈ ਜਿਸ 'ਤੇ ਬ੍ਰੋਕਰ ਚੱਲ ਰਹੇ ਸਨ:

ਨੋਡਸ ਦੁਆਰਾ ਮੈਮੋਰੀ ਵਰਤੋਂ 'ਤੇ ਡੇਟਾ ਤੋਂ, ਇਹ ਇਸ ਗੱਲ ਦਾ ਅਨੁਸਰਣ ਕਰਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਬਫਰਿੰਗ ਅਤੇ ਕੈਚਿੰਗ ਨੇ ~ 10-15 GB ਲਿਆ:

3 ਦਲਾਲ, ਸੰਦੇਸ਼ ਦਾ ਆਕਾਰ - 100 ਬਾਈਟਸ

ਜਿਵੇਂ ਕਿ ਸੁਨੇਹੇ ਦਾ ਆਕਾਰ ਘਟਦਾ ਹੈ, ਥ੍ਰੁਪੁੱਟ ਲਗਭਗ 15-20% ਘਟਦਾ ਹੈ: ਹਰੇਕ ਸੁਨੇਹੇ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਵਿੱਚ ਬਿਤਾਇਆ ਸਮਾਂ ਇਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ ਪ੍ਰੋਸੈਸਰ ਦਾ ਲੋਡ ਲਗਭਗ ਦੁੱਗਣਾ ਹੋ ਗਿਆ ਹੈ।

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

4 ਦਲਾਲ, ਸੰਦੇਸ਼ ਦਾ ਆਕਾਰ - 512 ਬਾਈਟਸ

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

ਜੇਵੀਐਮ ਮਸ਼ੀਨ ਦੀ ਮੈਮੋਰੀ ਖਪਤ 2 ਜੀਬੀ ਤੋਂ ਘੱਟ ਰਹੀ:

ਡਰਾਈਵਾਂ ਵਾਲੇ ਦਲਾਲਾਂ ਦਾ ਕੰਮ ਭਾਗਾਂ ਦੇ ਅਸੰਤੁਲਨ ਦੁਆਰਾ ਪ੍ਰਭਾਵਿਤ ਹੋਇਆ ਸੀ:

ਸਿੱਟਾ

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

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

ਜੇਕਰ ਤੁਸੀਂ ਬਨਜ਼ਾਈ ਕਲਾਉਡ ਟੈਕਨਾਲੋਜੀ ਅਤੇ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਕੰਪਨੀ ਦੇ ਗਾਹਕ ਬਣੋ GitHub, ਸਬੰਧਤ ਜ ਟਵਿੱਟਰ.

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

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

• «K8s ਵਿੱਚ Redis ਆਪਰੇਟਰ ਦੇ ਨਾਲ ਇੱਕ ਕਹਾਣੀ ਅਤੇ ਇਸ ਡੇਟਾਬੇਸ ਤੋਂ ਡੇਟਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਉਪਯੋਗਤਾਵਾਂ ਦੀ ਇੱਕ ਛੋਟੀ-ਸਮੀਖਿਆ";
• «RabbitMQ ਦਾ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਹਿਜ ਪ੍ਰਵਾਸ";
• «CoreOS ਤੋਂ zetcd: ZooKeeper ਨੂੰ...etcd ਸਟੋਰੇਜ ਨਾਲ ਬਦਲਣਾ".

ਸਰੋਤ: www.habr.com