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 එකේ ඔබ නිරීක්ෂණය කළේ කුමක්ද යන්න ලියන්න, එවිට ඊළඟ පුද්ගලයාට කතාවක් වෙනුවට සාක්ෂි උරුම වේ.