19 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
Kelsey Hightower ਦੀ Cloud-Native ਸਪਸ਼ਟਤਾ: Kubernetes ਦੀ ਵਿਆਖਿਆ
Kelsey Hightower ਦੀ ਸਪਸ਼ਟ ਸਿੱਖਣ ਦੀ ਸ਼ੈਲੀ ਨੇ ਟੀਮਾਂ ਨੂੰ Kubernetes ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਸੰਕਲਪ ਸਮਝਣ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕੀਤੀ—ਭਰੋਸਾ, ਸਾਂਝੀ ਭਾਸ਼ਾ ਅਤੇ ਵਿਆਪਕ ਅਪਨਾਉਣ ਬਣਦੇ ਹੋਏ।
Kelsey Hightower ਦੀ ਸਪਸ਼ਟ ਸਿੱਖਣ ਦੀ ਸ਼ੈਲੀ ਨੇ ਟੀਮਾਂ ਨੂੰ Kubernetes ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਸੰਕਲਪ ਸਮਝਣ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕੀਤੀ—ਭਰੋਸਾ, ਸਾਂਝੀ ਭਾਸ਼ਾ ਅਤੇ ਵਿਆਪਕ ਅਪਨਾਉਣ ਬਣਦੇ ਹੋਏ।
ਕਲਾਉਡ-ਨੇਟਿਵ ਟੂਲ ਤੇਜ਼ੀ ਅਤੇ ਲਚੀਲਾਪਨ ਦਾ ਵਾਅਦਾ ਕਰਦੇ ਹਨ, ਪਰ ਉਹ ਨਵੀਂ ਸ਼ਬਦਾਵਲੀ, ਨਵੇਂ ਹਿੱਸੇ ਅਤੇ ਆਪਰੇਸ਼ਨ ਬਾਰੇ ਨਵਾਂ ਸੋਚਣ ਦਾ ਢੰਗ ਵੀ ਲਿਆਉਂਦੇ ਹਨ। ਜਦ ਵਿਆਖਿਆ ਧੁੰਦਲੀ ਹੋਵੇ, ਅਪਨਾਉਣਾ ਰੁਕ ਜਾਂਦਾ ਹੈ ਇਸ ਸਿੱਧੇ ਕਾਰਨ ਕਰਕੇ: ਲੋਕ ਟੂਲ ਨੂੰ ਆਪਣੇ ਅਸਲੀ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਜੋੜ nahi ਪਾ ਰਹੇ। ਟੀਮਾਂ ਹਿਚਕਿਚਾਉਂਦੀਆਂ ਹਨ, ਨੇਤਾ ਫੈਸਲੇ ਰੋਕਦੇ ਹਨ, ਤੇ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਯੋਗ ਆਧ-ਪੂਰੇ ਪਾਇਲਟ ਵਿੱਚ ਪਰਿਵਰਤਿਤ ਹੋ ਜਾਂਦੇ ਹਨ।
ਕਲਾਰਟੀ ਉਸ ਡਾਈਨਾਮਿਕ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਇੱਕ ਸਪਸ਼ਟ ਵਿਆਖਿਆ "Kubernetes ਵਿਆਖਿਆ ਕੀਤੀ" ਨੂੰ ਇੱਕ ਮਾਰਕੀਟਿੰਗ ਵਾਕ्य ਨਹੀਂ ਰਹਿਣ ਦਿੰਦੀ; ਇਹ ਇੱਕ ਸਾਂਝੀ ਸਮਝ ਬਣਾਉਂਦੀ ਹੈ: Kubernetes ਕੀ ਕਰਦਾ ਹੈ, ਕੀ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਰੋਜ਼ਾਨਾ ਲਈ ਕਿਸੇ ਗੱਲ ਦੀ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਜਦ ਉਹ ਮਾਨਸਿਕ ਮਾਡਲ ਤੇ স্থਾਪਤ ਹੋ ਜਾਵੇ, ਗੱਲਬਾਤਾਂ ਪ੍ਰਾਇਕਟਿਕਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ—ਵਰਕਲੋਡ, ਭਰੋਸੇਯੋਗਤਾ, ਸਕੇਲਿੰਗ, ਸੁਰੱਖਿਆ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮ ਚਲਾਉਣ ਲਈ ਲਾਜ਼ਮੀ ਆਦਤਾਂ ਬਾਰੇ।
ਜਦ ਸੰਕਲਪ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾਏ ਜਾਂਦੇ ਹਨ, ਟੀਮਾਂ:
ਦूसਰੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਸੰਚਾਰ ਇੱਕ ਸੋਭਾ-ਜੋਗ ਚੀਜ਼ nahi; ਇਹ ਰੋਲਆਉਟ ਯੋਜਨਾ ਦਾ ਹਿੱਸਾ ਹੈ।
ਇਹ ਲੇਖ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ Kelsey Hightower ਦੀ ਸਿੱਖਣ ਦੀ ਸ਼ੈਲੀ ਨੇ ਕਿਵੇਂ ਮੁੱਖ DevOps ਸੰਕਲਪ ਅਤੇ Kubernetes ਦੇ ਮੂਲਤੱਵਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਇਆ—ਅਤੇ ਇਸ ਪਹੁੰਚ ਨੇ ਕਿਵੇਂ ਵਿਸ਼ਾਲ cloud-native ਅਪਨਾਉਣ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ। ਤੁਸੀਂ ਆਪਣੇ ਸੰਗਠਨ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਯੋਗ ਸਬਕ ਲੈਕੇ ਜਾਵੋਗੇ:
ਮਕਸਦ ਟੂਲਾਂ 'ਤੇ விவਾਦ ਨਹੀਂ; ਇਹ ਦੱਸਣਾ ਹੈ ਕਿ ਸਪਸ਼ਟ ਸੰਚਾਰ—ਦੋਹਰਾਇਆ ਗਿਆ, ਸਾਂਝਾ ਕੀਤਾ ਅਤੇ ਕਮੇਨਿਊਨਟੀ ਵਲੋਂ ਸੁਧਾਰਿਆ ਗਿਆ—ਕਿਵੇਂ ਇੱਕ ਉਦਯੋਗ ਨੂੰ ਜਿਗਿਆਸਾ ਤੋਂ ਭਰੋਸੇਯੋਗ ਉਪਯੋਗ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ।
Kelsey Hightower ਇੱਕ ਮੰਨਿਆ ہوا Kubernetes ਸੁਪਸ਼ਿਕਸ਼ਕ ਅਤੇ ਕਮੇਨਿਊਨਟੀ ਆਵਾਜ਼ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਕੰਮ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੂੰ ਵੇਖਣਗੇ ਕਿ ਕੰਟੇਨਰ ਓਰਕੇਸਟ੍ਰੇਸ਼ਨ DAR ਵਿੱਚ ਅਸਲ ਰੂਪ ਵਿੱਚ ਕੀ ਲਾਈਟ ਹੁੰਦਾ ਹੈ—ਖ਼ਾਸ ਕਰਕੇ ਉਹ ਆਪਰੇਸ਼ਨਲ ਹਿੱਸੇ ਜੋ ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਕਠੋਰ ਤਰੀਕੇ ਨਾਲ ਸਿੱਖਦੇ ਹਨ।
ਉਹ ਉਦਯੋਗੀ ਕਾਨਫਰੰਸਾਂ 'ਤੇ ਬੋਲਦੇ, ਟਿਊਟੋਰੀਅਲ ਅਤੇ ਟਾਕ ਪ੍ਰਕਾਸ਼ਤ ਕਰਦੇ ਅਤੇ ਵਿਸ਼ਾਲ cloud-native ਕਮੇਨਿਊਨਟੀ ਵਿਚ ਹਿੱਸਾ ਲੈਂਦੇ ਰਹੇ ਹਨ ਜਿੱਥੇ ਪ੍ਰੈਕਟੀਸ਼ਨਰ ਪੈਟਰਨ, ਫੇਲਿਯਰ ਅਤੇ ਫਿਕਸ ਸਾਂਝੇ ਕਰਦੇ ਹਨ। Kubernetes ਨੂੰ ਕਿਸੇ ਜਾਦੂਈ ਉਤਪਾਦ ਵਜੋਂ ਪੇਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ, ਉਹ ਇਸਨੂੰ ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਵਜੋਂ ਦਰਸਾਉਂਦੇ ਹਨ ਜਿਸਨੂੰ ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ—ਜਿਸਦੇ ਹਿੱਸੇ, ਟਰੇਡ-ਆਫ਼ ਅਤੇ ਅਸਲ ਫੇਲਰ ਮੋਡ ਹੁੰਦੇ ਹਨ।
ਉਹ ਗੱਲ ਜੋ ਲਗਾਤਾਰ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ ਉਹ ਹੈ ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਹਮਦਰਦੀ ਜਿਨ੍ਹਾਂ 'ਤੇ ਚੀਜ਼ਾਂ ਟੁੱਟਣ 'ਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ: on-call ਇੰਜੀਨੀਅਰ, ਪਲੈਟਫਾਰਮ ਟੀਮਾਂ, SREs ਅਤੇ ਡਿਵੈਲਪਰ ਜੋ ਨਵੀਂ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਸਿੱਖਦੇ ਹੋਏ ਕੋਡ ਰਿਲੀਜ਼ ਕਰ ਰਹੇ ਹਨ।
ਉਹ ਹਮਦਰਦੀ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦੀ ਹੈ ਕਿ ਉਹ ਕਿਵੇਂ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ:
ਇਹ ਉਹਨਾਂ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਵੀ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ ਕਿ ਉਹ ਨਵੀਆਂ ਸ਼ੁਰੂਆਤੀਆਂ ਨਾਲ ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਘੱਟ ਸਮਝਣ ਦੇ ਗੱਲ ਕਰਦੇ ਹਨ। ਟੋਨ ਆਮ ਤੌਰ 'ਤੇ ਸਿੱਧਾ, ਜਮੀਨੀ ਅਤੇ ਦਾਵਿਆਂ ਵਿੱਚ ਸੰਭਾਲੀ ਹੁੰਦਾ ਹੈ—"ਇੱਥੇ ਕੀ ਹੁੰਦਾ ਹੈ" ਦੀ ਵਿਆਖਿਆ, ਨਾ ਕਿ "ਇਹ ਇਕੋ ਸਹੀ ਤਰੀਕਾ ਹੈ"।
ਤੁਹਾਨੂੰ ਕਿਸੇ ਨੂੰ ਮਾਸਕਾਟ ਵਜੋਂ ਨਹੀਂ ਦੇਖਣ ਦੀ ਜ਼ਰੂਰਤ ਕਿ ਪ੍ਰਭਾਵ ਵੇਖ ਸਕੋ। ਸਬੂਤ ਮੈਟਰੀਅਲ ਵਿੱਚ ਹੈ: ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਹਵਾਲਾ ਦਿੱਤੇ ਗਏ ਟਾਕ, ਹੈਂਡਸ-ਆਨ ਸਿੱਖਣ ਵਾਲੇ ਸਰੋਤ ਅਤੇ ਐਸੇ ਵਿਆਖਿਆਵਾਂ ਜੋ ਹੋਰ ਸਿਖਾਉਣ ਵਾਲੇ ਅਤੇ ਅੰਤਰਕਿਰਿਆਤਮਕ ਪਲੈਟਫਾਰਮ ਟੀਮਾਂ ਦੁਆਰਾ ਦੁਹਰਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਜਦ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿਸੇ ਕੰਸੈਪਟ ਜਿਵੇਂ ਕਿ ਕੰਟਰੋਲ ਪਲੇਨ, ਸਰਟੀਫਿਕੇਟ, ਜਾਂ ਕਲੱਸਟਰ ਬੂਟਸਟ੍ਰੈਪਿੰਗ 'ਦਾ ਅਸਲੀ ਅਰਥ ਸਮਝ ਆ ਗਿਆ', ਅਕਸਰ ਇਹ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਸੇ ਨੇ ਉਸਨੂੰ ਸਪਸ਼ਟ ਢੰਗ ਨਾਲ ਸਮਝਾਇਆ—ਤੇ ਕਾਫੀ ਵਾਰ ਉਹ ਸਪਸ਼ਟ ਵਿਆਖਿਆਵਾਂ ਉਸ ਦੀ ਸਿਖਲਾਈ ਦੀ ਸ਼ੈਲੀ ਨਾਲ ਜੋੜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਜੇ Kubernetes ਅਪਨਾਉਣਾ ਕਿਹਾ ਜਾਵੇ ਕਿ ਆਧਿਕ ਢੰਗ ਨਾਲ ਸੰਚਾਰ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਦੀ ਪ੍ਰਭਾਵਤਾ ਇੱਕ ਯਾਦ ਦਿਲਾਉਂਦੀ ਹੈ ਕਿ ਸਪਸ਼ਟ ਸਿੱਖਿਆ ਵੀ ਇਕ ਪ੍ਰਵਾਨਾਭੂ ਤਰ੍ਹਾਂ ਦੀ ਨਿਰਮਾਣਾਤਮਕ ਚੀਜ਼ ਹੈ।
Kubernetes ਦੇ ਮੂਲ ਵੇਲੇ, ਜਦ ਇਹ "ਕਿਵੇਂ ਅਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਕੰਟੇਨਰ ਚਲਾਏਂ" ਦਾ ਮੁੱਖ ਜਵਾਬ ਨਹੀਂ ਸੀ, ਇਹ ਅਕਸਰ ਨਵੀਂ ਸ਼ਬਦਾਵਲੀ ਅਤੇ ਧਾਰਣਾਵਾਂ ਦੀ ਭਾਰੀ ਭੀੜ ਵਾਂਗ ਲੱਗਦਾ ਸੀ। ਇੱਥੋਂ ਤੱਕ ਕਿ Linux, CI/CD ਅਤੇ ਕਲਾਉਡ ਸਰਵਿਸਿਜ਼ ਨਾਲ ਪਰਿਚਿਤ ਟੀਮਾਂ ਵੀ ਮੂਲ ਸਵਾਲ ਪੁੱਛ ਰਹੀਆਂ ਸਨ—ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਲੱਗਦਾ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਇਹ ਸਵਾਲ ਨਹੀਂ ਪੁੱਛਣੇ ਚਾਹੀਦੇ।
Kubernetes ਨੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਾਰੇ ਸੋਚਣ ਦਾ ਵੱਖਰਾ ਤਰੀਕਾ ਲਿਆਉਂਦਾ ਹੈ। "ਇੱਕ ਸਰਵਰ ਮੇਰੀ ਐਪ ਚਲਾਂਦਾ ਹੈ" ਦੀ ਥਾਂ, ਤੁਸੀਂ ਅਚਾਨਕ ਪੌਡ, ਡਿਪਲੋਇਮੈਂਟ, ਸਰਵਿਸ, ਇੰਗਰੈਸ, ਕੰਟਰੋਲਰ ਅਤੇ ਕਲੱਸਟਰ ਦੇਖਦੇ ਹੋ। ਹਰ ਟਰਮ ਆਪਣੀ ਥਾਂ ਤੇ ਸਧਾਰਨ ਲੱਗਦੀ ਹੈ, ਪਰ ਉਸਦਾ ਮਤਲਬ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਕੀਤੇ ਹੋਰ ਹਿੱਸਿਆਂ ਨਾਲ ਕਿਵੇਂ ਜੁੜਦਾ ਹੈ।
ਆਮ ਰੁਕਾਵਟ ਮਨ-ਮਾਡਲ ਦੇ ਮਿਲੇ-ਜੁਲੇ ਹੋਣ ਦੀ ਸੀ:
ਇਹ ਸਿਰਫ਼ ਇੱਕ ਟੂਲ ਸਿੱਖਣਾ ਨਹੀਂ ਸੀ; ਇਹ ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਸਿੱਖਣਾ ਸੀ ਜੋ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਨੂੰ ਤਰਲ ਮੰਨਦਾ ਹੈ।
ਪਹਿਲਾ ਡੈਮੋ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇੱਕ ਕੰਟੇਨਰ ਸਹੀ ਤਰ੍ਹਾਂ ਸਕੇਲ ਹੋ ਕੇ ਚੱਲੇ। ਪਰ ਚਿੰਤਾ ਬਾਅਦ ਵਿੱਚ ਛਲਕ ਕੇ ਆਉਂਦੀ, ਜਦ ਲੋਕ ਅਸਲ ਆਪਰੇਸ਼ਨਲ ਸਵਾਲ ਕਲਪਨਾ ਕਰਨ ਲੱਗਦੇ:
ਬਹੁਤੀਆਂ ਟੀਮ YAML ਤੋਂ ਨਹੀਂ ਡਰਦੀਆਂ ਸੀ—ਉਹ ਛੁਪੇ ਹੋਏ ਜਟਿਲਤਾ ਤੋਂ ਡਰਦੀਆਂ ਸਨ, ਜਿੱਥੇ ਗਲਤੀਆਂ ਸ਼ਾਂਤ ਢੰਗ ਨਾਲ ਰਿਕਾਰਡ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇਕ ਆਉਟੇਜ ਤੱਕ ਨਾ ਪਹੁੰਚਣ।
ਕਈ ਵਾਰੀ Kubernetes ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਕਿ 'ਤੁਸੀਂ ਸਿਰਫ ਡਿਪਲੋਯ ਕਰੋ' ਅਤੇ ਹਰ ਚੀਜ਼ ਆਟੋਮੈਟਿਕ ਹੋ ਜਾਵੇਗੀ। ਹਕੀਕਤ ਵਿੱਚ, ਉਸ ਅਨੁਭਵ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਚੋਣਾਂ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ ਹਨ: ਨੈੱਟਵਰਕਿੰਗ, ਸਟੋਰੇਜ, ਆਈਡੈਂਟੀਟੀ, ਨੀਤੀ, ਮਾਨੀਟਰਿੰਗ, ਲੋਗਿੰਗ ਅਤੇ ਅਪਗ੍ਰੇਡ ਰਣਨੀਤੀ।
ਇਹ ਫਰਕ ਨਾਰਾਜ਼ਗੀ ਪੈਦਾ ਕਰਦਾ। ਲੋਕ Kubernetes ਨੂੰ ਨਕਾਰ ਨਹੀਂ ਰਹੇ ਸਨ; ਉਹ ਇਸ ਗੱਲ 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰ ਰਹੇ ਸਨ ਕਿ ਵਾਅਦਾ ('ਸਧਾਰਨ, ਪੋਰਟੇਬਲ, ਸਵੈ-ਹੀਲਿੰਗ') ਨੂੰ ਅਸਲ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸੱਚ ਕਰਨਾ ਕਿੰਨਾ ਮੁਸ਼ਕਲ ਹੈ।
Kelsey Hightower ਉਸ ਤਰ੍ਹਾਂ ਸਿੱਖਾਉਂਦੇ ਹਨ ਜਿਵੇਂ ਕੋਈ ਉਹ ਬੰਦਾ ਹੋਵੇ ਜਿਸਨੇ on-call ਰਹਿਣਾ ਹੈ, ਕਿਸੇ ਡਿਪਲੋਇਮੈਂਟ ਨੇ ਪਿੱਠ ਘੁਟਾਈ ਹੈ, ਤੇ ਫਿਰ ਵੀ ਅਗਲੇ ਦਿਨ ਕੋਡ ਰਿਲੀਜ਼ ਕਰਨਾ ਹੋਵੇ। ਮਕਸਦ ਵਾਕ-ਸ਼ਬਦ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਕਰਨਾ ਨਹੀਂ—ਇਹ ਤੁਹਾਨੂੰ ਉਹ ਮਾਨਸਿਕ ਮਾਡਲ ਦੇਣਾ ਹੈ ਜੋ ਤੁਸੀਂ 2 ਵਜੇ ਸਵੇਰੇ pager ਬਜਣ 'ਤੇ ਵਰਤ ਸਕੋ।
ਇੱਕ ਮੁੱਖ ਆਦਤ ਹੈ ਜਦੋ ਜਰੂਰੀ ਹੋ ਉਹੇ ਸਮੇਂ ਸ਼ਬਦ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ। ਸ਼ੁਰੂ ਵਿੱਚ Kubernetes ਦੀ ਇੱਕ ਲੰਮੀ ਸ਼ਬਦਾਵਲੀ ਦੇਣ ਦੀ ਬਜਾਏ, ਉਹ ਇੱਕ ਸੰਕਲਪ ਨੂੰ ਸੰਦਰਭ ਵਿੱਚ ਸਮਝਾਉਂਦੇ ਹਨ: ਇੱਕ Pod ਕੀ ਹੈ ਅਤੇ ਇੱਕਸਮੇਂ ਤੇ ਕਿਉਂ ਤੁਸੀਂ ਕੰਟੇਨਰਾਂ ਨੂੰ ਗਰੁੱਪ ਕਰੋਗੇ, ਜਾਂ ਇੱਕ Service ਕੀ ਕਰਦੀ ਹੈ ਜਦ ਸਵਾਲ ਹੋਵੇ 'ਮੇਰੀ ਐਪ ਨੂੰ ਕਿਵੇਂ ਰਿਕਵੇਸਟ ਮਿਲਦੇ ਹਨ?'
ਇਹ ਤਰੀਕਾ ਉਹ ਬੇਹਿਸ ਕੀਅਸੂਸ ਨੂੰ ਘੱਟ ਕਰਦਾ ਹੈ ਜੋ ਬਹੁਤ ਸਾਰੇ ਇੰਜੀਨੀਅਰ cloud-native ਵਿਸ਼ਿਆਂ ਨਾਲ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਇੱਕ ਗਲੋਸਰੀ ਯਾਦ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ; ਤੁਸੀਂ ਇੱਕ ਸਮੱਸਿਆ ਨੂੰ ਉਸਦੇ ਹੱਲ ਤੱਕ ਪ徂Follow ਕਰਕੇ ਸਿੱਖਣ ਹੋ।
ਉਨ੍ਹਾਂ ਦੀਆਂ ਵਿਆਖਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਪਰਟਿਕੁਲਰ ਹਕੀਕਤੀ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ:
ਇਹ ਸਵਾਲਾਂ ਕੁਦਰਤੀ ਤੌਰ ਤੇ Kubernetes ਪ੍ਰਿਮਿਟਿਵਾਂ ਵੱਲ ਲੈ ਜਾਂਦੀਆਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਅਜਿਹੇ ਸਿਨੈਰਿਓਜ਼ ਨਾਲ ਜੋੜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਇੰਜੀਨੀਅਰ ਅਸਲ ਸਿਸਟਮ ਤੋਂ ਪਛਾਣਦੇ ਹਨ। ਡਾਇਗ੍ਰਾਮ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ, ਪਰ ਪਾਠ ਦਾ ਭਾਰ ਉਦਾਹਰਣ ਦੀ ਉੱਤੇ ਹੁੰਦਾ ਹੈ।
ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਿੱਖਿਆ ਵਿੱਚ ਉਹ ਨਿਰਾਸ਼ੀਜਕ ਹਿੱਸੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ: ਅਪਗ੍ਰੇਡ, ਘਟਨਾਵਾਂ, ਅਤੇ ਟਰੇਡ-ਆਫ਼। ਇਹ ਤੁਹਾਨੂੰ ਨਹੀਂ ਕਹਿੰਦਾ 'Kubernetes ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ', ਬਲਕਿ 'Kubernetes ਤੁਹਾਨੂੰ ਤਕਨੀਕ ਦਿੰਦਾ ਹੈ—ਹੁਣ ਤੁਹਾਨੂੰ ਉਹ ਚਲਾਉਣੇ ਪੈਣਗੇ'।
ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਮੰਨਣਾ ਹੈ:
ਇਸੇ ਕਾਰਨ ਉਹਨਾਂ ਦੀ ਸਮੱਗਰੀ ਕੰਮ ਕਰਨ ਵਾਲੇ ਇੰਜੀਨੀਅਰਾਂ ਨਾਲ ਗੂੰਜੇ: ਇਹ ਪਰੋਡਕਸ਼ਨ ਨੂੰ ਕਲਾਸਰੂਮ ਮਨਦਾ ਹੈ, ਅਤੇ ਸਪਸ਼ਟਤਾ ਨੂੰ ਇੱਜ਼ਤ ਦੇ ਰੂਪ ਵਿੱਚ ਵੇਖਦਾ ਹੈ।
"Kubernetes the Hard Way" ਯਾਦ ਰਹਿੰਦਾਂ ਹੈ ਕਿਉਂਕਿ ਇਹ ਜਾਣ-ਬੁਝ ਕੇ ਮੁਸ਼ਕਲ ਨਹੀਂ, ਬਲਕਿ ਇਹ ਉਹ ਹਿੱਸੇ ਛੂਹਣ ਕਰਾਉਂਦਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਟਿਊਟੋਰੀਅਲ ਛੁਪਾਉਂਦੇ ਹਨ। ਮੈਨੇਜਡ ਸਰਵਿਸ ਵਿਜ਼ਰਡ ਤੋਂ ਕਲਿੱਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇੱਕ ਕਲੱਸਟਰ ਪੀਸ-ਬਾਈ-ਪੀਸ ਇਕੱਠਾ ਕਰਦੇ ਹੋ। ਉਹ 'ਹੱਥਾਂ-ਹੱਥ ਸਿੱਖਣ' ਵਾਲੀ ਪਹੁੰਚ ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਨੂੰ ਕਾਲਾ ਬਕਸਾਂ ਤੋਂ ਬਾਹਰ ਲਿਆਉਂਦੀ ਹੈ ਅਤੇ ਇੱਕ ਐਸਾ ਸਿਸਟਮ ਬਣਾਉਂਦੀ ਹੈ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ।
ਵਾਕਥਰੂ ਤੁਹਾਨੂੰ ਆਪਣੇ ਆਪ ਹਿੱਸੇ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ: ਸਰਟੀਫਿਕੇਟ, kubeconfigs, ਕੰਟਰੋਲ ਪਲੇਨ ਕੰਪੋਨੈਂਟ, ਨੈੱਟਵਰਕਿੰਗ, ਅਤੇ ਵਰਕਰ ਨੋਡ ਸੈਟਅਪ। ਜੇਕਰ ਤੁਸੀਂ ਕੀਤੇ ਤਰੀਕੇ ਨੂੰ ਕਦੇ ਵੀ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਨਹੀਂ ਚਲਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ, ਫਿਰ ਵੀ ਇਹ ਅਭਿਆਸ ਸਿਖਾਉਂਦਾ ਹੈ ਕਿ ਹਰ ਕੰਪੋਨੈਂਟ ਕਿਸ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਅਤੇ ਗਲਤ ਕਨਫਿਗਰ ਹੋਣ 'ਤੇ ਕੀ ਹੋ ਸਕਦਾ ਹੈ।
ਤੁਸੀਂ صرف 'etcd ਮਹੱਤਵਪੂਰਨ ਹੈ' ਨਹੀਂ ਸੁਣਦੇ—ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਕਿ ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਇਹ ਕੀ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੇ ਇਹ ਉਪਲਬਧ ਨਹੀਂ ਤਾਂ ਕੀ ਨਤੀਜਾ ਹੋ ਸਕਦਾ ਹੈ। 'API ਸਰਵਰ ਦਰਵਾਜ਼ਾ ਹੈ' ਇਹ ਯਾਦ ਨਹੀਂ ਰਹਿ ਜਾਂਦਾ—ਤੁਸੀਂ ਇਸਨੂੰ ਸੈਟਅਪ ਕਰਦੇ ਹੋ ਅਤੇ ਸਮਝਦੇ ਹੋ ਕਿ ਇਹ ਕਿਹੜੇ keys ਜਾਂਚਦਾ ਹੈ ਪਹਿਲਾਂ ਜੇਹੜਾ رਿਕਵੇਸਟ ਆਉਂਦਾ ਹੈ।
ਕਈ ਟੀਮਾਂ Kubernetes ਨੂੰ ਅਪਨਾਉਣ ਵਿੱਚ ਅਸਹਜ ਮਹਿਸੂਸ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਨਹੀ ਦੱਸ ਸਕਦੀਆਂ ਕਿ ਹੇਠਾਂ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਮੂਲ ਤੋਂ ਬਣਾਉਣ ਇਸ ਅਹਿਸਾਸ ਨੂੰ ਉਲਟ ਦਿੰਦਾ ਹੈ। ਜਦ ਤੁਹਾਨੂੰ ਸਰਟੀਫਿਕੇਟ ਚੇਨ (certs), ਸਚਾਈ ਦਾ ਸਰੋਤ (etcd), ਅਤੇ ਕੰਟਰੋਲ ਲੂਪ ਦੀ ਸੰਕਲਪਨਾ (controllers ਲਗਾਤਾਰ desired vs actual state ਨੂੰ ਮਿਲਾਉਂਦੇ ਰਹਿਣ) ਦਾ ਅੰਦਾਜ਼ਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਸਿਸਟਮ ਵਧੀਕ ਰਹੱਸਮਈ ਨਹੀਂ ਲੱਗਦਾ।
ਉਹ ਭਰੋਸਾ ਪ੍ਰਾਇਕਟਿਕ ਹੁੰਦਾ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ ਵੇਂਡਰ ਫੀਚਰਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ, ਘਟਨਾਵਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਅਤੇ ਸਹੀ ਤਰਜੀਹਾਂ ਚੁਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਕਹਿ ਸਕਦੇ ਹੋ 'ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਇਹ ਮੈਨੇਜਡ ਸਰਵਿਸ ਕੀ ਅਭਸ્ت ਕਰ ਰਹੀ ਹੈ', ਨਾ ਕਿ ਉਮੀਦ ਕਰਦੇ ਹੋ ਕਿ ਇਹ ਸਹੀ ਹੋਵੇਗੀ।
ਇੱਕ ਚੰਗਾ ਵਾਕਥਰੂ 'Kubernetes' ਨੂੰ ਛੋਟੇ, ਟੈਸਟ ਕਰਨਯੋਗ ਕਦਮਾਂ ਵਿੱਚ ਭਾੰਟਦਾ ਹੈ। ਹਰ ਕਦਮ ਦਾ ਇਕ ਸਪਸ਼ਟ ਉਮੀਦਿਆ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ—ਸੇਵਾ ਸਟਾਰਟ ਹੋਵੇ, ਹੈਲਥ ਚੈਕ ਪਾਸ ਹੋਵੇ, ਨੋਡ ਜੁੜੇ। ਪ੍ਰਗਟਿ ਮਾਪਯੋਗ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਗਲਤੀਆਂ ਲੋਕਲ ਰਹਿੰਦੀਆਂ ਹਨ।
ਇਹ ਬਣਤਰ ਚਿੰਤਾ ਨੂੰ ਘਟਾਂਦੀ ਹੈ: ਜਟਿਲਤਾ ਸਮਝਣਯੋਗ ਫ਼ੈਸਲਿਆਂ ਦੀ ਇੱਕ ਲੜੀ ਬਣ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਇਕੱਲਾ ਛਾਲ ਜੋ ਅਣਜਾਣ ਵਿੱਚ ਛੱਡ ਦਿੰਦਾ ਹੈ।
ਕਾਫੀ Kubernetes ਦੀ ਗੁੰਝਲ ਦੱਸਣ ਨਾਲ ਆਉਂਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਫੀਚਰਾਂ ਦੇ ਗੁੱਚੇ ਵਜੋਂ ਵੇਖਦੇ ਹੋ ਨਾ ਕਿ ਇਕ ਸਧਾਰਨ ਵਾਅਦਾ ਵਜੋਂ: ਤੁਸੀਂ ਜੋ ਚਾਹੁੰਦੇ ਹੋ ਉਸਦੀ ਵਰਣਨਾ ਕਰੋ, ਅਤੇ ਸਿਸਟਮ ਹਮੇਸ਼ਾ ਅਸਲੀਅਤ ਨੂੰ ਉਸਦੇ ਨਜ਼ਦੀਕ ਬਣਾਈ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।
'Desired state' सिरਫ਼ ਤੁਹਾਡੀ ਟੀਮ ਵੱਲੋਂ ਲਿਖਿਆ ਗਿਆ ਨਤੀਜਾ ਹੈ: 'ਇਸ ਐਪ ਦੀ ਤਿੰਨ ਨਕਲ ਚਲਾਉ', 'ਇਸਨੂੰ ਇੱਕ ਸਥਿਰ ਪਤੇ ਤੇ ਖੋਲ੍ਹੋ', 'CPU ਹੱਦ ਰੱਖੋ'। ਇਹ ਕਿਸੇ ਸਕ੍ਰਿਪਟ ਦੀ ਲੜੀ ਨਹੀਂ।
ਇਹ ਫਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਰੋਜ਼ਾਨਾ ਓਪਸ ਕੰਮ ਦੀ ਦਰਸਾਉਂਦਾ ਹੈ। 'SSH ਕਰਕੇ ਸਰਵਰ A 'ਤੇ ਜਾ ਕੇ ਪ੍ਰੋਸੈਸ ਚਲਾਉ' ਦੀ ਥਾਂ, ਤੁਸੀਂ ਟਾਰਗੇਟ ਘੋਸ਼ਣਾ ਕਰਦੇ ਹੋ ਅਤੇ ਪਲੇਟਫਾਰਮ ਮੁੜਦੋਹਰਾਉਣ ਵਾਲੇ ਕਦਮ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ।
Reconciliation ਲਗਾਤਾਰ ਚੈੱਕ-ਅਤੇ-ਠੀਕ ਕਰਨ ਵਾਲੀ ਲੂਪ ਹੈ। Kubernetes ਜੋ ਤੁਸੀਂ ਮੰਗਿਆ ਹੈ ਉਸਨੂੰ ਜੋ ਅਸਲ 'ਚ ਚੱਲ ਰਿਹਾ ਹੈ ਨਾਲ ਤੁਲਨਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੇ ਕੁਝ ਡ੍ਰਿਫਟ ਹੋ ਗਿਆ—ਪੌਡ کریਸ਼, ਨੋਡ ਗਾਇਬ, ਕਨਫਿਗ ਬਦਲਿਆ—ਤਾਂ ਇਹ ਗੈਪ ਬੰਦ ਕਰਨ ਲਈ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ।
ਆਦਮੀ ਭਾਸ਼ਾ ਵਿੱਚ: ਇਹ ਇੱਕ on-call ਇੰਜੀਨੀਅਰ ਹੈ ਜੋ ਕਦੇ ਸੁੱਤਦਾ ਨਹੀਂ, ਲਗਾਤਾਰ ਸਹਿਮਤ ਮਿਆਰ ਨੂੰ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।
ਇੱਥੇ ਸੰਕਲਪਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਕਾਫੀ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ। ਸੰਕਲਪ ਹੈ 'ਸਿਸਟਮ ਡ੍ਰਿਫਟ ਨੂੰ ਸਹੀ ਕਰਦਾ ਹੈ'। ਲਾਗੂ ਕਰਨ ਦੇ ਤਰੀਕੇ ਵਿੱਚ controllers, replica sets ਜਾਂ rollout ਰਣਨੀਤੀਆਂ ਆ ਸਕਦੀਆਂ ਹਨ—ਪਰ আপনি ਪਹਿਲਾਂ ਕੋਰ ਆਈਡੀਅਾ ਨੂੰ ਸਮਝ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇਨ੍ਹਾਂ ਦੀ ਡਿਟੇਲ ਵਿੱਚ ਲੰ ਘ।
Scheduling ਇੱਕ ਅਮਲੀ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜੋ ਹਰ ਓਪਰੇਟਰ ਸਕੂਪ ਹੁੰਦਾ ਹੈ: 'ਕਿਹੜੀ ਮਸ਼ੀਨ ਇਸ ਵਰਕਲੋਡ ਨੂੰ ਚਲਾਏਗੀ?' Kubernetes ਉਪਲਬਧ ਸਮਰੱਥਾ, ਪਾਬੰਦੀਆਂ ਅਤੇ ਨੀਤੀਆਂ ਦੇਖ ਕੇ ਵਕਤਲੂਕ ਤੌਰ 'ਤੇ ਕੰਮ ਨੋਡਾਂ 'ਤੇ ਰੱਖਦਾ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਿਮਿਟਿਵਾਂ ਨੂੰ ਜਾਣੂ ਕਾਰਜਾਂ ਨਾਲ ਜੋੜਨਾ ਇਹ ਸਮਝਣ ਵਿੱਚ ਸਹਾਇਕ ਹੁੰਦਾ ਹੈ:
ਜਦ ਤੁਸੀਂ Kubernetes ਨੂੰ 'ਡਿਕਲੇਅਰ, ਰੀਕਨਸਾਈਲ, ਪਲੇਸ' ਵਜੋਂ ਫਰੇਮ ਕਰਦੇ ਹੋ, ਤਾਂ ਬਾਕੀ ਸ਼ਬਦਾਵਲੀ ਬਣ ਜਾਂਦੀ ਹੈ—ਲਾਭਦਾਇਕ ਪਰ ਹੁਣ ਰਹੱਸਮਈ ਨਹੀਂ।
ਓਪਰੇਸ਼ਨਲ ਗੱਲਾਂ ਅਕਸਰ ਇੱਕ ਨਿੱਜੀ ਭਾਸ਼ਾ ਵਾਂਗ ਲੱਗਦੀਆਂ ਹਨ: SLIs, error budgets, 'blast radius', 'capacity planning'। ਜਦ ਲੋਕ ਅਪਵਿਹਸਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ, ਤਾਂ ਉਹ ਜਾਂ ਤਾਂ ਸਿਰਫ ਸਹਿਮਤ ਹੋ ਜਾਂਦੇ ਹਨ ਜਾਂ ਮੁੱਦੇ ਤੋਂ ਬਚਦੇ ਹਨ—ਦੋਹਾਂ ਨਤੀਜੇ ਨਾਜ਼ਕ ਸਿਸਟਮ ਪੈਦਾ ਕਰਦੇ ਹਨ।
Kelsey ਦੀ ਸ਼ੈਲੀ ops ਨੂੰ ਆਮ ਇੰਜੀਨੀਅਰਿੰਗ ਬਣਾਉਂਦੀ ਹੈ: ਪ੍ਰਾਇਕਟਿਕਲ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲੜੀ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸਿੱਖ ਸਕਦੇ ਹੋ, ਭਾਵੇਂ ਤੁਸੀਂ ਨਵੇਂ ਹੋ।
Ops ਨੂੰ 'ਬਿਹਤਰ ਅਭਿਆਸ' ਦੀ ਥਾਂ ਇਹ ਦੱਸੋ ਕਿ ਤੁਹਾਡੀ ਸੇਵਾ ਤਣਾਅ ਹੇਠ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ:
ਜਦ ops ਇਸ ਤਰੀਕੇ ਨਾਲ ਬਿਆਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਇਹ ਟਰਿਵਿਆ ਨਹੀਂ ਰਹਿੰਦਾ, ਪਰ ਸਧਾਰਨ ਮਨ-ਮਾਡਲ ਬਣ ਜਾਂਦਾ ਹੈ।
ਵਧੀਆ ਵਿਆਖਿਆਵਾਂ ਨਹੀਂ ਕਹਿੰਦੀਆਂ ਕਿ ਇੱਕ ਸਹੀ ਰਸਤਾ ਹੈ—ਉਹ ਹਰ ਚੋਣ ਦੀ ਲਾਗਤ ਦਿਖਾਉਂਦੀਆਂ ਹਨ।
ਟਰੇਡ-ਆਫ਼ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਨਾਂਵ ਦੇ ਕੇ, ਟੀਮਾਂ ਉਤਪਾਦਕ ਤਰੀਕੇ ਨਾਲ ਵੱਖ-ਵੱਖ ਵਿਰੋਧ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਕਿਸੇ ਨੂੰ 'ਨਹੀਂ ਸਮਝਣ ਵਾਲਾ' ਆਖੇ।
ਓਪਰੇਸ਼ਨ ਹਰਾਉਣ ਨਾਲ ਸਿੱਖਿਆ ਜਾਂਦੀ ਹੈ—ਘਟਨਾਵਾਂ ਅਤੇ ਨਜ਼ਦੀਕੀ-ਮਿਸ਼ਨਾਂ ਨੂੰ ਦੇਖ ਕੇ, ਨਾਂ ਕਿ ਸ਼ਬਦਾਵਲੀ ਯਾਦ ਕਰਕੇ। ਇੱਕ ਸਿਹਤਮੰਦ ops ਸਭਿਆਚਾਰ ਸਵਾਲਾਂ ਨੂੰ ਕੰਮ ਵਜੋਂ ਵੇਖਦਾ ਹੈ, ਕਮਜ਼ੋਰੀ ਨਹੀਂ।
ਇਕ ਪ੍ਰਾਇਕਟਿਕਲ ਆਦਤ: ਉਸوقتੋ ਬਾਅਦ ਜੋ ਕੋਈ ਆਉਟੇਜ ਜਾਂ ਡਰਾਨਾ ਚੇਤਾਵਨੀ ਹੋਵੇ, ਤਿੰਨ ਚੀਜ਼ਾਂ ਲਿਖੋ—ਤੁਸੀਂ ਕੀ ਉਮੀਦ ਕੀਤੀ, ਅਸਲ ਵਿੱਚ ਕੀ ਹੋਇਆ, ਅਤੇ ਕਿਹੜਾ ਸਿਗਨਲ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਨੂੰ ਚੇਤਾਵਨ ਕਰਦਾ। ਇਹ ਛੋਟੀ ਲੂਪ ਭ੍ਰਮ ਨੂੰ ਚੰਗੇ ਰਨਬੁੱਕਸ, ਸਾਫ਼ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਸ਼ਾਂਤ on-call ਰੋਟੇਸ਼ਨਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਹ ਮਾਈਂਡਸੈਟ ਫੈਲਾਉਣੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਸਿਖਾਓ: ਸਧਾਰਨ ਸ਼ਬਦ, ਈਮਾਨਦਾਰ ਟਰੇਡ-ਆਫ਼ ਅਤੇ ਜ਼ੀਵੰਤ ਤੌਰ 'ਤੇ ਖੁੱਲ੍ਹ ਕੇ ਸਿੱਖਣ ਦੀ ਆਗਿਆ।
ਸਪਸ਼ਟ ਵਿਆਖਿਆਵਾਂ ਸਿਰਫ਼ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਮਦਦ ਨਹੀਂ ਕਰਦੀਆਂ—ਉਹ ਫਰੈੰਚਾਈਜ਼ ਹੁੰਦੀਆਂ ਹਨ। ਜਦ ਕੋਈ ਬੋਲਣ ਵਾਲਾ ਜਾਂ ਲੇਖਕ Kubernetes ਨੂੰ ਵਾਸਤਵਿਕ ਬਣਾਉਂਦਾ ਹੈ—ਹਰ ਹਿੱਸੇ ਦਾ ਕੀ ਕੰਮ ਹੈ, ਇਹ ਕਿਉਂ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਹਕੀਕਤ ਵਿੱਚ ਕਿੱਥੇ ਫੇਲ ਹੁੰਦਾ ਹੈ—ਤਾਂ ਉਹ ਵਿਚਾਰ ਹੌਲੀ-ਹੌਲੀ ਗਲੀਆਂ ਦੀ ਚਰਚਾ, ਅੰਦਰੂਨੀ ਦਸਤਾਵੇਜ਼ਾਂ, ਅਤੇ ਮੀਟਅਪਸ ਵਿੱਚ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ।
Kubernetes ਦੇ ਕਾਫੀ ਸ਼ਬਦ ਹਨ ਜੋ ਸੁਣਨ 'ਚ ਜਾਣੂ ਲੱਗਦੇ ਹਨ ਪਰ ਖਾਸ ਮਤਲਬ ਰੱਖਦੇ ਹਨ: cluster, node, control plane, pod, service, deployment। ਜਦ ਵਿਆਖਿਆ ਸਪਸ਼ਟ ਹੋਵੇ, ਟੀਮਾਂ ਇਕ ਦੂਜੇ ਨਾਲ ਗਲਤਫਹਮੀ ਤੋਂ ਬਚਦੀਆਂ ਹਨ।
ਕੁਝ ਉਦਾਹਰਣ:
ਇਹ ਸਹਿਮਤੀ ਡੀਬੱਗਿੰਗ, ਯੋਜਨਾ ਅਤੇ ਓਨਬੋਰਡਿੰਗ ਤੇਜ਼ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਲੋਕ ਅਨੁਵਾਦ ਕਰਨ 'ਤੇ ਘੱਟ ਸਮਾਂ ਖਰਚ ਕਰਦੇ ਹਨ।
ਕਈ ਇੰਜੀਨੀਅਰ ਸ਼ੁਰੂ ਵਿੱਚ Kubernetes ਤੋਂ ਇਸ ਲਈ ਦੂਰ ਰਹਿੰਦੇ ਹਨ ਕਿ ਇਹ ਕਾਲਾ ਬਕਸਾ ਲੱਗਦਾ ਹੈ, ਨਾ ਕਿ ਉਹ ਨਹੀਂ ਸਿੱਖ ਸਕਦੇ। ਸਪਸ਼ਟ ਸਿਖਲਾਈ ਰਹਸ ਨੂੰ ਮਨ-ਮਾਡਲ ਨਾਲ ਬਦਲ ਦਿੰਦੀ ਹੈ: 'ਇਹ ਇੱਥੇ-ਇੱਥੇ ਗੱਲ ਕਰਦਾ ਹੈ, ਇਥੇ ਰਾਜ ਸਟੋਰ ਹੁੰਦਾ ਹੈ, ਟਰੈਫਿਕ ਇੰਝ ਰੂਟ ਹੁੰਦੀ ਹੈ'।
ਜਦ ਮਾਡਲ ਸਮਝ ਆ ਜਾਂਦਾ ਹੈ, ਤਜਰਬਾ ਸੁਰੱਖਿਅਤ ਲੱਗਦਾ ਹੈ। ਲੋਕ ਹੋਰ ਤਿਆਰ ਹੋ ਜਾਂਦੇ ਹਨ:
ਜਦ ਵਿਆਖਿਆ ਯਾਦਗਾਰ ਹੁੰਦੀ ਹੈ, ਕਮੇਨਿਊਨਟੀ ਉਸਨੂੰ ਦੁਹਰਾਉਂਦੀ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਡਾਇਗ੍ਰਾਮ ਜਾਂ ਰੂਪਕ ਸਿਖਾਉਣ ਦਾ ਡਿਫਾਲਟ ਤਰੀਕਾ ਬਣ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਪ੍ਰਭਾਵ ਪੈਂਦਾ ਹੈ:
ਸਮੇਂ ਦੇ ਨਾਲ, ਕਲਾਰਟੀ ਇੱਕ ਸੱਭਿਆਚਾਰਕ ਚੀਜ਼ ਬਣ ਜਾਂਦੀ ਹੈ: ਕਮੇਨਿਊਨਟੀ ਸਿੱਖਦੀ ਹੈ ਨਾ ਸਿਰਫ Kubernetes, ਪਰ ਉਸਨੂੰ ਚਲਾਉਣ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦਾ ਤਰੀਕਾ ਵੀ।
ਸਪਸ਼ਟ ਸੰਚਾਰ ਸਿਰਫ Kubernetes ਨੂੰ ਸਿੱਖਣਾ ਆਸਾਨ ਨਹੀਂ ਬਣਾਉਂਦਾ—ਇਹ ਉਸ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਕਿ ਸੰਸਥਾਵਾਂ ਨੇ ਅਪਨਾਉਣ 'ਤੇ ਫੈਸਲਾ ਕੀਤਾ। ਜਦ ਮੁਸ਼ਕਲ ਸਿਸਟਮ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਮਝਾਏ ਜਾਂਦੇ ਹਨ, ਮਾਨਿਆ ਗਿਆ ਖਤਰਾ ਘਟ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਟੀਮਾਂ ਨਫ਼ੇ ਦੀ ਗੱਲ ਕਰਨ ਲਗਦੀਆਂ ਹਨ ਜਗ੍ਹਾ ਜਾਰਗਨ ਦੀ।
ਐਕਸਿਕਿਊਟਿਵ ਅਤੇ IT ਨੇਤਾ ਅਕਸਰ ਹਰ ਤਨਖਾਹੀ ਵਿਸਥਾਰ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੇ, ਪਰ ਉਹ ਟਰੇਡ-ਆਫ਼ ਬਾਰੇ ਇੱਕ ਭਰੋਸੇਯੋਗ ਕਹਾਣੀ ਚਾਹੁੰਦੇ ਹਨ। Kubernetes ਦੇ ਸਪਸ਼ਟ ਅਤੇ ਸਹਿ-ਪਾਠ ਬਿਆਨ ਨੇ ਗੱਲਬਾਤਾਂ ਨੂੰ ਫਰੇਮ ਕੀਤਾ:
ਜਦ Kubernetes ਨੂੰ ਸਮਝਣਯੋਗ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਵਜੋਂ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ—ਨਾ ਕਿ ਕੋਈ ਜਾਦੂਈ ਪਲੇਟਫਾਰਮ—ਤਾਂ ਬਜਟ ਅਤੇ ਟਾਇਮਲਾਈਨ ਚਰਚਾ ਘੱਟ ਅਨੁਮਾਨਯੋਗ ਹੋ ਗਈ। ਇਸ ਨਾਲ ਪਾਇਲਟ ਚਲਾਉਣਾ ਤੇ ਅਸਲ ਨਤੀਜੇ ਮਾਪਣਾ ਅਸਾਨ ਹੋਇਆ।
ਉਦਯੋਗੀ ਅਪਨਾਉਣ ਸਿਰਫ ਵੇਂਡਰ ਪ੍ਰੇਜ਼ੈਂਟੇਸ਼ਨਾਂ ਰਾਹੀਂ ਨਹੀਂ ਫੈਲੀ; ਇਹ ਸਿੱਖਿਆ ਰਾਹੀਂ ਫੈਲੀ। ਉੱਚ-ਸੰਕੇਤ ਵਾਲੇ ਟਾਕ, ਡੈਮੋ ਅਤੇ ਪ੍ਰੈਕਟਿਕਲ ਗਾਈਡਾਂ ਨੇ ਕੰਪਨੀਆਂ ਅਤੇ ਨੌਕਰੀ ਭੂਮਿਕਾਾਂ ਵਿਚਕਾਰ ਇੱਕ ਸਾਂਝੀ ਸ਼ਬਦਾਵਲੀ ਬਣਾਈ।
ਉਹ ਸਿੱਖਿਆ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਅਪਨਾਉਣ ਤੇਜ਼ ਕਰਨ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਵਿੱਚ ਤਬਦੀਲ ਹੋਈ:
ਜਦ ਟੀਮਾਂ desired state, controllers ਅਤੇ rollout ਰਣਨੀਤੀ ਵਰਗੇ ਸੰਕਲਪਾਂ ਨੂੰ ਸਮਜ ਸਕਦੀਆਂ, ਤਾਂ Kubernetes ਗੱਲਬਾਤਯੋਗ ਬਣ ਗਿਆ—ਅਤੇ ਇਸ ਤੋਂ ਬਾਦ ਅਪਨਾਉਣਯੋਗ।
ਇੱਕ ਵਧੀਆ ਵਿਆਖਿਆ ਹਰ ਸੰਸਥਾਗਤ ਬਦਲਾਅ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈ ਸਕਦੀ। Kubernetes ਨੂੰ ਅਪਨਾਉਣਾ ਫਿਰ ਵੀ ਮੰਗਦਾ ਹੈ:
ਸੰਚਾਰ Kubernetes ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦਾ ਹੈ; ਸਫਲ ਅਪਨਾਉਣ ਲਈ ਫਿਰ ਵੀ ਵਚਨਬੱਧਤਾ, ਅਭਿਆਸ ਅਤੇ ਗਠਿਤ ਪ੍ਰੇਰਣਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
Kubernetes ਅਕਸਰ ਆਮ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ ਹੁੰਦਾ ਹੈ: ਲੋਕ ਦਿਨ-2 ਓਪਰੇਸ਼ਨ ਨੂੰ ਅਨੁਮਾਨ ਨਹੀਂ ਕਰਦੇ, ਉਹ ਜਾਣਦੇ ਨਹੀਂ ਕਿ ਪਹਿਲਾਂ ਕੀ ਸਿੱਖਣਾ ਹੈ, ਅਤੇ ਦਸਤਾਵੇਜ਼ ਇਹ ਮੰਨ ਕੇ ਲਿਖੇ ਜਾਂਦੇ ਹਨ ਕਿ ਹਰ ਕੋਈ 'ਕਲੱਸਟਰ' ਬੋਲਦਾ ਹੈ। ਪ੍ਰਾਇਕਟਿਕਲ ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਕਲਾਰਟੀ ਨੂੰ ਰੋਲਆਉਟ ਯੋਜਨਾ ਦਾ ਹਿੱਸਾ ਮੰਨੋ—ਇੱਕ ਬਾਅਦ ਦਾ ਸੋਚ ਨਾ ਬਣਾਓ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ 'ਕਿਵੇਂ Kubernetes ਵਰਤਣਾ ਹੈ' ਅਤੇ 'ਕਿਵੇਂ Kubernetes ਚਲਾਉਣਾ ਹੈ' ਨੂੰ ਮਿਲਾ ਜਾਂਦਾ ਹੈ। ਆਪਣੀ ਸਕੀਮ ਨੂੰ ਦੋ ਸਪਸ਼ਟ ਰਸਤੇ ਵਿੱਚ ਵੰਡੋ:
ਆਪਣੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀਆਂ ਸਿਰਤੋ ਇਹ ਵੰਡ ਰੱਖੋ ਤਾਂ ਕਿ ਨਵੇਂ ਨੌਜਵਾਨ ਗਲਤੀ ਨਾਲ ਡੂੰਘੇ ਪਾਣੀ ਵਿੱਚ ਨਾ ਘੁਸ ਜਾਣ।
ਡੈਮੋ ਨੂੰ ਸਭ ਤੋਂ ਛੋਟੇ ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਉਹ ਸਮੱਗਰੀ ਜੋ ਇਕ ਅਸਲ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਲਾਜ਼ਮੀ ਹੋ, ਜੋੜੀ ਜਾਵੇ।
ਇਕ Deployment ਅਤੇ Service ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਫਿਰ configuration, health checks, ਅਤੇ autoscaling ਜੋੜੋ। ਬੁਨਿਆਦਾਂ ਸਥਿਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ingress controllers, service meshes ਜਾਂ custom operators ਪੇਸ਼ ਕਰੋ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਲੋਕ ਕਾਰਨ-ਪਰਭਾਵ ਨੂੰ ਜੋੜਨ ਸਮਝਣ, ਨਾ ਕਿ YAML ਯਾਦ ਕਰਨਾ।
ਕੇਵਲ ਚੈੱਕਲਿਸਟ runbooks cargo-cult ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਹਰ ਮੁੱਖ ਜ਼ਰੂਰੀ ਕਦਮ ਦੇ ਨਾਲ ਇੱਕ ਇੱਕ-ਵਾਕ ਦੀ ਵਜਹ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਇਹ ਕਿਸ ਲਛਣ ਨੂੰ ਸਧਾਰਨ ਕਰਦਾ ਹੈ, ਸਫਲਤਾ ਦਾ ਕੀ ਮਿਆਰ ਹੈ, ਅਤੇ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।
ਉਦਾਹਰਣ: 'ਪੌਡ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰਨ ਨਾਲ ਇੱਕ ਫਸਿਆ ਹੋਇਆ ਕਨੈਕਸ਼ਨ ਪੂਲ ਸਾਫ਼ ਹੋ ਜਾਂਦਾ ਹੈ; ਜੇ ਇਹ 10 ਮਿੰਟ ਵਿੱਚ ਫਿਰੋਂ ਆ ਜਾਏ ਤਾਂ downstream latency ਅਤੇ HPA events ਚੈਕ ਕਰੋ।' ਉਹ 'ਕਿਉਂ' ਕਿਸੇ ਨੂੰ ਜਦ ਘਟਨਾ ਸਕ੍ਰਿਪਟ ਨਾਲ ਮਿਲਦੀ ਨਹੀਂ, improvisation ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਤੁਹਾਡੇ Kubernetes ਟ੍ਰੇਨਿੰਗ ਦੇ ਕੰਮ ਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਤੁਸੀਂ ਤਦੋ ਜਾਣੋਗੇ ਜਦ:
ਇਨ੍ਹਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਟਰੈਕ ਕਰੋ ਅਤੇ ਆਪਣੀਆਂ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ ਵਰਕਸ਼ਾਪਾਂ ਨੂੰ ਅਨੁਸਾਰ ਸੋਧੋ। ਕਲਾਰਟੀ ਇੱਕ ਡਿਲਿਵਰੇਬਲ ਹੈ—ਇਸ ਨੂੰ ਇੱਕ ਢੰਗ ਨਾਲ ਟ੍ਰੇਟ ਕਰੋ।
ਇਕ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਤਰੀਕਾ Kubernetes ਅਤੇ ਪਲੈਟਫਾਰਮ ਸੰਕਲਪਾਂ ਨੂੰ 'ਕਲਿਕ' ਬਣਾਉਣ ਲਈ ਇਸ ਗੱਲ ਨੂੰ ਟੀਮਾਂ ਨੂੰ ਵਾਸਤਾ ਕਰਨਾ ਹੈ ਕਿ ਉਹ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਛੁਹਣ ਤੋਂ ਪਹਿਲਾਂ ਹਕੀਕਤੀ ਸਰਵਿਸਾਂ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰ ਸਕਣ। ਇਸ ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਇੱਕ ਛੋਟੀ ਅੰਦਰੂਨੀ ਰੈਫਰੰਸ ਐਪ (API + UI + ਡਾਟਾਬੇਸ) ਬਣਾਉਣਾ, ਫਿਰ ਇਸਨੂੰ ਦਸਤਾਵੇਜ਼, ਡੈਮੋ ਅਤੇ ਟਰਬਲਸ਼ੂਟਿੰਗ ਡਰਿਲਜ਼ ਵਿੱਚ ਇੱਕ ਸਥਾਈ ਉਦਾਹਰਣ ਵਜੋਂ ਵਰਤਣਾ।
Platforms like Koder.ai ਇੱਥੇ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇੱਕ ਚੈਟ-ਚਲਿਤ ਸਪੈੱਕ ਤੋਂ ਇੱਕ ਚੱਲ ਰਹੀ ਵੈੱਬ ਐਪ, ਬੈਕਐਂਡ ਸਰਵਿਸ ਅਤੇ ਡਾਟਾ ਮਾਡਲ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ 'ਪਲੈਨਿੰਗ ਮੋਡ' ਵਿਚ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਿਸੇ ਪੂਰੇ YAML ਦੀ ਚਿੰਤਾ ਕੀਤੇ। ਮਕਸਦ Kubernetes ਸਿੱਖਣ ਨੂੰ ਬਦਲਣਾ ਨਹੀਂ—ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਖ਼ਿਆਲ → ਚਲ ਰਹੀ ਸੇਵਾ ਦਾ ਸਮਾਂ ਘਟ ਜਾਵੇ ਤਾਂ ਤੁਹਾਡੀ ਟ੍ਰੇਨਿੰਗ ਓਪਰੇਸ਼ਨਲ ਮਾਨਸਿਕ ਮਾਡਲ ('desired state', rollouts, observability, ਸੁਰੱਖਿਅਤ ਬਦਲਾਵ) 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰ ਸਕੇ।
ਕਲਾਉਡ-ਨੇਟਿਵ ਸਟੈਕ ਨਵੇਂ ਪ੍ਰਿਮਿਟਿਵ (ਪੌਡ, ਸਰਵਿਸ, ਕੰਟ੍ਰੋਲ ਪਲੇਨ) ਅਤੇ ਨਵੀਆਂ ਆਪਰੇਸ਼ਨਲ ਜਿੰਮੇਵਾਰੀਆਂ (ਅਪਗ੍ਰੇਡ, ਆਈਡੈਂਟੀਟੀ, ਨੈੱਟਵਰਕਿੰਗ) ਜੋੜਦੇ ਹਨ। ਜਦ ਟੀਮਾਂ ਇੱਕ ਸਾਂਝੇ ਖਾਕੇ ਨੂੰ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਸਮਝਦੀਆਂ, ਤਾਂ ਫੈਸਲੇ ਟਲਦੇ ਹਨ ਅਤੇ ਪਾਇਲਟ ਅੱਧੇ-ਟੂਟੇ ਹੀ ਰਹਿ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਲੋਕ ਟੂਲ ਨੂੰ ਆਪਣੇਅਸਲ ਖਤਰਾ ਅਤੇ ਵਰਕਫਲੋ ਨਾਲ ਜੁੜ ਕੇ ਨਹੀਂ ਦੇਖ ਸਕਦੇ।
ਸਾੱਫ਼ ਭਾਸ਼ਾ ਦੇ ਨਾਲ ਟਰੇਡ-ਆਫ਼ ਅਤੇ ਪਹਿਲੋਂ ਤੋਂ ਲੋੜੀਂਦੇ ਹਿੱਸੇ ਦਿਖ ਜਾਂਦੇ ਹਨ:
ਉਹ ਇਕ ਅਜਿਹਾ ਅਖ਼ਬਾਰੀ ਅਤੇ ਸਿੱਧਾ ਸੁਨੇਹਾ ਦੇਂਦੇ ਹਨ ਜੋ Kubernetes ਨੂੰ ਇੱਕ 'ਚਲਾਉਣਯੋਗ ਸਿਸਟਮ' ਵਜੋਂ ਵੇਖਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਕੋਈ ਜਾਦੂਈ ਉਤਪਾਦ। ਉਹ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਕੁਝ ਟੁੱਟ ਸਕਦਾ ਹੈ, ਕੀ ਤੁਹਾਡੀ ਜਿੰਮੇਵਾਰੀ ਹੈ, ਅਤੇ ਕੰਟਰੋਲ ਪਲੇਨ, ਨੈੱਟਵਰਕਿੰਗ, ਸੁਰੱਖਿਆ ਬਾਰੇ ਕਿਵੇਂ ਸੋਚਣਾ ਹੈ—ਉਹ ਮੋਹਰੇ ਜੋ ਟੀਮ ਅਕਸਰ ਘਟਨਾਵਾਂ ਦੌਰਾਨ ਸਿੱਖਦੇ ਹਨ, ਜੇ ਪਹਿਲਾਂ ਸਿਖਾਇਆ ਨਾ ਗਿਆ ਹੋਵੇ।
ਸ਼ੁਰੂ ਵਿੱਚ ਮਨ-ਮਾਡਲ ਬਦਲਣ ਕਰਕੇ ਮੁਸ਼ਕਲ ਹੋੰਦੀ ਸੀ:
ਜਦ ਟੀਮਾਂ ਇਹ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੀਆਂ ਕਿ 'ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਫਲੂਇਡ ਹੈ', ਤਾਂ ਸ਼ਬਦਾਵਲੀ ਨੂੰ ਠਿਕ ਥਾਂ 'ਚ ਰੱਖਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਡੈਮੋ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਹਕੀਕਤ ਵਿਚਕਾਰ ਫ਼ਰਕ:
ਡੈਮੋ 'ਡਿਪਲੋਯ ਅਤੇ ਸਕੇਲ' ਦਿਖਾਉਂਦੇ ਹਨ, ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਤੁਰੰਤ ਫੈਸਲੇ ਮੰਗਦਾ ਹੈ ਜਿਵੇਂ:
ਬਿਨਾਂ ਇਸ ਸੰਦਰਭ ਦੇ, Kubernetes ਇਕ ਵਾਅਦਾ ਲੱਗਦਾ ਹੈ ਜਿਸਦਾ ਨਕਸ਼ਾ ਨਹੀਂ।
ਇਹ ਮੂਲ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਹੱਥਾਂ-ਹੱਥ ਪਾਰਟਸ ਦੇ ਨੇੜੇ ਲਿਆਉਂਦਾ ਹੈ: ਸਰਟੀਫਿਕੇਟ, kubeconfigs, ਕੰਟਰੋਲ ਪਲੇਨ ਕੰਪੋਨੈਂਟ, ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ ਵਰਕਰ ਨੋਡ ਸੈਟਅਪ।
ਜੇਕਰ ਤੁਸੀਂ ਕਦੇ ਵੀ ਐਸਾ ਪ੍ਰਚਲਿਤ ਤਰੀਕਾ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਨਹੀਂ ਵਰਤੋਗੇ, ਇਹ ਅਭਿਆਸ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਹਰ ਹਿੱਸਾ ਕਿਸ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਅਤੇ ਗਲਤ ਕਨਫਿਗਰੈਸ਼ਨ 'ਤੇ ਕੀ-ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।
ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਨਤੀਜਾ ਲਿਖਦੇ ਹੋ, ਨਾ ਕਿ ਕਦਮ-ਦਰ-ਕਦਮ ਕਾਰਵਾਈ। ਉਦਾਹਰਣਾਂ:
Kubernetes ਲਗਾਤਾਰ ਇਸ ਵਰਣਨ ਨੂੰ ਹਕੀਕਤ ਨਾਲ ਮਿਲਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ, ਭਾਵੇਂ ਪੌਡਕ੍ਰੈਸ਼ ਹੋਣ ਜਾਂ ਨੋਡ ਗਾਇਬ ਹੋਣ।
Reconciliation ਹਮੇਸ਼ਾ ਚੱਲਦੀ ਰਹਿਣ ਵਾਲੀ ਜਾਂਚ-ਅਤੇ-ਠੀਕ ਕਰਨ ਦੀ ਲੂਪ ਹੈ: Kubernetes ਤੁਸੀਂ ਜੋ ਮੰਗਿਆ ਹੈ ਉਸਨੂੰ ਜੋ ਚਲ ਰਿਹਾ ਹੈ ਨਾਲ ਤુલਨਾ ਕਰਦਾ ਹੈ, ਫਿਰ ਖਾਂਚਾ ਬੰਦ ਕਰਨ ਲਈ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ.
ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਸੀ ਕਾਰਨ ਇੱਕ ਕਰੈਸ਼ ਹੋਇਆ ਪੌਡ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਕੇਲਿੰਗ ਸੈਟਿੰਗਸ ਸਮੇਂ ਸਮੇਂ 'ਤੇ ਲਾਗੂ ਬਣੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ—ਭਾਵੇਂ ਸਿਸਟਮ ਹੇਠਾਂ ਬਦਲ ਜਾਵੇ।
ਉਹਨਾਂ ਨੂੰ ਰੋਜ਼ਾਨਾ ਦੇ ਸਵਾਲਾਂ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਦਬਾਅ ਹੇਠ ਹੋਣ 'ਤੇ ਮਾਇਆ ਰੱਖਦੇ ਹਨ:
ਇਸ ਨਾਲ ops ਜਾਰਗਨ ਬਣਨ ਦੀ ਥਾਂ ਸਧਾਰਨ ਇੰਜੀਨੀਅਰਿੰਗ ਫੈਸਲੇ ਬਣ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਨ ਪੱਧਰ 'ਤੇ ਦੋ ਸਪష్ట ਟ੍ਰੈਕ ਬਣਾਓ:
ਫਿਰ ਸਿੱਖਿਆ ਨੂੰ ਨਤੀਜਿਆਂ ਦੁਆਰਾ ਵੈਰੀਫਾਈ ਕਰੋ (ਤੇਜ਼ ਇੰਸੀਡੈਂਟ ਟਰਾਇਅਜ, ਘੱਟ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਪ੍ਰਸ਼ਨ) ਨਾ ਕਿ ਸਿਰਫ ਹਾਜ਼ਰੀ ਨਾਲ।