ખાનગી 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 માર્ગને એવી વિનંતીનો દોષ ન લાગે જે તેણે કદી ઉપાડી નથી.

આગલો એન્જિનિયર પૂછશે કે ટનલ તૂટેલી છે કે નહીં. તમારી નોંધે તેનો જવાબ પહેલેથી આપી દેવો જોઈએ.