ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਮੋਰੀਆਂ ਨੂੰ ਫਿਕਸ ਕਰਨਾ। DevOpsConf ਤੋਂ ਰਿਪੋਰਟ ਅਤੇ ਪ੍ਰਤੀਲਿਪੀ

ਪਾਵੇਲ ਸੇਲੀਵਾਨੋਵ, ਸਾਊਥਬ੍ਰਿਜ ਹੱਲ ਆਰਕੀਟੈਕਟ ਅਤੇ ਸਲਰਮ ਅਧਿਆਪਕ, ਨੇ DevOpsConf 2019 'ਤੇ ਇੱਕ ਪੇਸ਼ਕਾਰੀ ਦਿੱਤੀ। ਇਹ ਗੱਲਬਾਤ ਕੁਬਰਨੇਟਸ "ਸਲਰਮ ਮੈਗਾ" 'ਤੇ ਡੂੰਘਾਈ ਵਾਲੇ ਕੋਰਸ ਦੇ ਵਿਸ਼ਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਹਿੱਸਾ ਹੈ।

ਸਲਰਮ ਬੇਸਿਕ: ਕੁਬਰਨੇਟਸ ਦੀ ਜਾਣ-ਪਛਾਣ 18-20 ਨਵੰਬਰ ਨੂੰ ਮਾਸਕੋ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।
ਸਲਰਮ ਮੈਗਾ: ਕੁਬਰਨੇਟਸ ਦੇ ਹੁੱਡ ਦੇ ਹੇਠਾਂ ਦੇਖਦੇ ਹੋਏ — ਮਾਸਕੋ, 22-24 ਨਵੰਬਰ।
ਸਲਰਮ ਔਨਲਾਈਨ: ਦੋਵੇਂ ਕੁਬਰਨੇਟਸ ਕੋਰਸ ਹਮੇਸ਼ਾ ਉਪਲਬਧ.

ਕੱਟ ਦੇ ਹੇਠਾਂ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਹੈ।

ਸ਼ੁਭ ਦੁਪਹਿਰ, ਸਹਿਕਰਮੀਆਂ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਹਮਦਰਦੀ ਰੱਖਣ ਵਾਲੇ। ਅੱਜ ਮੈਂ ਸੁਰੱਖਿਆ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ।

ਮੈਂ ਦੇਖਿਆ ਕਿ ਅੱਜ ਹਾਲ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਸੁਰੱਖਿਆ ਗਾਰਡ ਹਨ। ਜੇਕਰ ਮੈਂ ਸੁਰੱਖਿਆ ਦੀ ਦੁਨੀਆ ਤੋਂ ਅਜਿਹੇ ਸ਼ਬਦਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ ਜਿਵੇਂ ਤੁਹਾਡੇ ਲਈ ਰਿਵਾਜ ਹੈ, ਤਾਂ ਮੈਂ ਤੁਹਾਡੇ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਮੁਆਫੀ ਮੰਗਦਾ ਹਾਂ।

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

ਮੇਰੀ ਪਿਛਲੀ ਕੰਪਨੀ ਨੇ ਅਜਿਹੀ ਸੇਵਾ ਵੇਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ. ਅਤੇ ਮੈਨੂੰ ਇਹ ਦੇਖਣ ਲਈ ਕਲੱਸਟਰ ਨੂੰ ਪੋਕ ਕਰਨ ਲਈ ਕਿਹਾ ਗਿਆ ਸੀ ਕਿ ਕੀ ਇਹ ਹੱਲ ਢੁਕਵਾਂ ਸੀ ਜਾਂ ਨਹੀਂ.

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

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

ਮੈਂ ਤੁਹਾਨੂੰ ਉਦਾਹਰਣਾਂ ਦੇ ਨਾਲ ਦੱਸਾਂਗਾ ਕਿ ਮੈਂ ਇਹ ਕਿਵੇਂ ਕੀਤਾ ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਇਸ ਤੋਂ ਕਿਵੇਂ ਬਚਾਇਆ।

ਪਰ ਪਹਿਲਾਂ, ਮੈਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਦਿਓ. ਮੇਰਾ ਨਾਮ ਪਾਵੇਲ ਸੇਲੀਵਾਨੋਵ ਹੈ। ਮੈਂ ਸਾਊਥਬ੍ਰਿਜ ਵਿਖੇ ਇੱਕ ਆਰਕੀਟੈਕਟ ਹਾਂ। ਮੈਂ Kubernetes, DevOps ਅਤੇ ਹਰ ਤਰ੍ਹਾਂ ਦੀਆਂ ਫੈਨਸੀ ਚੀਜ਼ਾਂ ਨੂੰ ਸਮਝਦਾ ਹਾਂ। ਸਾਊਥਬ੍ਰਿਜ ਇੰਜੀਨੀਅਰ ਅਤੇ ਮੈਂ ਇਹ ਸਭ ਬਣਾ ਰਹੇ ਹਾਂ, ਅਤੇ ਮੈਂ ਸਲਾਹ ਕਰ ਰਿਹਾ ਹਾਂ।

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

ਮੈਂ ਅੱਜ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ? ਰਿਪੋਰਟ ਦਾ ਵਿਸ਼ਾ ਸਪੱਸ਼ਟ ਹੈ - ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੀ ਸੁਰੱਖਿਆ ਬਾਰੇ. ਪਰ ਮੈਂ ਤੁਰੰਤ ਕਹਿਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਇਹ ਵਿਸ਼ਾ ਬਹੁਤ ਵੱਡਾ ਹੈ - ਅਤੇ ਇਸ ਲਈ ਮੈਂ ਤੁਰੰਤ ਸਪੱਸ਼ਟ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਮੈਂ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਕਿਸ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗਾ. ਮੈਂ ਹੈਕਨੀਡ ਸ਼ਬਦਾਂ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗਾ ਜੋ ਪਹਿਲਾਂ ਹੀ ਇੰਟਰਨੈਟ 'ਤੇ ਸੌ ਵਾਰ ਵਰਤੇ ਜਾ ਚੁੱਕੇ ਹਨ। ਹਰ ਕਿਸਮ ਦੇ RBAC ਅਤੇ ਸਰਟੀਫਿਕੇਟ।

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

ਇੱਥੇ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਤਿੰਨ ਨੁਕਤੇ ਹਨ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਮੈਂ ਅੱਜ ਗੱਲ ਕਰਾਂਗਾ:

1. ਉਪਭੋਗਤਾ ਅਧਿਕਾਰ ਬਨਾਮ ਪੌਡ ਅਧਿਕਾਰ। ਉਪਭੋਗਤਾ ਅਧਿਕਾਰ ਅਤੇ ਪੋਡ ਅਧਿਕਾਰ ਇੱਕੋ ਚੀਜ਼ ਨਹੀਂ ਹਨ।
2. ਕਲੱਸਟਰ ਬਾਰੇ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ। ਮੈਂ ਦਿਖਾਵਾਂਗਾ ਕਿ ਤੁਸੀਂ ਇਸ ਕਲੱਸਟਰ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਕਲੱਸਟਰ ਤੋਂ ਲੋੜੀਂਦੀ ਸਾਰੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰ ਸਕਦੇ ਹੋ।
3. ਕਲੱਸਟਰ 'ਤੇ DoS ਹਮਲਾ। ਜੇਕਰ ਅਸੀਂ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਅਸੀਂ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ ਇੱਕ ਕਲੱਸਟਰ ਲਗਾਉਣ ਦੇ ਯੋਗ ਹੋਵਾਂਗੇ। ਮੈਂ ਕਲੱਸਟਰ ਨਿਯੰਤਰਣ ਤੱਤਾਂ 'ਤੇ DoS ਹਮਲਿਆਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ।

ਇਕ ਹੋਰ ਆਮ ਚੀਜ਼ ਜਿਸਦਾ ਮੈਂ ਜ਼ਿਕਰ ਕਰਾਂਗਾ ਉਹ ਹੈ ਕਿ ਮੈਂ ਇਸ ਸਭ ਦੀ ਜਾਂਚ ਕੀਤੀ, ਜਿਸ 'ਤੇ ਮੈਂ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਕਹਿ ਸਕਦਾ ਹਾਂ ਕਿ ਇਹ ਸਭ ਕੰਮ ਕਰਦਾ ਹੈ.

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

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

ਮੈਂ ਵਾਅਦਾ ਕੀਤਾ ਸੀ ਕਿ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਅਸੀਂ ਕਲੱਸਟਰ ਦੇ ਪ੍ਰਬੰਧਕ ਅਧਿਕਾਰ ਪ੍ਰਾਪਤ ਕਰਾਂਗੇ। ਸਾਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੀ ਪੌਡ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜੋ ਕਿ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਤੋੜ ਦੇਵੇਗਾ। ਸਾਨੂੰ ਬਸ ਇਸ ਨੂੰ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ 'ਤੇ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

kubectl apply -f pod.yaml

ਇਹ ਪੋਡ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੇ ਮਾਸਟਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਕੋਲ ਪਹੁੰਚੇਗਾ। ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਕਲੱਸਟਰ ਖੁਸ਼ੀ ਨਾਲ ਸਾਡੇ ਕੋਲ admin.conf ਨਾਮ ਦੀ ਇੱਕ ਫਾਈਲ ਵਾਪਸ ਕਰੇਗਾ। ਕਿਊਬ ਵਿੱਚ, ਇਹ ਫਾਈਲ ਸਾਰੇ ਪ੍ਰਬੰਧਕ ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਕਲੱਸਟਰ API ਨੂੰ ਸੰਰਚਿਤ ਕਰਦੀ ਹੈ। ਮੇਰੇ ਖਿਆਲ ਵਿੱਚ, ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ ਦੇ 98% ਤੱਕ ਪ੍ਰਸ਼ਾਸਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਨਾ ਇਹ ਕਿੰਨਾ ਸੌਖਾ ਹੈ।

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

ਅਤੇ ਹੁਣ ਇੱਕ ਖਾਸ ਤੌਰ 'ਤੇ ਤਿਆਰ ਪੋਡ ਬਾਰੇ. ਅਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਚਿੱਤਰ 'ਤੇ ਚਲਾਉਂਦੇ ਹਾਂ. ਆਉ ਡੇਬੀਅਨ: ਜੇਸੀ ਨੂੰ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਲੈਂਦੇ ਹਾਂ।

ਸਾਡੇ ਕੋਲ ਇਹ ਚੀਜ਼ ਹੈ:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

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

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

ਇਨ੍ਹਾਂ ਦੋ ਭਾਗਾਂ ਨਾਲ ਉਹ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਮਾਸਟਰ ਕੋਲ ਆਵੇਗਾ। ਅਤੇ ਉਸਨੂੰ ਉੱਥੇ ਰਹਿਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਾਵੇਗੀ।

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

hostNetwork: true 
hostPID: true 

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

ਫਿਰ ਛੋਟੀਆਂ ਗੱਲਾਂ ਦੀ ਗੱਲ ਹੈ। etcd ਲਓ ਅਤੇ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਪੜ੍ਹੋ।

ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਕੁਬਰਨੇਟਸ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਜੋ ਕਿ ਮੂਲ ਰੂਪ ਵਿੱਚ ਮੌਜੂਦ ਹੈ।

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

ਅਤੇ ਇਸਦਾ ਸਾਰ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਪੌਡ ਵਿੱਚ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਇਸ ਕਲੱਸਟਰ ਦੇ ਅਧਿਕਾਰਾਂ ਤੋਂ ਬਿਨਾਂ ਵੀ ਲਾਂਚ ਕਰਦੇ ਹਾਂ, ਕਿ ਅਸੀਂ ਹੋਸਟਪਾਥ ਕਿਸਮ ਦੀ ਇੱਕ ਵਾਲੀਅਮ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਇਸਦਾ ਅਰਥ ਹੈ ਹੋਸਟ ਤੋਂ ਉਹ ਮਾਰਗ ਲੈਣਾ ਜਿਸ 'ਤੇ ਅਸੀਂ ਲਾਂਚ ਕਰਾਂਗੇ - ਅਤੇ ਇਸਨੂੰ ਵਾਲੀਅਮ ਵਜੋਂ ਲੈਣਾ. ਅਤੇ ਫਿਰ ਅਸੀਂ ਇਸਨੂੰ ਨਾਮ ਕਹਿੰਦੇ ਹਾਂ: ਮੇਜ਼ਬਾਨ. ਅਸੀਂ ਇਸ ਪੂਰੇ ਹੋਸਟਪਾਥ ਨੂੰ ਪੌਡ ਦੇ ਅੰਦਰ ਮਾਊਂਟ ਕਰਦੇ ਹਾਂ। ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ, /host ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ।

ਮੈਂ ਇਸਨੂੰ ਦੁਬਾਰਾ ਦੁਹਰਾਵਾਂਗਾ। ਅਸੀਂ ਪੌਡ ਨੂੰ ਮਾਸਟਰ ਕੋਲ ਆਉਣ ਲਈ ਕਿਹਾ, ਉੱਥੇ ਹੋਸਟਨੈੱਟਵਰਕ ਅਤੇ ਹੋਸਟਪੀਆਈਡੀ ਪ੍ਰਾਪਤ ਕਰੋ - ਅਤੇ ਇਸ ਪੋਡ ਦੇ ਅੰਦਰ ਮਾਸਟਰ ਦੇ ਪੂਰੇ ਰੂਟ ਨੂੰ ਮਾਊਂਟ ਕਰੋ।

ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ ਡੇਬੀਅਨ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਬੈਸ਼ ਚੱਲ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਹ ਬੈਸ਼ ਰੂਟ ਦੇ ਹੇਠਾਂ ਚੱਲਦਾ ਹੈ। ਯਾਨੀ ਕਿ, ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਅਧਿਕਾਰ ਦੇ, ਮਾਸਟਰ 'ਤੇ ਰੂਟ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ।

ਫਿਰ ਸਾਰਾ ਕੰਮ ਸਬ ਡਾਇਰੈਕਟਰੀ /host /etc/kubernetes/pki 'ਤੇ ਜਾਣਾ ਹੈ, ਜੇਕਰ ਮੈਂ ਗਲਤ ਨਹੀਂ ਹਾਂ, ਤਾਂ ਉਥੇ ਕਲੱਸਟਰ ਦੇ ਸਾਰੇ ਮਾਸਟਰ ਸਰਟੀਫਿਕੇਟ ਚੁੱਕੋ ਅਤੇ, ਉਸ ਅਨੁਸਾਰ, ਕਲੱਸਟਰ ਪ੍ਰਬੰਧਕ ਬਣੋ।

ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਇਹ ਪੌਡਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਅਧਿਕਾਰ ਹਨ - ਚਾਹੇ ਉਪਭੋਗਤਾ ਕੋਲ ਕਿਹੜੇ ਅਧਿਕਾਰ ਹਨ:

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

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

ਹੋਸਟ ਪਾਥ ਵਾਲੀਅਮ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਤੋਂ ਲੋੜੀਂਦਾ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ।

ਪਰ ਇਸ ਸਭ ਦਾ ਕੀ ਕਰੀਏ?

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

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

Pod ਸੁਰੱਖਿਆ ਨੀਤੀ ਬਾਰੇ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ, ਸਾਰੇ PSP ਸਥਾਪਕਾਂ ਦਾ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਵਰਣਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਉਹ ਸਿਰਫ਼ ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਯੋਗ ਹਨ। ਪੋਡ ਸੁਰੱਖਿਆ ਨੀਤੀ ਦਾਖਲਾ ਪਲੱਗਇਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਮਰੱਥ ਹੈ।

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

ਅਤੇ ਸਾਡੇ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਜਾਪਦਾ ਹੈ. ਅਤੇ ਸਾਡੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਦੋ ਮਿੰਟਾਂ ਵਿੱਚ ਹੈਕ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।

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

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

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

ਅੱਗੇ ਸਾਡੇ ਕੋਲ ਇੱਕ ਖਾਸ devns ਹੈ, ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ ਖਾਸ ਪੌਡ ਚਲਾ ਸਕਦੇ ਹੋ। ਅਤੇ ਫਿਰ ਇਸ ਪੋਡ ਤੋਂ ਇਸ ਤਰ੍ਹਾਂ ਕੁਝ ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਹੈ:

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics ਪ੍ਰੋਮੀਥੀਅਸ ਨਿਰਯਾਤਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜੋ ਖੁਦ ਕੁਬਰਨੇਟਸ API ਤੋਂ ਮੈਟ੍ਰਿਕਸ ਇਕੱਤਰ ਕਰਦਾ ਹੈ। ਉੱਥੇ ਬਹੁਤ ਸਾਰਾ ਡੇਟਾ ਹੈ, ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਵਿੱਚ ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ, ਇਹ ਕੀ ਹੈ, ਤੁਹਾਨੂੰ ਇਸ ਨਾਲ ਕੀ ਸਮੱਸਿਆਵਾਂ ਹਨ.

ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਣ ਵਜੋਂ:

kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

ਇੱਕ ਗੈਰ-ਅਧਿਕਾਰਤ ਪੋਡ ਤੋਂ ਇੱਕ ਸਧਾਰਨ ਕਰਲ ਬੇਨਤੀ ਕਰਕੇ, ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਤੁਸੀਂ ਕੁਬਰਨੇਟਸ ਦਾ ਕਿਹੜਾ ਸੰਸਕਰਣ ਚਲਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਤੁਹਾਨੂੰ ਆਸਾਨੀ ਨਾਲ ਦੱਸ ਦੇਵੇਗਾ।

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

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

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

ਅਜਿਹੀ ਗੱਲ ਹੈ - ਨੈੱਟਵਰਕ ਨੀਤੀ.

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

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

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

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

ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

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

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

ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਨਵਾਂ ਕਲੱਸਟਰ ਬਣਾਉਂਦੇ ਹੋ, ਉਸੇ ਸਮੇਂ ਫਲੈਨਲ ਦੀ ਬਜਾਏ ਕੈਲੀਕੋ ਪਾਓ.

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

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

ਇੱਕ ਹੋਰ ਛੋਟੀ ਜਿਹੀ ਸਮੱਸਿਆ ਹੈ। ਪ੍ਰੋਮੀਥੀਅਸ ਇਕੱਲਾ ਅਜਿਹਾ ਨਹੀਂ ਹੈ ਜੋ ਕਿਸੇ ਨੂੰ ਵੀ ਆਪਣੀ ਮੈਟ੍ਰਿਕਸ ਸੌਂਪਦਾ ਹੈ। ਸਾਡੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੇ ਸਾਰੇ ਹਿੱਸੇ ਵੀ ਆਪਣੇ ਖੁਦ ਦੇ ਮੈਟ੍ਰਿਕਸ ਵਾਪਸ ਕਰਨ ਦੇ ਯੋਗ ਹਨ।

ਪਰ ਜਿਵੇਂ ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਹੈ, ਜੇ ਤੁਸੀਂ ਕਲੱਸਟਰ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਕਰ ਸਕਦੇ ਅਤੇ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਘੱਟੋ ਘੱਟ ਕੁਝ ਨੁਕਸਾਨ ਕਰ ਸਕਦੇ ਹੋ।

ਇਸ ਲਈ ਮੈਂ ਜਲਦੀ ਹੀ ਦੋ ਤਰੀਕੇ ਦਿਖਾਵਾਂਗਾ ਕਿ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਕਿਵੇਂ ਬਰਬਾਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਜਦੋਂ ਮੈਂ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਾਂਗਾ ਤਾਂ ਤੁਸੀਂ ਹੱਸੋਗੇ, ਇਹ ਦੋ ਅਸਲ ਜ਼ਿੰਦਗੀ ਦੇ ਮਾਮਲੇ ਹਨ।

ਢੰਗ ਇੱਕ. ਸਰੋਤ ਦੀ ਕਮੀ.

ਚਲੋ ਇੱਕ ਹੋਰ ਵਿਸ਼ੇਸ਼ ਪੌਡ ਲਾਂਚ ਕਰੀਏ। ਇਸ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਇੱਕ ਸੈਕਸ਼ਨ ਹੋਵੇਗਾ।

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ, ਬੇਨਤੀਆਂ CPU ਅਤੇ ਮੈਮੋਰੀ ਦੀ ਮਾਤਰਾ ਹੈ ਜੋ ਬੇਨਤੀਆਂ ਵਾਲੇ ਖਾਸ ਪੌਡਾਂ ਲਈ ਹੋਸਟ 'ਤੇ ਰਾਖਵੀਂ ਹੈ। ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਇੱਕ Kubernetes ਕਲੱਸਟਰ ਵਿੱਚ ਇੱਕ ਚਾਰ-ਕੋਰ ਹੋਸਟ ਹੈ, ਅਤੇ ਚਾਰ CPU ਪੌਡ ਬੇਨਤੀਆਂ ਦੇ ਨਾਲ ਉੱਥੇ ਪਹੁੰਚਦੇ ਹਨ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਬੇਨਤੀਆਂ ਵਾਲੇ ਹੋਰ ਪੌਡ ਇਸ ਹੋਸਟ ਵਿੱਚ ਨਹੀਂ ਆ ਸਕਣਗੇ।

ਜੇ ਮੈਂ ਅਜਿਹੀ ਪੌਡ ਚਲਾਉਂਦਾ ਹਾਂ, ਤਾਂ ਮੈਂ ਕਮਾਂਡ ਚਲਾਵਾਂਗਾ:

$ kubectl scale special-pod --replicas=...

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

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

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

ਅਤੇ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤਰੀਕਾ ਨੰਬਰ ਦੋ ਆਉਂਦਾ ਹੈ. ਅਸੀਂ 11 ਪੌਡ ਲਾਂਚ ਕਰਦੇ ਹਾਂ। ਇਹ ਗਿਆਰਾਂ ਅਰਬ ਹੈ। ਇਹ ਇਸ ਲਈ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਮੈਂ ਅਜਿਹਾ ਨੰਬਰ ਲੈ ਕੇ ਆਇਆ ਹਾਂ, ਪਰ ਕਿਉਂਕਿ ਮੈਂ ਇਸਨੂੰ ਖੁਦ ਦੇਖਿਆ ਹੈ।

ਅਸਲ ਕਹਾਣੀ. ਦੇਰ ਸ਼ਾਮ ਮੈਂ ਦਫ਼ਤਰ ਛੱਡਣ ਹੀ ਵਾਲਾ ਸੀ। ਮੈਂ ਡਿਵੈਲਪਰਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਨੂੰ ਕੋਨੇ ਵਿੱਚ ਬੈਠੇ ਵੇਖਦਾ ਹਾਂ, ਆਪਣੇ ਲੈਪਟਾਪਾਂ ਨਾਲ ਬੇਚੈਨੀ ਨਾਲ ਕੁਝ ਕਰ ਰਿਹਾ ਹਾਂ। ਮੈਂ ਮੁੰਡਿਆਂ ਕੋਲ ਜਾਂਦਾ ਹਾਂ ਅਤੇ ਪੁੱਛਦਾ ਹਾਂ: "ਤੁਹਾਨੂੰ ਕੀ ਹੋਇਆ?"

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

ਇਹ ਸੱਚ ਹੈ ਕਿ ਇਹ ਕਹਾਣੀ ਕੁਬਰਨੇਟਸ ਉੱਤੇ ਨਹੀਂ ਵਾਪਰੀ ਸੀ; ਉਸ ਸਮੇਂ ਇਹ ਨੋਮੈਡ ਸੀ। ਇਹ ਇਸ ਤੱਥ ਦੇ ਨਾਲ ਖਤਮ ਹੋਇਆ ਕਿ ਨੋਮੈਡ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀਆਂ ਲਗਾਤਾਰ ਕੋਸ਼ਿਸ਼ਾਂ ਤੋਂ ਰੋਕਣ ਦੀਆਂ ਸਾਡੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੇ ਇੱਕ ਘੰਟੇ ਬਾਅਦ, ਨੋਮੈਡ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਕਿ ਉਹ ਸਕੇਲਿੰਗ ਨਹੀਂ ਬੰਦ ਕਰੇਗਾ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ ਕਰੇਗਾ। "ਮੈਂ ਥੱਕ ਗਿਆ ਹਾਂ, ਮੈਂ ਜਾ ਰਿਹਾ ਹਾਂ।" ਅਤੇ ਉਹ ਝੁਕ ਗਿਆ.

ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਮੈਂ ਕੁਬਰਨੇਟਸ' ਤੇ ਵੀ ਅਜਿਹਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ. ਕੁਬਰਨੇਟਸ ਗਿਆਰਾਂ ਅਰਬ ਪੌਡਾਂ ਤੋਂ ਖੁਸ਼ ਨਹੀਂ ਸੀ, ਉਸਨੇ ਕਿਹਾ: “ਮੈਂ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਅੰਦਰੂਨੀ ਮਾਊਥ ਗਾਰਡ ਤੋਂ ਵੱਧ ਹੈ।" ਪਰ 1 ਪੌਡਸ ਕਰ ਸਕਦੇ ਹਨ।

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

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

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

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

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

ਕਲੱਸਟਰ ਦੇ ਸਾਰੇ ਨੋਡਾਂ 'ਤੇ, ਵੱਧ ਤੋਂ ਵੱਧ ਨਵੇਂ iptables ਨਿਯਮ ਲਗਭਗ ਇੱਕੋ ਸਮੇਂ ਤਿਆਰ ਕੀਤੇ ਜਾਣਗੇ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਹਰੇਕ ਸੇਵਾ ਲਈ ਇੱਕ ਅਰਬ iptables ਨਿਯਮ ਤਿਆਰ ਕੀਤੇ ਜਾਣਗੇ।

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

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

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

ਸਰੋਤ ਕੋਟਾ + ਸੀਮਾ ਸੀਮਾ + RBAC
• ਇੱਕ ਨੇਮਸਪੇਸ ਬਣਾਓ
• ਅੰਦਰ ਇੱਕ ਸੀਮਾ ਸੀਮਾ ਬਣਾਓ
• ਅੰਦਰ ਸਰੋਤ ਕੋਟਾ ਬਣਾਓ
• CI ਲਈ ਸੇਵਾ ਖਾਤਾ ਬਣਾਓ
• CI ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਰੋਲਬਾਈਡਿੰਗ ਬਣਾਓ
• ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ ਜ਼ਰੂਰੀ ਸੇਵਾ ਪੌਡ ਲਾਂਚ ਕਰੋ

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

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

ਥੋੜਾ ਇਸ ਸਾਰੀ ਗੁੰਝਲਦਾਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣਾ.

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

ਨੈੱਟਵਰਕ ਨੀਤੀ ਸਿਰਫ਼ ਇੱਕ ਹੋਰ ਬੇਲੋੜੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਹੈ ਜੋ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈ.

LimitRange/ResourceQuota - ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ। ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਬਹੁਤ ਸਮਾਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਕੀਤੀ ਸੀ, ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਮੈਨੂੰ ਯਕੀਨ ਸੀ ਕਿ ਹਰ ਕੋਈ ਇਸਨੂੰ ਵਰਤ ਰਿਹਾ ਸੀ। ਇਹ ਪਤਾ ਲੱਗਾ ਕਿ ਇਹ ਬਹੁਤ ਘੱਟ ਹੁੰਦਾ ਹੈ.

ਇਸ ਤੋਂ ਇਲਾਵਾ ਜੋ ਮੈਂ ਰਿਪੋਰਟ ਦੇ ਦੌਰਾਨ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ, ਉੱਥੇ ਗੈਰ-ਦਸਤਾਵੇਜ਼ੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਕਲੱਸਟਰ 'ਤੇ ਹਮਲਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ। ਹਾਲ ਹੀ ਵਿੱਚ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਹੈ ਕੁਬਰਨੇਟਸ ਦੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਦਾ ਵਿਆਪਕ ਵਿਸ਼ਲੇਸ਼ਣ.

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

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

ਸਾਰਿਆਂ ਦਾ ਧੰਨਵਾਦ।

ਸਰੋਤ: www.habr.com