VPN ਸਾਈਡਕਾਰ ਨੂੰ ਸ਼ੁਰੂ ਨਿਯਮ ਅਤੇ ਅਸਫਲਤਾ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ

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

ਕ੍ਰਮ ਸਿਰਫ਼ ਪਹਿਲੀ ਬੇਨਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ

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

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

ਦੱਸੋ ਗੇਟ ਕੀ ਦੇਖਦਾ ਹੈ: ਇੱਕ ਪ੍ਰੋਸੈਸ ਹੈ, ਇੱਕ ਇੰਟਰਫੇਸ ਹੈ, ਇੱਕ handshake ਪੂਰਾ ਹੋਇਆ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਦਾਅਵਾ “ਇਸ pod ਨੂੰ ਲੋੜੀਂਦੇ ਟਿਕਾਣਿਆਂ ਤੱਕ ਡੇਟਾ ਮਾਰਗ ਕੰਮ ਕਰਦਾ ਹੈ” ਤੋਂ ਕਮਜ਼ੋਰ ਹੈ।

ਡੇਟਾ ਮਾਰਗ ਨੂੰ ਮੰਨਣ ਦੀ ਬਜਾਏ ਲਾਗੂ ਕਰੋ

ਪ੍ਰੋਬ ਇੱਕ ਪਲ ਦੀ ਜਾਂਚ ਹੈ ਅਤੇ firewall ਉਹ ਗੁਣ ਹੈ ਜੋ ਪਲਾਂ ਵਿਚਕਾਰ ਲਾਗੂ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਲੋੜ ਇਹ ਹੈ ਕਿ ਐਪ ਦਾ ਟ੍ਰੈਫਿਕ ਕਦੇ ਟਨਲ ਤੋਂ ਬਾਹਰ ਨਾ ਜਾਵੇ, ਤਾਂ ਇਹ ਸਾਂਝੇ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਵਿੱਚ ਸਵੀਕਾਰ-ਜਾਂ-ਛੱਡੋ ਨਿਯਮ ਵਜੋਂ ਦੱਸਣਾ ਪਵੇਗਾ। ਕੰਟੇਨਰ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਕ੍ਰਮ ਇਹ ਲੋੜ ਨਹੀਂ ਚੁੱਕ ਸਕਦਾ। ਸਿਰਫ਼ ਇੱਕ ਨਿਯਮ ਚੁੱਕ ਸਕਦਾ ਹੈ।

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

ਅਸਫਲਤਾ ਨੀਤੀ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਤੈਅ ਕਰੋ: ਟਨਲ ਸਿਹਤਮੰਦ ਨਾ ਹੋਣ ਵੇਲੇ ਐਪ ਦਾ ਟ੍ਰੈਫਿਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੁਕਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਜਾਰੀ ਰਹਿ ਕੇ ਅਸੁਰੱਖਿਅਤ ਵਜੋਂ ਨਿਸ਼ਾਨਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ? ਦੋਵੇਂ ਵਾਜਬ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਖਾਸ ਕ੍ਰਮ ਵਿੱਚ ਕੰਟੇਨਰ ਸ਼ੁਰੂ ਕਰਕੇ ਨਹੀਂ ਮਿਲਦਾ।

ਉਸ ਟ੍ਰੈਫਿਕ ਦੀ ਜਾਂਚ ਕਰੋ ਜਿਸਦਾ ਤੁਸੀਂ ਜ਼ਿਕਰ ਨਹੀਂ ਕੀਤਾ

ਨਿਯੰਤਰਿਤ ਟਨਲ ਅਸਫਲਤਾ ਦੌਰਾਨ ਨਵੀਂ ਬੇਨਤੀ ਲਵੋ ਅਤੇ ਦੇਖੋ ਕਿ ਇਹ ਬਾਹਰ ਜਾਂਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਫਿਰ ਉਨ੍ਹਾਂ ਰਾਹਾਂ ਲਈ ਜਾਂਚ ਦੁਹਰਾਓ ਜਿਨ੍ਹਾਂ ਨੂੰ ਐਗਜ਼ਿਟ-ਐਡਰੈੱਸ ਟੈਸਟ ਕਦੇ ਨਹੀਂ ਛੂਹਦਾ: ਕਲਸਟਰ ਦੇ ਅੰਦਰ DNS ਰਿਜ਼ੋਲਿਊਸ਼ਨ, IPv6 ਟਿਕਾਣੇ, ਅਤੇ ਜਨਤਕ ਇੰਟਰਨੈੱਟ ਦੀ ਬਜਾਏ ਕਲਸਟਰ-ਅੰਦਰੂਨੀ ਪਤਿਆਂ ਰਾਹੀਂ ਪਹੁੰਚਣ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ। ਇਹ ਉਹ ਰਾਹ ਹਨ ਜੋ ਟਨਲ ਮਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਚੁੱਪਚਾਪ ਕੰਮ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ।

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

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

ਡਿਪਲੌਇਮੈਂਟ ਰਿਕਾਰਡ ਲਿਖੋ

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

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

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