පුද්ගලික 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 මාර්ගයක් දොස් නැගීම වළක්වයි.

ඊළඟ ඉංජිනේරුවා විමසන්නේ උමං බිඳී ඇත්ද කියාය. ඔබේ සටහන එයට දැනටමත් පිළිතුරු දී තිබිය යුතුය.