ਕੁਬਰਨੇਟਸ ਦੀ ਸਹੀ ਤੁਲਨਾ ਲਾਗੂ ਕਰੋ, ਬਦਲੋ ਅਤੇ ਪੈਚ ਕਰੋ

ਕੁਬਰਨੇਟਸ ਕੋਲ ਸਰੋਤਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਕਈ ਵਿਕਲਪ ਹਨ: ਲਾਗੂ ਕਰੋ, ਸੰਪਾਦਿਤ ਕਰੋ, ਪੈਚ ਕਰੋ ਅਤੇ ਬਦਲੋ। ਇਸ ਬਾਰੇ ਭੰਬਲਭੂਸਾ ਹੈ ਕਿ ਹਰ ਕੋਈ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਦੋਂ ਕਰਨੀ ਹੈ। ਆਓ ਇਸ ਨੂੰ ਬਾਹਰ ਕੱਢੀਏ।

ਜੇ ਗੂਗਲ 'ਤੇ ਖੋਜ ਕਰੋ ਵਾਕੰਸ਼ "ਕੁਬਰਨੇਟਸ ਲਾਗੂ ਬਨਾਮ ਬਦਲੋ" ਸਥਿਤ ਹੈ StackOverflow ਦਾ ਜਵਾਬ, ਜੋ ਸਹੀ ਨਹੀਂ ਹੈ। ਖੋਜ ਕਰਦੇ ਸਮੇਂ "kubernetes ਲਾਗੂ ਬਨਾਮ ਪੈਚ" ਲਈ ਪਹਿਲਾ ਲਿੰਕ ਦਸਤਾਵੇਜ਼ ਹੈ kubectl patch, ਜਿਸ ਵਿੱਚ ਤੁਲਨਾ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ apply и patch. ਇਹ ਲੇਖ ਵੱਖ-ਵੱਖ ਵਿਕਲਪਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਹਰੇਕ ਦੀ ਸਹੀ ਵਰਤੋਂ ਬਾਰੇ ਵੀ ਵਿਚਾਰ ਕਰੇਗਾ।

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

ਕੁਬਰਨੇਟਸ CLI

ਜੇਕਰ ਤੁਸੀਂ CLI ਰਾਹੀਂ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਤੋਂ ਜਾਣੂ ਹੋ apply и edit. ਟੀਮ apply ਫਾਈਲ ਤੋਂ ਸਰੋਤ ਨਿਰਧਾਰਨ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਲਈ "ਉੱਪਰ" ਬਣਾਉਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ. ਜੇਕਰ ਇਹ ਮੌਜੂਦ ਨਹੀਂ ਹੈ ਤਾਂ ਸਰੋਤ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਜੇਕਰ ਇਹ ਮੌਜੂਦ ਹੈ ਤਾਂ ਇਸਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ। ਟੀਮ edit API ਦੁਆਰਾ ਇੱਕ ਸਰੋਤ ਪੜ੍ਹਦਾ ਹੈ, ਫਿਰ ਇੱਕ ਸਥਾਨਕ ਫਾਈਲ ਵਿੱਚ ਸਰੋਤ ਨਿਰਧਾਰਨ ਲਿਖਦਾ ਹੈ, ਜੋ ਫਿਰ ਇੱਕ ਟੈਕਸਟ ਐਡੀਟਰ ਵਿੱਚ ਖੋਲ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਡੇ ਦੁਆਰਾ ਫਾਈਲ ਨੂੰ ਸੰਪਾਦਿਤ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, kubectl API ਰਾਹੀਂ ਕੀਤੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਵਾਪਸ ਭੇਜੇਗਾ, ਜੋ ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸਰੋਤ 'ਤੇ ਧਿਆਨ ਨਾਲ ਲਾਗੂ ਕਰੇਗਾ।

ਹਰ ਕੋਈ ਹੁਕਮਾਂ ਨੂੰ ਨਹੀਂ ਜਾਣਦਾ patch и replace. ਟੀਮ patch ਤੁਹਾਨੂੰ ਇੱਕ ਸਰੋਤ ਨਿਰਧਾਰਨ ਦਾ ਹਿੱਸਾ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਕਮਾਂਡ ਲਾਈਨ 'ਤੇ ਸਿਰਫ਼ ਬਦਲਿਆ ਹੋਇਆ ਹਿੱਸਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਟੀਮ replace ਵਾਂਗ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ edit, ਪਰ ਸਭ ਕੁਝ ਹੱਥੀਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ: ਤੁਹਾਨੂੰ ਸਰੋਤ ਨਿਰਧਾਰਨ ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਉਦਾਹਰਨ ਲਈ, kubectl get -o yaml, ਇਸ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰੋ, ਫਿਰ ਵਰਤੋਂ replace ਇੱਕ ਬਦਲੇ ਹੋਏ ਨਿਰਧਾਰਨ ਦੇ ਅਨੁਸਾਰ ਇੱਕ ਸਰੋਤ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਲਈ. ਟੀਮ replace ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ ਜੇਕਰ ਸਰੋਤ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਬਦਲਣ ਵਿੱਚ ਕੋਈ ਤਬਦੀਲੀ ਆਈ ਹੈ।

ਕੁਬਰਨੇਟਸ API

ਤੁਸੀਂ ਸ਼ਾਇਦ ਤਰੀਕਿਆਂ ਤੋਂ ਜਾਣੂ ਹੋ CoreV1().Pods().Update(), replaceNamespacedService ਜ patch_namespaced_deployment, ਜੇਕਰ ਤੁਸੀਂ ਕਲੱਸਟਰਾਂ ਨਾਲ ਇਸ ਰਾਹੀਂ ਕੰਮ ਕਰਦੇ ਹੋ Kubernetes API ਲਈ ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਕੁਝ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ. ਲਾਇਬ੍ਰੇਰੀ ਇਹਨਾਂ ਤਰੀਕਿਆਂ ਨੂੰ HTTP ਬੇਨਤੀਆਂ ਦੁਆਰਾ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੈਂਡਲ ਕਰਦੀ ਹੈ PUT и PATCH... ਜਿਸ ਵਿਚ update и replace ਵਰਤਣ PUTਅਤੇ patch, ਭਾਵੇਂ ਇਹ ਕਿੰਨੀ ਮਾਮੂਲੀ ਕਿਉਂ ਨਾ ਹੋਵੇ, ਵਰਤਦਾ ਹੈ PATCH.

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

ਮੂਲ ਰੂਪ ਵਿੱਚ ਪੈਚ

ਸਭ ਤੋਂ ਵਧੀਆ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ patch, ਜੇਕਰ ਤੁਸੀਂ ਸਰੋਤ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਇਸ ਤਰ੍ਹਾਂ ਦੋਵੇਂ ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀਆਂ Kubernetes API ਦੇ ਸਿਖਰ 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਅਤੇ kubectl (ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ, ਕਿਉਂਕਿ ਇਹ ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਲਈ ਇੱਕ ਰੈਪਰ ਹੈ, ਲਗਭਗ ਅਨੁਵਾਦਕ).

ਰਣਨੀਤਕ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰੋ

ਸਾਰੀਆਂ ਟੀਮਾਂ kubectl apply, edit и patch ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰੋ PATCH ਮੌਜੂਦਾ ਸਰੋਤ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ HTTP ਬੇਨਤੀਆਂ ਵਿੱਚ। ਜੇ ਤੁਸੀਂ ਕਮਾਂਡਾਂ ਨੂੰ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਦੀ ਖੋਜ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਸਾਰੇ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਰਣਨੀਤਕ-ਅਭੇਦ ਪੈਚਿੰਗ ਸਰੋਤਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ, ਹਾਲਾਂਕਿ ਕਮਾਂਡ patch ਹੋਰ ਤਰੀਕੇ ਵਰਤ ਸਕਦੇ ਹਨ (ਹੇਠਾਂ ਇਸ ਬਾਰੇ ਹੋਰ)। ਰਣਨੀਤਕ-ਅਭੇਦ ਪੈਚਿੰਗ ਪਹੁੰਚ ਮੌਜੂਦਾ ਨਿਰਧਾਰਨ ਨਾਲ ਸਪਲਾਈ ਕੀਤੇ ਨਿਰਧਾਰਨ ਨੂੰ ਮਿਲਾ ਕੇ "ਇਸ ਨੂੰ ਸਹੀ" ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ। ਵਧੇਰੇ ਖਾਸ ਤੌਰ 'ਤੇ, ਇਹ ਆਬਜੈਕਟ ਅਤੇ ਐਰੇ ਦੋਵਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤਬਦੀਲੀਆਂ ਜੋੜਨ ਲਈ ਹੁੰਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਕਮਾਂਡ ਚਲਾਉਣਾ patch ਪੌਡ ਕੰਟੇਨਰ ਨਿਰਧਾਰਨ ਵਿੱਚ ਇੱਕ ਨਵੇਂ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਦੇ ਨਾਲ, ਉਸ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਦੀ ਬਜਾਏ ਮੌਜੂਦਾ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹਟਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਨਿਰਧਾਰਨ ਵਿੱਚ ਪੈਰਾਮੀਟਰ ਮੁੱਲ ਨੂੰ ਰੱਦ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਕਿਹੜੀਆਂ ਟੀਮਾਂ ਵਿੱਚੋਂ kubectl ਕੀ ਅਪਡੇਟ ਕਰਨ ਲਈ ਵਰਤਣਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ?

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

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

ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਅੱਪਡੇਟ ਵਿਧੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਜੋ ਉਪਰੋਕਤ ਕਮਾਂਡਾਂ ਦੇ ਸਮਾਨ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ kubectl, ਬੇਨਤੀਆਂ ਵਿੱਚ ਸੈੱਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ content-type в application/strategic-merge-patch+json. ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਨਿਰਧਾਰਨ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਹਟਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਦੇ ਮੁੱਲਾਂ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਰੱਦ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। kubectl patch. ਜੇਕਰ ਤੁਹਾਨੂੰ ਐਰੇ ਐਲੀਮੈਂਟਸ ਨੂੰ ਹਟਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਅੱਪਡੇਟ ਨਿਰਧਾਰਨ ਵਿੱਚ ਅਭੇਦ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਅੱਪਡੇਟ ਲਈ ਇੱਕ ਵੱਖਰੀ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਅੱਪਡੇਟ ਲਈ ਹੋਰ ਪਹੁੰਚ

ਕੁਬਰਨੇਟਸ ਦੋ ਹੋਰ ਅੱਪਡੇਟ ਪਹੁੰਚਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ: JSON ਪੈਚ ਮਿਲਾਓ и JSON ਪੈਚ. JSON ਅਭੇਦ ਪੈਚ ਪਹੁੰਚ ਇੱਕ ਅੰਸ਼ਕ ਕੁਬਰਨੇਟਸ ਨਿਰਧਾਰਨ ਨੂੰ ਇਨਪੁਟ ਦੇ ਤੌਰ 'ਤੇ ਲੈਂਦੀ ਹੈ ਅਤੇ ਰਣਨੀਤਕ-ਅਭੇਦ ਪੈਚਿੰਗ ਪਹੁੰਚ ਦੇ ਸਮਾਨ ਮਿਲਾਉਣ ਵਾਲੀਆਂ ਵਸਤੂਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ। ਦੋਨਾਂ ਵਿੱਚ ਅੰਤਰ ਇਹ ਹੈ ਕਿ ਇਹ ਪੋਡ ਨਿਰਧਾਰਨ ਵਿੱਚ ਕੰਟੇਨਰ ਐਰੇ ਸਮੇਤ, ਐਰੇ ਬਦਲਣ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ JSON ਮਰਜ ਪੈਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਕੰਟੇਨਰ ਦੀ ਕੋਈ ਵਿਸ਼ੇਸ਼ਤਾ ਬਦਲਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਲਈ ਪੂਰੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ ਇਹ ਪਹੁੰਚ ਇੱਕ BOM ਵਿੱਚ ਇੱਕ ਐਰੇ ਤੋਂ ਤੱਤਾਂ ਨੂੰ ਹਟਾਉਣ ਲਈ ਉਪਯੋਗੀ ਹੈ। ਕਮਾਂਡ ਲਾਈਨ 'ਤੇ ਤੁਸੀਂ JSON ਮਰਜ ਪੈਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਚੁਣ ਸਕਦੇ ਹੋ kubectl patch --type=merge. Kubernetes API ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਬੇਨਤੀ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ PATCH ਅਤੇ ਇੰਸਟਾਲੇਸ਼ਨ content-type в application/merge-patch+json.

JSON ਪੈਚ ਪਹੁੰਚ, ਇੱਕ ਸਰੋਤ ਦਾ ਅੰਸ਼ਕ ਨਿਰਧਾਰਨ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਬਜਾਏ, ਉਹਨਾਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਇੱਕ ਐਰੇ ਵਜੋਂ ਸਰੋਤ ਵਿੱਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਜਿਸ ਵਿੱਚ ਐਰੇ ਦਾ ਹਰੇਕ ਤੱਤ ਸਰੋਤ ਵਿੱਚ ਕੀਤੇ ਜਾ ਰਹੇ ਬਦਲਾਅ ਦੇ ਵਰਣਨ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਇਹ ਪਹੁੰਚ ਕੀਤੇ ਜਾ ਰਹੇ ਪਰਿਵਰਤਨਾਂ ਨੂੰ ਪ੍ਰਗਟ ਕਰਨ ਦਾ ਇੱਕ ਵਧੇਰੇ ਲਚਕਦਾਰ ਅਤੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਤਰੀਕਾ ਹੈ, ਪਰ ਇੱਕ ਅੰਸ਼ਕ ਸਰੋਤ ਨਿਰਧਾਰਨ ਭੇਜਣ ਦੀ ਬਜਾਏ, ਇੱਕ ਵੱਖਰੇ, ਗੈਰ-ਕੁਬਰਨੇਟਸ ਫਾਰਮੈਟ ਵਿੱਚ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਨ ਦੀ ਕੀਮਤ 'ਤੇ। IN kubectl ਤੁਸੀਂ JSON ਪੈਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਚੁਣ ਸਕਦੇ ਹੋ kubectl patch --type=json. Kubernetes API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਪਹੁੰਚ ਬੇਨਤੀ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੰਮ ਕਰਦੀ ਹੈ PATCH ਅਤੇ ਇੰਸਟਾਲੇਸ਼ਨ content-type в application/json-patch+json.

ਸਾਨੂੰ ਭਰੋਸੇ ਦੀ ਲੋੜ ਹੈ - ਬਦਲਣ ਦੀ ਵਰਤੋਂ ਕਰੋ

ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਸਰੋਤ ਨੂੰ ਪੜ੍ਹੇ ਜਾਣ ਅਤੇ ਇਸਨੂੰ ਅੱਪਡੇਟ ਕੀਤੇ ਜਾਣ ਦੇ ਸਮੇਂ ਵਿੱਚ ਕੋਈ ਤਬਦੀਲੀ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਾਰੇ ਬਦਲਾਅ ਹੋਣਗੇ ਪਰਮਾਣੂ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਰੋਤਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ replace. ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਕਾਊਂਟਰ ਵਾਲਾ ConfigMap ਹੈ ਜੋ ਕਈ ਸਰੋਤਾਂ ਦੁਆਰਾ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਦੋ ਸਰੋਤ ਇੱਕੋ ਸਮੇਂ ਕਾਊਂਟਰ ਨੂੰ ਅੱਪਡੇਟ ਨਹੀਂ ਕਰਦੇ, ਜਿਸ ਨਾਲ ਅੱਪਡੇਟ ਗੁਆਚ ਜਾਂਦਾ ਹੈ। ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ, ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਘਟਨਾਵਾਂ ਦੇ ਕ੍ਰਮ ਦੀ ਕਲਪਨਾ ਕਰੋ patch:

• A ਅਤੇ B API ਤੋਂ ਸਰੋਤ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ
• ਹਰ ਇੱਕ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕਾਊਂਟਰ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਵਧਾ ਕੇ ਅਤੇ "ਅਪਡੇਟ ਕੀਤੇ-ਦੁਆਰਾ" ਨੋਟ ਵਿੱਚ ਕ੍ਰਮਵਾਰ "A" ਜਾਂ "B" ਜੋੜ ਕੇ ਨਿਰਧਾਰਨ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ।
• ਅਤੇ ਇਹ ਸਰੋਤ ਨੂੰ ਥੋੜਾ ਤੇਜ਼ੀ ਨਾਲ ਅਪਡੇਟ ਕਰਦਾ ਹੈ
• B ਸਰੋਤ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ

ਨਤੀਜੇ ਵਜੋਂ, ਅੱਪਡੇਟ A ਖਤਮ ਹੋ ਗਿਆ ਹੈ। ਆਖਰੀ ਕਾਰਵਾਈ patch ਜਿੱਤਦਾ ਹੈ, ਕਾਊਂਟਰ ਨੂੰ ਦੋ ਦੀ ਬਜਾਏ ਇੱਕ ਨਾਲ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ "ਅਪਡੇਟ ਕੀਤੇ-ਬਾਏ" ਨੋਟ ਦਾ ਮੁੱਲ "B" ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ "A" ਨਹੀਂ ਹੁੰਦਾ। ਆਓ ਉਪਰੋਕਤ ਦੀ ਤੁਲਨਾ ਕਰੀਏ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਅੱਪਡੇਟ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ replace:

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

ਉਪਰੋਕਤ ਸਥਿਤੀ ਵਿੱਚ, B ਨੂੰ ਸਰੋਤ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੋਵੇਗਾ, ਨਵੀਂ ਸਥਿਤੀ ਵਿੱਚ ਬਦਲਾਅ ਕਰਨਾ ਹੋਵੇਗਾ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਹੋਵੇਗੀ replace. ਇਹ ਕਾਊਂਟਰ ਨੂੰ ਦੋ ਦੁਆਰਾ ਵਧਾਏਗਾ ਅਤੇ ਅੰਤ ਵਿੱਚ "AB" ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ "ਅਪਡੇਟ ਕੀਤੇ-ਬਾਏ" ਨੋਟ ਦਾ ਕਾਰਨ ਬਣੇਗਾ।

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

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਦੋ ਕਮਾਂਡਾਂ, ਕ੍ਰਮਵਾਰ ਚਲਾਈਆਂ ਗਈਆਂ, ਸਫਲਤਾਪੂਰਵਕ ਚੱਲਣਗੀਆਂ, ਕਿਉਂਕਿ deployment.yaml ਸੰਪਤੀ ਸ਼ਾਮਿਲ ਨਹੀ ਹੈ .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

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

ਤੁਸੀਂ ਇੱਕ ਪੈਚ ਨਹੀਂ ਕਰ ਸਕਦੇ - ਅਸੀਂ ਇੱਕ ਬਦਲਦੇ ਹਾਂ

ਕਈ ਵਾਰ ਤੁਹਾਨੂੰ ਕੁਝ ਤਬਦੀਲੀਆਂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ API ਦੁਆਰਾ ਸੰਭਾਲੀਆਂ ਨਹੀਂ ਜਾ ਸਕਦੀਆਂ। ਇਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਤੁਸੀਂ ਸਰੋਤ ਨੂੰ ਮਿਟਾਉਣ ਅਤੇ ਮੁੜ-ਬਣਾਉਣ ਦੁਆਰਾ ਇਸਨੂੰ ਬਦਲਣ ਲਈ ਮਜਬੂਰ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਵਰਤ ਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ kubectl replace --force. ਕਮਾਂਡ ਨੂੰ ਚਲਾਉਣ ਨਾਲ ਸਰੋਤਾਂ ਨੂੰ ਤੁਰੰਤ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਸਪਲਾਈ ਕੀਤੇ ਨਿਰਧਾਰਨ ਤੋਂ ਮੁੜ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। API ਵਿੱਚ ਕੋਈ "ਫੋਰਸ ਰਿਪਲੇਸ" ਹੈਂਡਲਰ ਨਹੀਂ ਹੈ, ਅਤੇ API ਦੁਆਰਾ ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਦੋ ਓਪਰੇਸ਼ਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਇਸਦੇ ਲਈ ਸੈੱਟ ਕਰਕੇ ਸਰੋਤ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਲੋੜ ਹੈ gracePeriodSeconds ਜ਼ੀਰੋ (0) ਅਤੇ propagationPolicy "ਬੈਕਗ੍ਰਾਉਂਡ" ਵਿੱਚ ਅਤੇ ਫਿਰ ਲੋੜੀਂਦੇ ਨਿਰਧਾਰਨ ਨਾਲ ਇਸ ਸਰੋਤ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਓ।

ਚੇਤਾਵਨੀ: ਇਹ ਪਹੁੰਚ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਖ਼ਤਰਨਾਕ ਹੈ ਅਤੇ ਇੱਕ ਅਣ-ਪ੍ਰਭਾਸ਼ਿਤ ਸਥਿਤੀ ਵੱਲ ਲੈ ਜਾ ਸਕਦੀ ਹੈ।

ਸਰਵਰ ਸਾਈਡ 'ਤੇ ਲਾਗੂ ਕਰੋ

ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਕੁਬਰਨੇਟਸ ਡਿਵੈਲਪਰ ਤਰਕ ਨੂੰ ਲਾਗੂ ਕਰਨ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਨ apply ਤੱਕ kubectl Kubernetes API ਵਿੱਚ। ਤਰਕ apply ਕੁਬਰਨੇਟਸ 1.18 ਰਾਹੀਂ ਉਪਲਬਧ ਹੈ kubectl apply --server-side ਜਾਂ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ API ਦੁਆਰਾ PATCH с content-type application/apply-patch+YAML.

ਨੋਟ: JSON ਵੀ ਵੈਧ YAML ਹੈ, ਇਸਲਈ ਤੁਸੀਂ ਨਿਰਧਾਰਨ ਨੂੰ JSON ਵਜੋਂ ਭੇਜ ਸਕਦੇ ਹੋ ਭਾਵੇਂ content-type ਹੋ ਜਾਵੇਗਾ application/apply-patch+yaml.

ਉਸ ਤਰਕ ਤੋਂ ਇਲਾਵਾ kubectl API ਦੁਆਰਾ ਹਰ ਕਿਸੇ ਲਈ ਉਪਲਬਧ ਹੋ ਜਾਂਦਾ ਹੈ, apply ਸਰਵਰ ਸਾਈਡ 'ਤੇ, ਨਿਰਧਾਰਨ ਵਿੱਚ ਫੀਲਡਾਂ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਇਸ ਗੱਲ ਦਾ ਧਿਆਨ ਰੱਖਦਾ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਇਸਦੇ ਵਿਵਾਦ-ਮੁਕਤ ਸੰਪਾਦਨ ਲਈ ਸੁਰੱਖਿਅਤ ਮਲਟੀਪਲ ਐਕਸੈਸ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਜੇ apply ਸਰਵਰ ਸਾਈਡ 'ਤੇ ਵਧੇਰੇ ਵਿਆਪਕ ਹੋ ਜਾਵੇਗਾ, ਇੱਕ ਯੂਨੀਵਰਸਲ ਸੁਰੱਖਿਅਤ ਸਰੋਤ ਪ੍ਰਬੰਧਨ ਇੰਟਰਫੇਸ ਵੱਖ-ਵੱਖ ਕਲਾਇੰਟਾਂ ਲਈ ਦਿਖਾਈ ਦੇਵੇਗਾ, ਉਦਾਹਰਨ ਲਈ, kubectl, Pulumi ਜਾਂ Terraform, GitOps, ਅਤੇ ਨਾਲ ਹੀ ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਵੈ-ਲਿਖੀਆਂ ਸਕ੍ਰਿਪਟਾਂ।

ਨਤੀਜੇ

ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਸਰੋਤਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੇ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਬਾਰੇ ਇਹ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਤੁਹਾਡੇ ਲਈ ਮਦਦਗਾਰ ਸੀ। ਇਹ ਜਾਣਨਾ ਚੰਗਾ ਹੈ ਕਿ ਇਹ ਸਿਰਫ਼ ਲਾਗੂ ਬਨਾਮ ਬਦਲਣਾ ਨਹੀਂ ਹੈ; ਲਾਗੂ ਕਰੋ, ਸੰਪਾਦਿਤ ਕਰੋ, ਪੈਚ ਕਰੋ ਜਾਂ ਬਦਲੋ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਰੋਤ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਸੰਭਵ ਹੈ। ਆਖ਼ਰਕਾਰ, ਸਿਧਾਂਤ ਵਿੱਚ, ਹਰੇਕ ਪਹੁੰਚ ਦਾ ਆਪਣਾ ਕਾਰਜ ਖੇਤਰ ਹੁੰਦਾ ਹੈ. ਪਰਮਾਣੂ ਤਬਦੀਲੀਆਂ ਲਈ, ਬਦਲਣਾ ਬਿਹਤਰ ਹੈ; ਨਹੀਂ ਤਾਂ, ਤੁਹਾਨੂੰ ਅਪਲਾਈ ਰਾਹੀਂ ਰਣਨੀਤਕ-ਅਭੇਦ ਪੈਚ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਬਹੁਤ ਘੱਟ ਤੋਂ ਘੱਟ, ਮੈਂ ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹਾਂ ਕਿ "kubernetes apply vs replace" ਦੀ ਖੋਜ ਕਰਦੇ ਸਮੇਂ ਤੁਸੀਂ Google ਜਾਂ StackOerflow 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਘੱਟੋ ਘੱਟ ਜਦੋਂ ਤੱਕ ਇਹ ਲੇਖ ਮੌਜੂਦਾ ਜਵਾਬ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ.

ਸਰੋਤ: www.habr.com