ਨਿੱਜੀ GKE ਨੋਡ ਇਹ ਤੈਅ ਨਹੀਂ ਕਰਦੇ ਕਿ kubectl ਕਿਹੜਾ API ਵਰਤਦਾ ਹੈ

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

ਪੰਜ ਜਾਂਚਾਂ, ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਇੱਕੋ ਮੁੱਲ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦਿਆਂ।

ਜਾਂਚ 1: kubeconfig ਵਿੱਚ ਸਰਵਰ URL ਪੜ੍ਹੋ

ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਡੋਲ੍ਹੇ ਬਿਨਾਂ ਐਂਡਪੌਇੰਟ ਛਾਪੋ: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}"। ਉਹ ਇੱਕ ਸਤਰ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕਿਸੇ IP ਪਤੇ, DNS ਨਾਮ ਜਾਂ ਤੁਹਾਡੇ ਬਿਨਾਂ ਇਰਾਦੇ ਦੇ ਬਾਹਰੀ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਰਿਹਾ ਹੈ। ਇਸ ਜਾਂਚ ਵਿੱਚ ਬਾਕੀ ਸਭ ਉਸੇ ਤੋਂ ਨਿਕਲਦਾ ਹੈ।

ਜੇ URL ਉਹ ਐਂਡਪੌਇੰਟ ਨਹੀਂ ਹੈ ਜੋ ਤੁਸੀਂ ਸੰਰਚਿਤ ਕੀਤਾ ਸਮਝਿਆ ਸੀ, ਤਾਂ ਬਾਕੀ ਨਿਦਾਨ ਸਿਰਫ਼ ਧਿਆਨ ਭਟਕਾਉਣਾ ਹੈ।

ਜਾਂਚ 2: URL ਨੂੰ ਐਂਡਪੌਇੰਟ ਦੀ ਕਿਸਮ ਨਾਲ ਮਿਲਾਓ

ਮੌਜੂਦਾ GKE IP-ਅਧਾਰਿਤ ਅਤੇ DNS-ਅਧਾਰਿਤ ਦੋਵੇਂ ਕੰਟਰੋਲ-ਪਲੇਨ ਪਹੁੰਚ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਵੱਲੋਂ ਲਏ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਚੁਣਦੇ ਹਨ। gcloud container clusters get-credentials NAME --location REGION --internal-ip ਅੰਦਰੂਨੀ IP ਐਂਡਪੌਇੰਟ ਲਿਖਦਾ ਹੈ, ਜਦਕਿ --dns-endpoint DNS-ਅਧਾਰਿਤ ਪਹੁੰਚ ਚੁਣਦਾ ਹੈ। ਕੋਈ ਵੀ ਫਲੈਗ ਨੈੱਟਵਰਕ ਰਾਹ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਜੋ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦਾ ਹੈ ਜੋ ਸਮਝਦੇ ਹਨ ਕਿ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਲੈਣ ਨਾਲ ਕਨੈਕਟੀਵਿਟੀ ਠੀਕ ਹੋ ਜਾਵੇਗੀ। ਜਾਣ-ਬੁੱਝ ਕੇ ਦੁਬਾਰਾ ਫੈਚ ਕਰੋ ਅਤੇ ਫਿਰ URL ਦੁਬਾਰਾ ਪੜ੍ਹੋ।

URL ਦੁਬਾਰਾ ਪੜ੍ਹੇ ਬਿਨਾਂ ਫਲੈਗ ਬਦਲਣਾ ਉਹੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਲੈਪਟਾਪ ਦੋ ਕਲਸਟਰਾਂ ਦੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਅਤੇ ਇੱਕ ਉਲਝਾਉਣ ਵਾਲੀ ਗਲਤੀ ਨਾਲ ਰਹਿ ਜਾਂਦਾ ਹੈ।

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

ਜਾਂਚ 3: ਉਸ ਐਂਡਪੌਇੰਟ ਤੱਕ ਦਾ ਰਾਹ ਸਾਬਤ ਕਰੋ

ਜੇ URL ਅੰਦਰੂਨੀ IP ਹੈ, ਤਾਂ ਜਿਸ ਨੈੱਟਵਰਕ ਉੱਤੇ ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਬੈਠਾ ਹੈ ਉੱਥੋਂ ਰੂਟ, ਮਨਜ਼ੂਰ ਸਰੋਤ ਰੇਂਜ ਅਤੇ ਕਲਸਟਰ ਦੀ ਖੇਤਰੀ ਜਾਂ ਗਲੋਬਲ ਪਹੁੰਚ ਸੈਟਿੰਗ ਜਾਂਚੋ। ਕੰਟਰੋਲ-ਪਲੇਨ ਰੇਂਜ ਅਤੇ ਨੋਡ ਸਬਨੈੱਟ ਇੱਕੋ ਮੰਜ਼ਿਲ ਨਹੀਂ ਹਨ, ਇਸ ਲਈ ਨੋਡਾਂ ਤੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰੂਟ ਐਂਡਪੌਇੰਟ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। DNS-ਅਧਾਰਿਤ ਪਹੁੰਚ ਲਈ ਰਾਹ ਦਸਤਾਵੇਜ਼ਬੱਧ Private Google Access ਪ੍ਰਬੰਧ ਨਾਲ Google API ਕਨੈਕਟੀਵਿਟੀ ਹੈ, ਵਰਕਰ ਸਬਨੈੱਟ ਤੱਕ ਰੂਟ ਨਹੀਂ। kubectl ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਧਾਰਨ TCP ਕਨੈਕਸ਼ਨ ਨਾਲ ਐਂਡਪੌਇੰਟ ਜਾਂਚੋ।

ਟਾਈਮਆਊਟ ਰਾਹ ਦੀ ਸਮੱਸਿਆ ਹੈ। 403 ਨੀਤੀ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਇਨ੍ਹਾਂ ਦਾ ਇੱਕੋ ਹੱਲ ਨਹੀਂ।

ਜਾਂਚ 4: ਲੌਗ ਅਤੇ exec ਨੂੰ API ਕਾਲਾਂ ਤੋਂ ਵੱਖ ਕਰੋ

ਜੇ ਆਮ API ਬੇਨਤੀਆਂ ਸਫਲ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ kubectl logs ਜਾਂ kubectl exec ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਐਂਡਪੌਇੰਟ ਚੋਣ ਤੋਂ ਅੱਗੇ ਲੰਘ ਚੁੱਕੇ ਹੋ। ਉਨ੍ਹਾਂ ਕਾਰਵਾਈਆਂ ਲਈ ਸੰਬੰਧਿਤ Kubernetes ਇਜਾਜ਼ਤਾਂ ਚਾਹੀਦੀਆਂ ਹਨ ਅਤੇ ਉਹ ਕੰਟਰੋਲ-ਪਲੇਨ ਤੋਂ ਨੋਡ ਤੱਕ ਸੰਚਾਰ ਉੱਤੇ ਨਿਰਭਰ ਹਨ, ਅਤੇ ਫੇਲ੍ਹ ਹੋਣਾ ਟਾਈਮਆਊਟ ਦੀ ਥਾਂ Forbidden ਜਵਾਬ ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਨੋਡ ਤੱਕ SSH ਪਹੁੰਚ ਬਿਲਕੁਲ ਵੱਖਰੀ ਸੇਵਾ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਥਾਪਤ ਨਹੀਂ ਕਰਦੀ।

VPN ਟਿਕਟ ਦੁਬਾਰਾ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਗਲਤੀ ਦੀ ਸ਼੍ਰੇਣੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਸ਼੍ਰੇਣੀਆਂ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ਉੱਤੇ ਰਹਿੰਦੀਆਂ ਹਨ।

ਜਾਂਚ 5: ਅਗਲੇ ਵਿਅਕਤੀ ਲਈ ਤਿੰਨ ਨਿਰੀਖਣ ਰੱਖੋ

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

ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਪੁੱਛੇਗਾ ਕਿ ਕੀ ਸੁਰੰਗ ਟੁੱਟੀ ਹੋਈ ਹੈ। ਤੁਹਾਡੇ ਨੋਟ ਵਿੱਚ ਇਸਦਾ ਜਵਾਬ ਪਹਿਲਾਂ ਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।