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 ನಲ್ಲಿ ಯಾವುದನ್ನು ಗಮನಿಸಿದಿರಿ ಎಂದು ಬರೆಯಿರಿ, ಮತ್ತು ಮುಂದಿನ ವ್ಯಕ್ತಿ ಕಥೆಯ ಬದಲು ಸಾಕ್ಷ್ಯಗಳನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತಾನೆ.