minikube ਨਿੱਜੀ API ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ? ਪਹਿਲਾਂ ਡਰਾਈਵਰ ਜਾਂਚੋ
ਹੋਸਟ, ਨੋਡ ਅਤੇ Pod—ਹਰ ਇੱਕ ਦੇ ਆਪਣੇ ਰੂਟ ਅਤੇ ਆਪਣਾ resolver ਹੈ। ਡਰਾਈਵਰ ਦਾ ਨਾਮ ਲਓ, ਉਹੀ endpoint ਤਿੰਨਾਂ ਤੋਂ ਜਾਂਚੋ, ਫਿਰ ਉਹ context ਠੀਕ ਕਰੋ ਜੋ ਫੇਲ੍ਹ ਹੋਇਆ।
ਇੱਕ ਨਿੱਜੀ API ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ minikube ਵਿੱਚ ਮੌਜੂਦ Pod ਉਸ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ। ਹੋਸਟ ਉੱਤੇ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਗਰਮ ਪ੍ਰੋਫਾਈਲ ਪਿੱਛੇ ਮੌਜੂਦ ਡਰਾਈਵਰ ਦਾ ਨਾਮ ਲਓ, ਕਿਉਂਕਿ ਇਹੀ ਇੱਕ ਤੱਥ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਅਸਲ ਵਿੱਚ ਕਿਸ ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ। ਫਿਰ ਉਹੀ endpoint ਹੋਸਟ ਤੋਂ, ਨੋਡ ਤੋਂ ਅਤੇ Pod ਤੋਂ ਜਾਂਚੋ। ਉਨ੍ਹਾਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਫੇਲ੍ਹ ਹੋਈ, ਅਤੇ ਗਲਤ ਅੰਦਾਜ਼ਾ ਇੱਕ ਦੁਪਹਿਰ ਬਰਬਾਦ ਕਰ ਦਿੰਦਾ ਹੈ।
ਕਦਮ 0: ਡਰਾਈਵਰ ਅਤੇ ਸਰੋਤ ਦਾ ਨਾਮ ਲਓ
minikube ਨੂੰ ਪੁੱਛੋ ਕਿ ਕਿਹੜੀ ਪ੍ਰੋਫਾਈਲ ਸਰਗਰਮ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਚੱਲ ਰਹੀ ਹੈ। ਕੰਟੇਨਰ ਡਰਾਈਵਰ ਨੋਡ ਨੂੰ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਉੱਤੇ ਇੱਕ ਕੰਟੇਨਰ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, VM ਡਰਾਈਵਰ ਇਸਨੂੰ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਰਿਮੋਟ ਡਰਾਈਵਰ ਇਸਨੂੰ ਬਿਲਕੁਲ ਕਿਤੇ ਹੋਰ ਰੱਖਦਾ ਹੈ।
minikube profile list
minikube status
kubectl config current-contextਇਸ ਤੋਂ ਲਿਖੋ ਕਿ ਬੇਨਤੀ ਕਿੱਥੋਂ ਆਉਂਦੀ ਹੈ। ਜਵਾਬ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸਦਾ resolver ਅਤੇ ਕਿਹੜੇ ਰੂਟ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਇਹ ਹਮੇਸ਼ਾ ਹੋਸਟ ਦਾ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕੋ ਲੈਪਟਾਪ ਉੱਤੇ ਦੋ ਪ੍ਰੋਫਾਈਲ ਇੱਕੋ URL ਲਈ ਬਿਲਕੁਲ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰ ਸਕਦੀਆਂ ਹਨ।
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod DNS through cluster services plus the cluster network path |
ਕਦਮ 1: ਉਹੀ endpoint ਤਿੰਨ ਵਾਰ ਜਾਂਚੋ
ਇੱਕ ਬੇਨੁਕਸਾਨ endpoint ਵਰਤੋ ਅਤੇ ਤਿੰਨਾਂ ਟੈਸਟਾਂ ਵਿੱਚ ਹੋਸਟਨਾਮ, ਪੋਰਟ ਅਤੇ ਐਡਰੈਸ ਫੈਮਿਲੀ ਇੱਕੋ ਜਿਹੇ ਰੱਖੋ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਰਨ ਵਿਚਕਾਰ ਬਦਲਣ ਨਾਲ ਨਤੀਜੇ ਤੁਲਨਾਯੋਗ ਨਹੀਂ ਰਹਿੰਦੇ।
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/healthਨੋਡ ਵੱਲੋਂ ਸਫਲ image pull ਨਿੱਜੀ ਹੋਸਟ ਲਈ ਨਾਮ ਹੱਲ ਹੋਣ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਸਫਲ ਜਨਤਕ ਬੇਨਤੀ ਹੋਰ ਵੀ ਘੱਟ ਸਾਬਤ ਕਰਦੀ ਹੈ। ਨਤੀਜਿਆਂ ਨੂੰ context ਅਨੁਸਾਰ ਵੱਖ ਰੱਖੋ, ਕਿਉਂਕਿ ਤਿੰਨ ਲਾਈਨਾਂ ਵਿੱਚ ਦਿਖਦਾ ਪੈਟਰਨ ਨਿਦਾਨ ਹੈ ਅਤੇ ਇਕੱਲੀ ਅਸਫਲਤਾ ਸੁਰਾਗ ਹੈ।
ਜੇ ਹੋਸਟ ਦੀ ਲਾਈਨ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਰੁਕੋ। ਤੁਹਾਡੇ ਕੋਲ ਹੋਸਟ ਦੀ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆ ਹੈ ਅਤੇ ਕਲਸਟਰ ਧਿਆਨ ਭਟਕਾਉਣ ਵਾਲੀ ਚੀਜ਼ ਹੈ।
ਕਦਮ 2: ਹੋਸਟ ਦਾ ਕਲਸਟਰ ਤੱਕ ਦਾ ਰਾਹ ਬਣਾਈ ਰੱਖੋ
ਲੋਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ ਅਜਿਹੀ ਦੂਜੀ ਦਿਸ਼ਾ ਹੈ: ਹੋਸਟ ਨੂੰ ਕਲਸਟਰ ਦੇ ਆਪਣੇ API ਅਤੇ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚਦੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। VPN ਕਲਾਇੰਟ ਅਜਿਹੇ ਰੂਟ ਲਗਾ ਸਕਦਾ ਹੈ ਜੋ minikube ਆਪਣੇ ਨੋਡ ਨੈੱਟਵਰਕ, ਸਰਵਿਸ ਰੇਂਜ ਅਤੇ pod ਰੇਂਜ ਲਈ ਵਰਤਦਾ ਹੈ, ਉਨ੍ਹਾਂ prefixes ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦੇ ਹਨ।
ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਲੱਛਣ ਉਲਝਾਉਣ ਵਾਲਾ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਟਨਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ kubectl ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ ਜਾਂ NodePort ਕਨੈਕਸ਼ਨ ਨਕਾਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਕਲਸਟਰ ਦੀ ਖਰਾਬੀ ਜਿਹਾ ਲੱਗਦਾ ਹੈ ਅਤੇ ਲੈਪਟਾਪ ਦੀ ਰਾਊਟਿੰਗ ਦੀ ਖਰਾਬੀ ਹੁੰਦਾ ਹੈ।
ਟਨਲ ਨੂੰ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਲਈ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਹੋਸਟ ਦੀ ਰਾਊਟਿੰਗ ਟੇਬਲ ਦੀ minikube ਦੀਆਂ ਰੇਂਜਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਓਵਰਲੈਪ ਆਮ ਤੌਰ 'ਤੇ ਵਧੇਰੇ ਵਿਸ਼ੇਸ਼ ਰੂਟ ਵਜੋਂ ਦਿਖਦਾ ਹੈ ਜੋ ਕਲਸਟਰ ਆਪਣਾ ਮੰਨਦੇ prefix ਲਈ ਟਨਲ ਇੰਟਰਫੇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
ਕਦਮ 3: VPN ਬੰਦ ਕੀਤੇ ਬਿਨਾਂ ਓਵਰਲੈਪ ਹੱਲ ਕਰੋ
minikube ਦੀ ਆਪਣੀ VPN ਅਤੇ proxy ਹੈਂਡਬੁੱਕ ਇਨ੍ਹਾਂ ਟਕਰਾਵਾਂ ਦੀ ਚਰਚਾ ਕਰਦੀ ਹੈ ਅਤੇ ਆਪਣੀਆਂ ਉਦਾਹਰਨ ਰੇਂਜਾਂ ਨੂੰ ਜਾਂਚਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਮੰਨਦੀ ਹੈ, ਸਰਵਵਿਆਪੀ ਸੂਚੀ ਨਹੀਂ। ਇਸਨੂੰ ਉਸ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਪੜ੍ਹੋ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਹੈ।
ਜਿੱਥੇ ਸੱਚਮੁੱਚ ਓਵਰਲੈਪ ਹੈ, ਉੱਥੇ ਸਮਰਥਿਤ ਜਵਾਬ ਇੱਕ ਗੈਰ-ਓਵਰਲੈਪਿੰਗ ਰੇਂਜ ਜਾਂ VPN ਦੇ ਮਾਲਕ ਵੱਲੋਂ ਮਨਜ਼ੂਰ ਕੀਤੀ ਜਾਣਬੁੱਝ ਕੇ ਬਣਾਈ ਸਥਾਨਕ ਪਹੁੰਚ ਨੀਤੀ ਹੈ। ਸਰਵਿਸ ਰੇਂਜ ਬਦਲਣਾ pod ਰੇਂਜ ਬਦਲਣ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨੋਡ ਨੈੱਟਵਰਕ ਬਦਲਣ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ।
ਸਥਾਨਕ ਕਲਸਟਰ ਚੱਲਣ ਲਈ ਕਾਰਪੋਰੇਟ ਟਨਲ ਬੰਦ ਕਰਨਾ ਕੋਈ ਸ਼ਾਰਟਕੱਟ ਨਹੀਂ ਹੈ; ਇਹ ਨੀਤੀ ਦਾ ਫੈਸਲਾ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ ਨੇ ਲੈਣਾ ਹੈ। ਬਾਕੀ ਸਾਰਿਆਂ ਦੇ ਘਰ ਜਾਣ ਤੋਂ ਬਾਅਦ ਚੁੱਪਚਾਪ ਕਰਨ ਦੀ ਬਜਾਏ ਇਸਨੂੰ ਉਸ ਵਿਅਕਤੀ ਕੋਲ ਲੈ ਜਾਓ। ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕਰ ਚੁੱਕੇ ਹੋ, ਤਾਂ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਪਸ ਲਗਾਓ।
ਕਦਮ 4: proxy, DNS ਅਤੇ ਅਸਫਲਤਾ ਦੇ ਚਾਰ ਰੂਪ ਵੱਖ ਕਰੋ
ਜੇ proxy ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਪਛਾਣੋ ਕਿ ਕਿਹੜੇ context ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ। ਹੋਸਟ ਉੱਤੇ ਬ੍ਰਾਊਜ਼ਰ ਸੈਟਿੰਗ ਨੋਡ ਦੇ ਅੰਦਰ ਕਿਸੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕੌਨਫਿਗਰ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ Pod ਨੂੰ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਜਾਂ ਕਲਸਟਰ-ਪੱਧਰੀ proxy ਕੌਨਫਿਗਰੇਸ਼ਨ ਚਾਹੀਦੀ ਹੈ।
ਫਿਰ ਅਸਫਲਤਾ ਦਾ ਵਰਣਨ ਕਰਨ ਦੀ ਬਜਾਏ ਵਰਗੀਕਰਨ ਕਰੋ। ਜੋ ਨਾਮ ਹੱਲ ਨਾ ਹੋਵੇ ਉਹ DNS ਹੈ। ਜੋ ਨਾਮ ਹੱਲ ਹੋਵੇ ਅਤੇ ਕਨੈਕਸ਼ਨ ਨਕਾਰੇ ਉਹ ਰਾਊਟਿੰਗ ਜਾਂ listener ਹੈ। ਜੋ ਕਨੈਕਸ਼ਨ ਬਣੇ ਅਤੇ ਪਛਾਣ ਉੱਤੇ ਫੇਲ੍ਹ ਹੋਵੇ ਉਹ TLS ਹੈ। ਗਲਤੀ ਦੇ body ਨਾਲ ਸਫਲ ਕਨੈਕਸ਼ਨ ਐਪਲੀਕੇਸ਼ਨ ਹੈ।
ਇਨ੍ਹਾਂ ਚਾਰਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰੀ ਸੁਧਾਈ ਨਾਲ ਸਬੰਧਤ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਇੱਕ VPN ਬਾਰੇ ਹੈ। ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਹਰ context ਵਿੱਚ ਕਿਹੜਾ ਦੇਖਿਆ, ਅਤੇ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਕਹਾਣੀ ਦੀ ਬਜਾਏ ਸਬੂਤ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਣਗੇ।