kubectl VPN ਉੱਤੇ ਕਿਉਂ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ AKS ਸਕੇਲਿੰਗ ਕਿਉਂ ਰੋਕ ਦਿੰਦਾ ਹੈ

ਤੁਸੀਂ ਦਫ਼ਤਰ ਦੇ VPN ਦਾ ਜਨਤਕ ਪਤਾ AKS API ਸਰਵਰ ਦੀ ਆਗਿਆ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਦੇ ਹੋ, ਅਤੇ kubectl ਕੰਮ ਕਰਦਾ ਹੈ। ਇੱਕ ਹਫ਼ਤੇ ਬਾਅਦ node pool ਦਾ ਸਕੇਲ-ਅੱਪ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, CI ਕੰਮ ਕਲਸਟਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ, ਅਤੇ ਪੋਰਟਲ ਉਹ ਗਲਤੀ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ IP ਰੇਂਜਾਂ ਦਾ ਕੋਈ ਜ਼ਿਕਰ ਨਹੀਂ। ਆਗਿਆ ਸੂਚੀ ਕਿਸੇ ਨੇ ਨਹੀਂ ਬਦਲੀ। ਤੁਸੀਂ ਜੋ ਨਿਯੰਤਰਣ ਚਾਲੂ ਕੀਤਾ ਹੈ ਉਹ API ਸਰਵਰ ਦੇ ਅੱਗੇ ਇੱਕ ਜਨਤਕ IP ਫਿਲਟਰ ਹੈ, ਅਤੇ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਕੌਣ ਕਾਲ ਕਰ ਰਿਹਾ ਹੈ, ਸਿਰਫ਼ ਇਹ ਜਾਣਦਾ ਹੈ ਕਿ ਕਾਲ ਕਿਸ ਪਤੇ ਤੋਂ ਆਈ। VPN ਕਲਸਟਰ ਨੂੰ ਲੋੜੀਂਦੇ ਕਈ ਪਤਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਟੁੱਟਣਾ ਉਹੀ ਹੋਵੇ, ਇਹ ਘੱਟ ਹੀ ਹੁੰਦਾ ਹੈ।

ਆਗਿਆ ਸੂਚੀ ਪਤੇ ਨਾਲ ਮਿਲਦੀ ਹੈ, ਵਿਅਕਤੀ ਨਾਲ ਨਹੀਂ

--api-server-authorized-ip-ranges ਇਹ CIDR ਬਲਾਕ ਲੈਂਦੀ ਹੈ, ਵਰਤੋਂਕਾਰ ਜਾਂ ਸਮੂਹ ਨਹੀਂ। ਜਦੋਂ ਡਿਵੈਲਪਰ ਦੀ ਬੇਨਤੀ VPN ਸਰਵਰ ਛੱਡ ਕੇ Azure ਵੱਲ ਜਾਂਦੀ ਹੈ, ਤਾਂ API ਸਰਵਰ ਉੱਤੇ ਸਰੋਤ ਪਤਾ VPN ਸਰਵਰ ਦਾ ਜਨਤਕ ਈਗ੍ਰੈਸ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ ਉਸ VPN ਉੱਤੇ ਹਰ ਵਿਅਕਤੀ ਇੱਕੋ ਐਂਟਰੀ ਸਾਂਝੀ ਕਰਦਾ ਹੈ, ਅਤੇ VPN ਤੋਂ ਬਾਹਰ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਨੂੰ ਪ੍ਰਮਾਣਿਕਤਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

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

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਟੁੱਟਣ ਵਾਲੀ ਚੀਜ਼ ਆਮ ਤੌਰ ਉੱਤੇ kubectl ਨਹੀਂ ਹੁੰਦੀ

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

ਘੱਟ ਸਪੱਸ਼ਟ ਮਾਮਲਾ ਉਹ ਆਟੋਮੇਸ਼ਨ ਹੈ ਜਿਸ ਨੂੰ Azure ਜਾਂ ਤੁਹਾਡੇ ਆਪਣੇ ਸਾਧਨ ਚਲਾਉਂਦੇ ਹਨ। ਪਲੇਟਫਾਰਮ ਵੱਲੋਂ ਸ਼ੁਰੂ ਕੀਤੇ ਕੁਝ ਓਪਰੇਸ਼ਨ ਤੁਹਾਡੇ VPN ਤੋਂ ਬਿਨਾਂ ਪਤਿਆਂ ਤੋਂ API ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਸੂਚੀ ਸਖ਼ਤ ਕਰਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਫੇਲ੍ਹ ਹੋਣ ਲੱਗੇ, ਤਾਂ ਸਮਾਂ ਹੀ ਸੁਰਾਗ ਹੈ। ਇੰਟਰਐਕਟਿਵ ਪਹੁੰਚ ਕੰਮ ਕਰਦੀ ਹੈ ਇਸ ਲਈ ਸੂਚੀ ਪੂਰੀ ਮੰਨ ਕੇ ਨਾ ਚੱਲੋ; ਕਲਸਟਰ ਖਰਾਬ ਹੈ ਦਾ ਨਤੀਜਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਖੇਤਰ ਅਤੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ ਲਈ ਇਸ ਸੁਵਿਧਾ ਦੀ ਲੋੜ ਜਾਂਚੋ।

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

ਪੂਰੀ ਸੂਚੀ ਇੱਕ ਹੀ ਕਮਾਂਡ ਵਿੱਚ ਬਣਾਓ

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

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

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

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

ਆਗਿਆ ਸੂਚੀ ਨੇ ਕਦੇ ਕੀ ਨਹੀਂ ਢਕਿਆ

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

ਇਸ ਦਾ ਵਰਕਲੋਡ ਨਾਲ ਕੋਈ ਸਬੰਧ ਨਹੀਂ। ਸੂਚੀ ਚਾਲੂ ਹੋਣ ਉੱਤੇ ਵੀ Pods ਅਤੇ Services ਚੱਲਦੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ VPN ਰਾਹੀਂ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚਣਾ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹੈ: ਜਿਸ Service ਕੋਲ ਸਿਰਫ਼ ਕਲਸਟਰ IP ਹੈ, ਉਸ ਨੂੰ ਲੈਪਟੌਪ ਦੇ ਖੋਲ੍ਹ ਸਕਣ ਤੋਂ ਪਹਿਲਾਂ ਅਜੇ ਵੀ ਅੰਦਰੂਨੀ ਲੋਡ ਬੈਲੈਂਸਰ, ingress ਜਾਂ port-forward ਚਾਹੀਦਾ ਹੈ। ਇਹਨਾਂ ਦੋ ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਉਹ ਬਦਲਾਅ ਟਿਕਟ ਬਣਦੀ ਹੈ ਜੋ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸੀਮਤ ਕਰਨ ਦਾ ਦਾਅਵਾ ਕਰਦੀ ਹੈ ਅਤੇ ਅਸਲ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਾਰੇ ਕੁਝ ਵੀ ਸੀਮਤ ਨਹੀਂ ਕਰਦੀ।

ਦੋਵਾਂ ਪਾਸਿਆਂ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਇੱਕ ਅਸਲੀ ਕਾਰਵਾਈ ਚਲਾਓ

VPN ਉੱਤੇ ਨਵੇਂ ਕਲਾਇੰਟ ਅਤੇ ਇਸ ਤੋਂ ਬਾਹਰਲੇ ਕਲਾਇੰਟ ਨਾਲ ਪਰਖੋ। ਬਾਹਰਲੀ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਨਾਮ ਹੱਲ ਉੱਤੇ ਨਹੀਂ, API ਸਰਵਰ ਉੱਤੇ ਰੱਦ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ; ਜੇ ਨਾਮ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਤੁਸੀਂ DNS ਪਰਖ ਰਹੇ ਹੋ ਅਤੇ ਫਿਲਟਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਸਿੱਖਿਆ। ਫਿਰ ਅਜਿਹੀ ਕਾਰਵਾਈ ਚਲਾਓ ਜੋ ਇੰਟਰਐਕਟਿਵ kubectl ਕਾਲ ਨਹੀਂ, ਜਿਵੇਂ node pool ਸਕੇਲ ਜਾਂ ਅੱਪਗ੍ਰੇਡ ਜਾਂਚ, ਅਤੇ ਹੋ ਜਾਵੇਗਾ ਮੰਨਣ ਦੀ ਬਜਾਏ ਪੂਰਾ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

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