ਕੁਬਰਨੇਟਸ 1.16: ਮੁੱਖ ਕਾਢਾਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ

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

ਇਸ ਸਮੱਗਰੀ ਨੂੰ ਤਿਆਰ ਕਰਨ ਲਈ ਵਰਤੀ ਗਈ ਜਾਣਕਾਰੀ ਤੋਂ ਲਈ ਗਈ ਹੈ ਕੁਬਰਨੇਟਸ ਇਨਹਾਂਸਮੈਂਟ ਟਰੈਕਿੰਗ ਟੇਬਲ, ਪਰਿਵਰਤਨ-1.16 ਅਤੇ ਸੰਬੰਧਿਤ ਮੁੱਦੇ, ਪੁੱਲ ਬੇਨਤੀਆਂ, ਅਤੇ ਕੁਬਰਨੇਟਸ ਐਨਹਾਂਸਮੈਂਟ ਪ੍ਰਸਤਾਵ (KEP)। ਇਸ ਲਈ, ਚਲੋ! ..

ਨੋਡਸ

K8s ਕਲੱਸਟਰ ਨੋਡਸ (Kubelet) ਦੇ ਸਾਈਡ 'ਤੇ ਇੱਕ ਸੱਚਮੁੱਚ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਨਵੀਨਤਾਵਾਂ (ਅਲਫ਼ਾ ਸੰਸਕਰਣ ਸਥਿਤੀ ਵਿੱਚ) ਪੇਸ਼ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।

ਪਹਿਲੀ, ਇਸ ਲਈ-ਕਹਿੰਦੇ «ਅਲੌਕਿਕ ਕੰਟੇਨਰ» (ਅਕਾਲਿਕ ਕੰਟੇਨਰ), ਪੌਡਾਂ ਵਿੱਚ ਡੀਬੱਗਿੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ. ਨਵੀਂ ਵਿਧੀ ਤੁਹਾਨੂੰ ਵਿਸ਼ੇਸ਼ ਕੰਟੇਨਰਾਂ ਨੂੰ ਲਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਜੋ ਮੌਜੂਦਾ ਪੌਡਾਂ ਦੇ ਨਾਮ-ਸਥਾਨ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ ਅਤੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਰਹਿੰਦੇ ਹਨ। ਉਹਨਾਂ ਦਾ ਉਦੇਸ਼ ਕਿਸੇ ਵੀ ਸਮੱਸਿਆ ਅਤੇ ਡੀਬੱਗ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਦੂਜੇ ਪੌਡਾਂ ਅਤੇ ਕੰਟੇਨਰਾਂ ਨਾਲ ਗੱਲਬਾਤ ਕਰਨਾ ਹੈ। ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ ਇੱਕ ਨਵੀਂ ਕਮਾਂਡ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ kubectl debug, ਸਾਰ ਵਿੱਚ ਸਮਾਨ kubectl exec: ਕੇਵਲ ਇੱਕ ਕੰਟੇਨਰ ਵਿੱਚ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਚਲਾਉਣ ਦੀ ਬਜਾਏ (ਜਿਵੇਂ ਕਿ ਵਿੱਚ exec) ਇਹ ਇੱਕ ਪੋਡ ਵਿੱਚ ਇੱਕ ਕੰਟੇਨਰ ਲਾਂਚ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇਹ ਕਮਾਂਡ ਇੱਕ ਨਵੇਂ ਕੰਟੇਨਰ ਨੂੰ ਇੱਕ ਪੋਡ ਨਾਲ ਜੋੜ ਦੇਵੇਗੀ:

kubectl debug -c debug-shell --image=debian target-pod -- bash

ਅਲੌਕਿਕ ਕੰਟੇਨਰਾਂ ਬਾਰੇ ਵੇਰਵੇ (ਅਤੇ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ) ਵਿੱਚ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ ਅਨੁਸਾਰੀ KEP. ਮੌਜੂਦਾ ਲਾਗੂਕਰਨ (K8s 1.16 ਵਿੱਚ) ਇੱਕ ਅਲਫ਼ਾ ਸੰਸਕਰਣ ਹੈ, ਅਤੇ ਇੱਕ ਬੀਟਾ ਸੰਸਕਰਣ ਵਿੱਚ ਇਸ ਦੇ ਟ੍ਰਾਂਸਫਰ ਲਈ ਮਾਪਦੰਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ "[ਕੁਬਰਨੇਟਸ] ਦੇ ਘੱਟੋ-ਘੱਟ 2 ਰੀਲੀਜ਼ਾਂ ਲਈ Ephemeral Containers API ਦੀ ਜਾਂਚ ਕਰਨਾ।"

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

ਇੱਕ ਹੋਰ ਨਵੀਨਤਾ - PodOverhead - ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ ਪੌਡਾਂ ਲਈ ਓਵਰਹੈੱਡ ਲਾਗਤਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਵਿਧੀ, ਜੋ ਕਿ ਵਰਤੇ ਗਏ ਰਨਟਾਈਮ ਦੇ ਆਧਾਰ 'ਤੇ ਬਹੁਤ ਬਦਲ ਸਕਦਾ ਹੈ। ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ, ਲੇਖਕ ਇਸ ਕੇ.ਈ.ਪੀ ਨਤੀਜੇ ਵਜੋਂ Kata ਕੰਟੇਨਰ, ਜਿਸ ਲਈ ਗੈਸਟ ਕਰਨਲ, ਕਾਟਾ ਏਜੰਟ, init ਸਿਸਟਮ, ਆਦਿ ਨੂੰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਓਵਰਹੈੱਡ ਇੰਨਾ ਵੱਡਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸ ਨੂੰ ਹੋਰ ਕੋਟਾ, ਯੋਜਨਾਬੰਦੀ ਆਦਿ ਲਈ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਵਿਚ ਲਾਗੂ ਕਰਨ ਲਈ PodSpec ਖੇਤਰ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ Overhead *ResourceList (ਵਿੱਚ ਡਾਟਾ ਨਾਲ ਤੁਲਨਾ ਕਰਦਾ ਹੈ RuntimeClass, ਜੇਕਰ ਇੱਕ ਵਰਤਿਆ ਗਿਆ ਹੈ).

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

ਟੌਪੋਲੋਜੀ ਮੈਨੇਜਰ ਕੰਪੋਨੈਂਟ ਡਾਇਗ੍ਰਾਮ

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

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

ਨੈੱਟ

ਕੁਬਰਨੇਟਸ 1.16 ਵਿੱਚ ਦੋ ਮਹੱਤਵਪੂਰਨ ਨੈੱਟਵਰਕਿੰਗ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜੋ ਪਹਿਲੀ ਵਾਰ (ਅਲਫ਼ਾ ਸੰਸਕਰਣ ਵਿੱਚ) ਪ੍ਰਗਟ ਹੋਈਆਂ ਹਨ:

• ਸਪੋਰਟ ਦੋਹਰਾ ਨੈੱਟਵਰਕ ਸਟੈਕ - IPv4/IPv6 - ਅਤੇ ਪੌਡਾਂ, ਨੋਡਾਂ, ਸੇਵਾਵਾਂ ਦੇ ਪੱਧਰ 'ਤੇ ਇਸਦੀ ਅਨੁਸਾਰੀ "ਸਮਝ"। ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ IPv4-to-IPv4 ਅਤੇ IPv6-ਤੋਂ-IPv6 ਪੌਡਾਂ ਵਿਚਕਾਰ ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ, ਪੌਡਾਂ ਤੋਂ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਤੱਕ, ਸੰਦਰਭ ਲਾਗੂਕਰਨ (ਬ੍ਰਿਜ CNI, PTP CNI ਅਤੇ ਹੋਸਟ-ਲੋਕਲ IPAM ਪਲੱਗਇਨਾਂ ਦੇ ਅੰਦਰ), ਅਤੇ ਨਾਲ ਹੀ ਰਿਵਰਸ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਚੱਲ ਰਹੇ ਹਨ। IPv4 ਜਾਂ IPv6 ਸਿਰਫ਼। ਲਾਗੂ ਕਰਨ ਦੇ ਵੇਰਵੇ ਵਿੱਚ ਹਨ KEP.

  ਪੌਡਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਦੋ ਕਿਸਮਾਂ (IPv4 ਅਤੇ IPv6) ਦੇ IP ਪਤਿਆਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਦੀ ਇੱਕ ਉਦਾਹਰਣ:

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• ਐਂਡਪੁਆਇੰਟ ਲਈ ਨਵਾਂ API - EndpointSlice API. ਇਹ ਮੌਜੂਦਾ ਐਂਡਪੁਆਇੰਟ API ਦੇ ਪ੍ਰਦਰਸ਼ਨ/ਸਕੇਲਬਿਲਟੀ ਮੁੱਦਿਆਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਜੋ ਕੰਟਰੋਲ-ਪਲੇਨ (ਏਪੀਸਰਵਰ, ਆਦਿ, ਐਂਡਪੁਆਇੰਟ-ਕੰਟਰੋਲਰ, ਕਿਊਬ-ਪ੍ਰੌਕਸੀ) ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਨਵੇਂ API ਨੂੰ ਡਿਸਕਵਰੀ API ਸਮੂਹ ਵਿੱਚ ਜੋੜਿਆ ਜਾਵੇਗਾ ਅਤੇ ਹਜ਼ਾਰਾਂ ਨੋਡਾਂ ਵਾਲੇ ਕਲੱਸਟਰ ਵਿੱਚ ਹਰੇਕ ਸੇਵਾ 'ਤੇ ਹਜ਼ਾਰਾਂ ਬੈਕਐਂਡ ਅੰਤਮ ਬਿੰਦੂਆਂ ਦੀ ਸੇਵਾ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਹਰੇਕ ਸੇਵਾ ਨੂੰ N ਆਬਜੈਕਟ ਨਾਲ ਮੈਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ EndpointSlice, ਜਿਸ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਮੂਲ ਰੂਪ ਵਿੱਚ 100 ਤੋਂ ਵੱਧ ਅੰਤ ਬਿੰਦੂ ਨਹੀਂ ਹੁੰਦੇ ਹਨ (ਮੁੱਲ ਸੰਰਚਨਾਯੋਗ ਹੈ)। ਐਂਡਪੁਆਇੰਟ ਸਲਾਈਸ API ਇਸਦੇ ਭਵਿੱਖ ਦੇ ਵਿਕਾਸ ਲਈ ਮੌਕੇ ਵੀ ਪ੍ਰਦਾਨ ਕਰੇਗਾ: ਹਰੇਕ ਪੌਡ ਲਈ ਮਲਟੀਪਲ IP ਐਡਰੈੱਸ ਲਈ ਸਮਰਥਨ, ਐਂਡਪੁਆਇੰਟ ਲਈ ਨਵੇਂ ਰਾਜ (ਨਾ ਸਿਰਫ਼ Ready и NotReady), ਅੰਤਮ ਬਿੰਦੂਆਂ ਲਈ ਗਤੀਸ਼ੀਲ ਸਬਸੈਟਿੰਗ।

ਆਖਰੀ ਰੀਲੀਜ਼ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਇੱਕ ਬੀਟਾ ਸੰਸਕਰਣ 'ਤੇ ਪਹੁੰਚ ਗਿਆ ਹੈ ਫਾਈਨਲਾਈਜ਼ਰ, ਨਾਮ ਦਿੱਤਾ ਗਿਆ service.kubernetes.io/load-balancer-cleanup ਅਤੇ ਕਿਸਮ ਦੇ ਨਾਲ ਹਰੇਕ ਸੇਵਾ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ LoadBalancer. ਅਜਿਹੀ ਸੇਵਾ ਨੂੰ ਮਿਟਾਉਣ ਦੇ ਸਮੇਂ, ਇਹ ਸਰੋਤ ਦੇ ਅਸਲ ਮਿਟਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਸਾਰੇ ਸੰਬੰਧਿਤ ਬੈਲੈਂਸਰ ਸਰੋਤਾਂ ਦੀ "ਸਫਾਈ" ਪੂਰੀ ਨਹੀਂ ਹੋ ਜਾਂਦੀ।

API ਮਸ਼ੀਨਰੀ

ਅਸਲ "ਸਥਿਰਤਾ ਮੀਲਪੱਥਰ" Kubernetes API ਸਰਵਰ ਦੇ ਖੇਤਰ ਵਿੱਚ ਹੈ ਅਤੇ ਇਸਦੇ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਹੈ। ਦੇ ਕਾਰਨ ਹੀ ਅਜਿਹਾ ਹੋਇਆ ਹੈ ਉਹਨਾਂ ਨੂੰ ਸਥਿਰ ਸਥਿਤੀ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਜਾਣ-ਪਛਾਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਕਸਟਮ ਰਿਸੋਰਸ ਪਰਿਭਾਸ਼ਾਵਾਂ (CRD), ਜਿਸ ਦੀ ਕੁਬਰਨੇਟਸ 1.7 ਦੇ ਦੂਰ ਦੇ ਦਿਨਾਂ ਤੋਂ ਬੀਟਾ ਸਥਿਤੀ ਹੈ (ਅਤੇ ਇਹ ਜੂਨ 2017 ਹੈ!) ਉਹੀ ਸਥਿਰਤਾ ਸੰਬੰਧਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਆਈ:

• "ਉਪ ਸਰੋਤ" ਤੱਕ /status и /scale ਕਸਟਮ ਸਰੋਤਾਂ ਲਈ;
• ਤਬਦੀਲੀ CRD ਲਈ ਸੰਸਕਰਣ, ਬਾਹਰੀ ਵੈਬਹੁੱਕ ਦੇ ਅਧਾਰ ਤੇ;
• ਹਾਲ ਹੀ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ (K8s 1.15 ਵਿੱਚ) ਡਿਫਾਲਟ ਮੁੱਲ (ਡਿਫਾਲਟਿੰਗ) ਅਤੇ ਆਟੋਮੈਟਿਕ ਫੀਲਡ ਹਟਾਉਣਾ (ਛਾਂਟਣੀ) ਕਸਟਮ ਸਰੋਤਾਂ ਲਈ;
• ਮੌਕਾ ਸਰਵਰ ਸਾਈਡ 'ਤੇ CRD ਸਰੋਤਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਂਦੇ OpenAPI ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਬਣਾਉਣ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ OpenAPI v3 ਸਕੀਮਾ ਦੀ ਵਰਤੋਂ ਕਰਨਾ।

ਇੱਕ ਹੋਰ ਵਿਧੀ ਜੋ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਕੁਬਰਨੇਟਸ ਪ੍ਰਸ਼ਾਸਕਾਂ ਲਈ ਜਾਣੂ ਹੋ ਗਈ ਹੈ: ਦਾਖਲਾ ਵੈਬਹੁੱਕ - ਲੰਬੇ ਸਮੇਂ ਲਈ ਬੀਟਾ ਸਥਿਤੀ ਵਿੱਚ ਵੀ ਰਿਹਾ (K8s 1.9 ਤੋਂ) ਅਤੇ ਹੁਣ ਸਥਿਰ ਘੋਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਦੋ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬੀਟਾ 'ਤੇ ਪਹੁੰਚ ਗਈਆਂ ਹਨ: ਸਰਵਰ-ਸਾਈਡ ਲਾਗੂ и ਬੁੱਕਮਾਰਕ ਵੇਖੋ.

ਅਤੇ ਅਲਫ਼ਾ ਸੰਸਕਰਣ ਵਿੱਚ ਸਿਰਫ ਮਹੱਤਵਪੂਰਨ ਨਵੀਨਤਾ ਸੀ ਨਾਮਨਜ਼ੂਰ ਤੱਕ SelfLink - ਇੱਕ ਖਾਸ URI ਜੋ ਨਿਸ਼ਚਿਤ ਆਬਜੈਕਟ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸਦਾ ਹਿੱਸਾ ਹੈ ObjectMeta и ListMeta (ਜਿਵੇਂ ਕਿ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਕਿਸੇ ਵੀ ਵਸਤੂ ਦਾ ਹਿੱਸਾ)। ਉਹ ਇਸ ਨੂੰ ਕਿਉਂ ਛੱਡ ਰਹੇ ਹਨ? ਇੱਕ ਸਧਾਰਨ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੇਰਣਾ ਆਵਾਜ਼ ਕਿਉਂਕਿ ਇਸ ਖੇਤਰ ਦੇ ਅਜੇ ਵੀ ਮੌਜੂਦ ਹੋਣ ਦੇ ਅਸਲ (ਵਧੇਰੇ) ਕਾਰਨਾਂ ਦੀ ਅਣਹੋਂਦ ਹੈ। ਵਧੇਰੇ ਰਸਮੀ ਕਾਰਨ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ (ਇੱਕ ਬੇਲੋੜੀ ਫੀਲਡ ਨੂੰ ਹਟਾ ਕੇ) ਅਤੇ ਜੈਨਰਿਕ-ਏਪੀਸਰਵਰ ਦੇ ਕੰਮ ਨੂੰ ਸਰਲ ਬਣਾਉਣਾ ਹੈ, ਜੋ ਕਿ ਅਜਿਹੇ ਖੇਤਰ ਨੂੰ ਇੱਕ ਖਾਸ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਇਹ ਇੱਕੋ ਇੱਕ ਖੇਤਰ ਹੈ ਜੋ ਆਬਜੈਕਟ ਤੋਂ ਪਹਿਲਾਂ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ। ਲੜੀਬੱਧ ਹੈ)। ਸੱਚੀ ਅਪ੍ਰਚਲਤਾ (ਬੀਟਾ ਦੇ ਅੰਦਰ) SelfLink ਕੁਬਰਨੇਟਸ ਸੰਸਕਰਣ 1.20, ਅਤੇ ਅੰਤਮ - 1.21 ਦੁਆਰਾ ਹੋਵੇਗਾ।

ਡਾਟਾ ਸਟੋਰੇਜ

ਸਟੋਰੇਜ ਦੇ ਖੇਤਰ ਵਿੱਚ ਮੁੱਖ ਕੰਮ, ਜਿਵੇਂ ਕਿ ਪਿਛਲੇ ਰੀਲੀਜ਼ਾਂ ਵਿੱਚ, ਖੇਤਰ ਵਿੱਚ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ CSI ਸਹਿਯੋਗ. ਇੱਥੇ ਮੁੱਖ ਤਬਦੀਲੀਆਂ ਸਨ:

• ਪਹਿਲੀ ਵਾਰ (ਅਲਫ਼ਾ ਸੰਸਕਰਣ ਵਿੱਚ) ਪ੍ਰਗਟ ਹੋਇਆ ਵਿੰਡੋਜ਼ ਵਰਕਰ ਨੋਡਾਂ ਲਈ CSI ਪਲੱਗਇਨ ਸਮਰਥਨ: ਸਟੋਰੇਜ਼ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਮੌਜੂਦਾ ਤਰੀਕਾ ਕੁਬਰਨੇਟਸ ਕੋਰ ਵਿੱਚ ਇਨ-ਟਰੀ ਪਲੱਗਇਨਾਂ ਅਤੇ ਪਾਵਰਸ਼ੇਲ 'ਤੇ ਅਧਾਰਤ ਮਾਈਕ੍ਰੋਸਾੱਫਟ ਤੋਂ ਫਲੈਕਸਵੋਲਿਊਮ ਪਲੱਗਇਨਾਂ ਨੂੰ ਵੀ ਬਦਲ ਦੇਵੇਗਾ;

  
  ਵਿੰਡੋਜ਼ ਲਈ ਕੁਬਰਨੇਟਸ ਵਿੱਚ CSI ਪਲੱਗਇਨ ਲਾਗੂ ਕਰਨ ਲਈ ਸਕੀਮ

• ਮੌਕਾ CSI ਵਾਲੀਅਮ ਨੂੰ ਮੁੜ ਆਕਾਰ ਦੇਣਾ, K8s 1.12 ਵਿੱਚ ਵਾਪਸ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ, ਇੱਕ ਬੀਟਾ ਸੰਸਕਰਣ ਬਣ ਗਿਆ ਹੈ;
• ਇੱਕ ਸਮਾਨ "ਤਰੱਕੀ" (ਅਲਫ਼ਾ ਤੋਂ ਬੀਟਾ ਤੱਕ) ਸਥਾਨਕ ਅਲਫ਼ਾਜ਼ ਵਾਲੀਅਮ ਬਣਾਉਣ ਲਈ CSI ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੀ ਗਈ ਸੀ (CSI ਇਨਲਾਈਨ ਵਾਲੀਅਮ ਸਪੋਰਟ).

ਕੁਬਰਨੇਟਸ ਦੇ ਪਿਛਲੇ ਸੰਸਕਰਣ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ ਵਾਲੀਅਮ ਕਲੋਨਿੰਗ ਫੰਕਸ਼ਨ (ਮੌਜੂਦਾ ਪੀਵੀਸੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ DataSource ਨਵੀਂ ਪੀਵੀਸੀ ਬਣਾਉਣ ਲਈ) ਨੂੰ ਵੀ ਹੁਣ ਬੀਟਾ ਸਥਿਤੀ ਪ੍ਰਾਪਤ ਹੋਈ ਹੈ।

ਸ਼ਡਿਊਲਰ

ਸਮਾਂ-ਸਾਰਣੀ ਵਿੱਚ ਦੋ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ (ਦੋਵੇਂ ਅਲਫ਼ਾ ਵਿੱਚ):

• EvenPodsSpreading - ਮੌਕਾ ਲੋਡਾਂ ਦੀ "ਨਿਰਪੱਖ ਵੰਡ" ਲਈ ਲਾਜ਼ੀਕਲ ਐਪਲੀਕੇਸ਼ਨ ਯੂਨਿਟਾਂ ਦੀ ਬਜਾਏ ਪੌਡ ਦੀ ਵਰਤੋਂ ਕਰੋ (ਜਿਵੇਂ ਕਿ ਡਿਪਲਾਇਮੈਂਟ ਅਤੇ ਰਿਪਲੀਕਾਸੈੱਟ) ਅਤੇ ਇਸ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਨੂੰ ਐਡਜਸਟ ਕਰਨਾ (ਸਖਤ ਲੋੜ ਜਾਂ ਨਰਮ ਸਥਿਤੀ ਦੇ ਤੌਰ 'ਤੇ, ਜਿਵੇਂ ਕਿ ਤਰਜੀਹ)। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਯੋਜਨਾਬੱਧ ਪੌਡਾਂ ਦੀ ਮੌਜੂਦਾ ਵੰਡ ਸਮਰੱਥਾਵਾਂ ਦਾ ਵਿਸਤਾਰ ਕਰੇਗੀ, ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ ਵਿਕਲਪਾਂ ਦੁਆਰਾ ਸੀਮਿਤ ਹੈ PodAffinity и PodAntiAffinity, ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਵਧੀਆ ਨਿਯੰਤਰਣ ਦੇਣਾ, ਜਿਸਦਾ ਅਰਥ ਹੈ ਬਿਹਤਰ ਉੱਚ ਉਪਲਬਧਤਾ ਅਤੇ ਅਨੁਕੂਲਿਤ ਸਰੋਤ ਖਪਤ। ਵੇਰਵੇ - ਵਿੱਚ KEP.
• ਵਰਤੋਂ ਕਰੋ ਬੈਸਟਫਿਟ ਨੀਤੀ в RequestedToCapacity Ratio ਤਰਜੀਹੀ ਫੰਕਸ਼ਨ ਪੌਡ ਦੀ ਯੋਜਨਾਬੰਦੀ ਦੇ ਦੌਰਾਨ, ਜੋ ਆਗਿਆ ਦੇਵੇਗੀ ਵਰਤਣ ਬਿਨ ਪੈਕਿੰਗ ("ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਪੈਕਿੰਗ") ਦੋਨਾਂ ਬੁਨਿਆਦੀ ਸਰੋਤਾਂ (ਪ੍ਰੋਸੈਸਰ, ਮੈਮੋਰੀ) ਅਤੇ ਵਿਸਤ੍ਰਿਤ ਸਰੋਤਾਂ (ਜਿਵੇਂ GPU) ਲਈ। ਹੋਰ ਵੇਰਵਿਆਂ ਲਈ, ਵੇਖੋ KEP.

  
  ਸ਼ਡਿਊਲਿੰਗ ਪੌਡ: ਸਭ ਤੋਂ ਵਧੀਆ ਫਿਟ ਨੀਤੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ (ਸਿੱਧਾ ਡਿਫੌਲਟ ਸ਼ਡਿਊਲਰ ਰਾਹੀਂ) ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਨਾਲ (ਸ਼ਡਿਊਲਰ ਐਕਸਟੈਂਡਰ ਰਾਹੀਂ)

ਇਸ ਦੇ ਇਲਾਵਾ, ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਮੁੱਖ ਕੁਬਰਨੇਟਸ ਡਿਵੈਲਪਮੈਂਟ ਟ੍ਰੀ (ਰੁੱਖ ਤੋਂ ਬਾਹਰ) ਦੇ ਬਾਹਰ ਤੁਹਾਡੇ ਆਪਣੇ ਸ਼ਡਿਊਲਰ ਪਲੱਗਇਨ ਬਣਾਉਣ ਦੀ ਸਮਰੱਥਾ।

ਹੋਰ ਬਦਲਾਅ

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਹੇਠ ਲਿਖੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਨੋਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

• ਵਿੰਡੋਜ਼ ਸਪੋਰਟ ਡਿਵੈਲਪਮੈਂਟ с ਦਿੱਖ ਇਸ OS (ਅਲਫ਼ਾ ਸੰਸਕਰਣ) ਲਈ Kubeadm ਉਪਯੋਗਤਾਵਾਂ, ਮੌਕਾ RunAsUserName ਵਿੰਡੋਜ਼ ਕੰਟੇਨਰਾਂ ਲਈ (ਐਲਫ਼ਾ ਸੰਸਕਰਣ), ਸੁਧਾਰ ਗਰੁੱਪ ਮੈਨੇਜਡ ਸਰਵਿਸ ਅਕਾਉਂਟ (gMSA) ਬੀਟਾ ਸੰਸਕਰਣ ਤੱਕ ਸਮਰਥਨ, ਸਮਰਥਨ vSphere ਵਾਲੀਅਮ ਲਈ ਮਾਊਂਟ/ਅਟੈਚ ਕਰੋ।
• ਰੀਸਾਈਕਲ ਕੀਤਾ API ਜਵਾਬਾਂ ਵਿੱਚ ਡੇਟਾ ਕੰਪਰੈਸ਼ਨ ਵਿਧੀ. ਪਹਿਲਾਂ, ਇਹਨਾਂ ਉਦੇਸ਼ਾਂ ਲਈ ਇੱਕ HTTP ਫਿਲਟਰ ਵਰਤਿਆ ਜਾਂਦਾ ਸੀ, ਜਿਸ ਨੇ ਕਈ ਪਾਬੰਦੀਆਂ ਲਗਾਈਆਂ ਸਨ ਜੋ ਇਸਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਮਰੱਥ ਹੋਣ ਤੋਂ ਰੋਕਦੀਆਂ ਸਨ। "ਪਾਰਦਰਸ਼ੀ ਬੇਨਤੀ ਕੰਪਰੈਸ਼ਨ" ਹੁਣ ਕੰਮ ਕਰਦਾ ਹੈ: ਗਾਹਕ ਭੇਜਣਾ Accept-Encoding: gzip ਸਿਰਲੇਖ ਵਿੱਚ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ GZIP-ਸੰਕੁਚਿਤ ਜਵਾਬ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਇਸਦਾ ਆਕਾਰ 128 KB ਤੋਂ ਵੱਧ ਹੈ। ਗੋ ਕਲਾਇੰਟਸ ਆਟੋਮੈਟਿਕਲੀ ਕੰਪਰੈਸ਼ਨ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ (ਲੋੜੀਂਦਾ ਸਿਰਲੇਖ ਭੇਜਣਾ), ਇਸਲਈ ਉਹ ਤੁਰੰਤ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਕਮੀ ਦਾ ਨੋਟਿਸ ਕਰਨਗੇ। (ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਲਈ ਮਾਮੂਲੀ ਸੋਧਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।)
• ਸੰਭਵ ਹੋ ਗਿਆ ਬਾਹਰੀ ਮੈਟ੍ਰਿਕਸ ਦੇ ਆਧਾਰ 'ਤੇ HPA ਨੂੰ/ਜ਼ੀਰੋ ਪੌਡ ਤੱਕ ਸਕੇਲਿੰਗ ਕਰਨਾ. ਜੇਕਰ ਤੁਸੀਂ ਵਸਤੂਆਂ/ਬਾਹਰੀ ਮੈਟ੍ਰਿਕਸ ਦੇ ਆਧਾਰ 'ਤੇ ਸਕੇਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਜਦੋਂ ਵਰਕਲੋਡ ਨਿਸ਼ਕਿਰਿਆ ਹੁੰਦੇ ਹਨ ਤਾਂ ਤੁਸੀਂ ਸਰੋਤਾਂ ਨੂੰ ਬਚਾਉਣ ਲਈ ਆਪਣੇ ਆਪ 0 ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਤੱਕ ਸਕੇਲ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਖਾਸ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਲਈ ਲਾਭਦਾਇਕ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿੱਥੇ ਕਰਮਚਾਰੀ GPU ਸਰੋਤਾਂ ਦੀ ਬੇਨਤੀ ਕਰਦੇ ਹਨ, ਅਤੇ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਵਿਹਲੇ ਕਰਮਚਾਰੀਆਂ ਦੀ ਗਿਣਤੀ ਉਪਲਬਧ GPU ਦੀ ਸੰਖਿਆ ਤੋਂ ਵੱਧ ਹੈ।
• ਨਵਾਂ ਗਾਹਕ - k8s.io/client-go/metadata.Client - ਵਸਤੂਆਂ ਤੱਕ "ਆਮ" ਪਹੁੰਚ ਲਈ। ਇਹ ਆਸਾਨੀ ਨਾਲ ਮੈਟਾਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ (ਅਰਥਾਤ ਉਪ ਭਾਗ metadata) ਕਲੱਸਟਰ ਸਰੋਤਾਂ ਤੋਂ ਅਤੇ ਉਹਨਾਂ ਨਾਲ ਕੂੜਾ ਇਕੱਠਾ ਕਰਨਾ ਅਤੇ ਕੋਟਾ ਕਾਰਜ ਕਰਨਾ।
• ਕੁਬਰਨੇਟਸ ਬਣਾਓ ਹੁਣ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ ਵਿਰਾਸਤ ਤੋਂ ਬਿਨਾਂ (“ਬਿਲਟ-ਇਨ” ਇਨ-ਟਰੀ) ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ (ਅਲਫ਼ਾ ਸੰਸਕਰਣ)।
• kubeadm ਸਹੂਲਤ ਲਈ ਜੋੜਿਆ ਗਿਆ ਪ੍ਰਯੋਗਾਤਮਕ (ਅਲਫ਼ਾ ਸੰਸਕਰਣ) ਕਾਰਜਾਂ ਦੌਰਾਨ ਅਨੁਕੂਲਿਤ ਪੈਚਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਯੋਗਤਾ init, join и upgrade. ਫਲੈਗ ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਹੋਰ ਜਾਣੋ --experimental-kustomize, ਵਿੱਚ ਵੇਖੋ KEP.
• ਐਪੀਸਰਵਰ ਲਈ ਨਵਾਂ ਅੰਤ ਬਿੰਦੂ - readyz, - ਤੁਹਾਨੂੰ ਇਸਦੀ ਤਿਆਰੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਨਿਰਯਾਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। API ਸਰਵਰ ਵਿੱਚ ਵੀ ਹੁਣ ਇੱਕ ਫਲੈਗ ਹੈ --maximum-startup-sequence-duration, ਤੁਹਾਨੂੰ ਇਸਦੇ ਰੀਸਟਾਰਟ ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
• ਦੋ Azure ਲਈ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸਥਿਰ ਐਲਾਨਿਆ: ਸਮਰਥਨ ਉਪਲਬਧਤਾ ਜ਼ੋਨ (ਉਪਲਬਧਤਾ ਜ਼ੋਨ) ਅਤੇ ਕਰਾਸ ਸਰੋਤ ਸਮੂਹ (ਆਰ.ਜੀ.)। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਜ਼ੁਰ ਨੇ ਸ਼ਾਮਲ ਕੀਤਾ ਹੈ:
  • ਪ੍ਰਮਾਣਿਕਤਾ ਸਹਿਯੋਗ AAD ਅਤੇ ADFS;
  • ਸਾਰਾਂਸ਼ service.beta.kubernetes.io/azure-pip-name ਲੋਡ ਬੈਲੈਂਸਰ ਦਾ ਜਨਤਕ IP ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ;
  • ਮੌਕਾ ਸੈਟਿੰਗਾਂ LoadBalancerName и LoadBalancerResourceGroup.
• AWS ਹੁਣ ਹੈ ਸਹਿਯੋਗ ਵਿੰਡੋਜ਼ 'ਤੇ EBS ਲਈ ਅਤੇ ਅਨੁਕੂਲਿਤ EC2 API ਕਾਲਾਂ DescribeInstances.
• ਕੁਬੇਡਮ ਹੁਣ ਸੁਤੰਤਰ ਹੈ ਪਰਵਾਸ ਕਰਦਾ ਹੈ CoreDNS ਸੰਸਕਰਣ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਵੇਲੇ CoreDNS ਸੰਰਚਨਾ।
• ਬਾਈਨਰੀਆਂ ਆਦਿ ਅਨੁਸਾਰੀ ਡੌਕਰ ਚਿੱਤਰ ਵਿੱਚ ਕੀਤਾ ਹੈ ਵਿਸ਼ਵ-ਐਗਜ਼ੀਕਿਊਟੇਬਲ, ਜੋ ਤੁਹਾਨੂੰ ਰੂਟ ਅਧਿਕਾਰਾਂ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ ਇਸ ਚਿੱਤਰ ਨੂੰ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਨਾਲ ਹੀ, etcd ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਿੱਤਰ ਰੋਕਿਆ etcd2 ਸੰਸਕਰਣ ਸਮਰਥਨ.
• В ਕਲੱਸਟਰ ਆਟੋਸਕੇਲਰ 1.16.0 ਬੇਸ ਇਮੇਜ ਦੇ ਤੌਰ 'ਤੇ ਡਿਸਟ੍ਰੋਲੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਸਵਿਚ ਕੀਤਾ ਗਿਆ, ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ ਗਿਆ, ਨਵੇਂ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ (ਡਿਜੀਟਲ ਓਸ਼ਨ, ਮੈਗਨਮ, ਪੈਕੇਟ) ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ।
• ਵਰਤੇ ਗਏ/ਨਿਰਭਰ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਅੱਪਡੇਟ: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

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

• «ਕੁਬਰਨੇਟਸ 1.15: ਮੁੱਖ ਕਾਢਾਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ";
• «ਕੁਬਰਨੇਟਸ 1.14: ਮੁੱਖ ਕਾਢਾਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ";
• «ਕੁਬਰਨੇਟਸ 1.13: ਮੁੱਖ ਕਾਢਾਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ";
• «ਕੁਬਰਨੇਟਸ 1.12: ਮੁੱਖ ਕਾਢਾਂ ਦੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ".

ਸਰੋਤ: www.habr.com