GKE પોડ VPN દ્વારા સ્થાનિક હોસ્ટ સુધી કેમ પહોંચી શકતા નથી

નોડથી પિંગ કામ કરે છે અને પોડથી નિષ્ફળ જાય છે, અને સ્થાનિક બાજુ કંઈ પણ પહોંચતું નથી. ટનલ અને માર્ગ બરાબર છે; તાર પરનું સ્રોત સરનામું નથી. આ બે સ્થિતિઓ વચ્ચેનો ફરક એ છે કે ક્લસ્ટર છોડતી વખતે પેકેટ પોતાને શું કહે છે, અને GKE નો તે અંગે પોતાનો મત છે. પદ્ધતિ masquerade અપવાદોની યાદી છે, અને તેને વાંચવા એક જ આદેશ પૂરતો છે.

કંઈ પણ બદલતા પહેલા અમલમાં રહેલી યાદી વાંચો

GKE એજન્ટ આપે છે જે દરેક ગંતવ્ય શ્રેણી માટે નક્કી કરે છે કે પોડની ટ્રાફિક બહાર જતી વખતે નોડના સરનામે ફરી લખાય કે નહીં. તેની પ્રદાન કરેલી ગોઠવણી ત્રણ RFC1918 બ્લોક, 10.0.0.0/8, 172.16.0.0/12 અને 192.168.0.0/16, અપવાદિત ગંતવ્યો તરીકે નામ આપે છે. તેથી પોડમાંથી સ્થાનિક 10.x હોસ્ટ પર મોકલો છો તે બધું પોડના પોતાના સરનામા સાથે જ નોડ છોડે છે. નોડની પોતાની ટ્રાફિક ફરી લખાતી નથી, અને એટલે જ તેની પિંગ કામ કરે છે.

ઉદ્દેશિત ગોઠવણી અને સ્થાપિત નિયમો વાંચો, કારણ કે તે મેળ ન ખાઈ શકે. kubectl -n kube-system get configmap ip-masq-agent -o yaml એજન્ટને શું કહેવાયું તે દર્શાવે છે, અને kubectl -n kube-system get pods -l k8s-app=ip-masq-agent તે લાગુ કરવા કંઈ ચાલી રહ્યું છે કે નહીં તે દર્શાવે છે. નોડ પર iptables-save | grep -i masq કર્નલમાં ખરેખર હાજર નિયમો દર્શાવે છે. જ્યારે ConfigMap એક વાત કહે અને નિયમો બીજી, ત્યારે શંકાસ્પદ નેટવર્ક નહીં, એજન્ટ હોય છે.

કેપ્ચરથી સ્રોત સરનામું ખાતરી કરો

યાદી બદલતા પહેલા કેપ્ચર કરો. એક જ ગંતવ્ય પર ફિલ્ટર આઉટપુટ વાંચવા યોગ્ય રાખે છે: tcpdump -ni any host 10.20.30.40.

તેને સામી બાજુ જે જણાવે છે તેની સાથે સરખાવો. સ્થાનિક બાજુનું કેપ્ચર જે પોડનું સરનામું દર્શાવે અને કોઈ જવાબ ન હોય તે વર્તુળ બંધ કરે છે: અપવાદ યાદી કોઈ ટનલ ખામી વિના અસમમિતિ સમજાવે છે. એક જ સ્રોત સરનામાના બે અવલોકન CNI વિશે અનુમાન કરવાનું બંધ કરવા પૂરતા છે.

અપવાદને પોડ CIDR સુધી મર્યાદિત કરો

સમર્થિત સુધારો અપવાદને દૂર કરવાને બદલે મર્યાદિત કરે છે: પોડ CIDR અપવાદિત રાખો અને 10.x જગ્યાનો બાકીનો ભાગ છોડી દો. તે યાદી એજન્ટના ConfigMap માં nonMasqueradeCIDRs હેઠળ છે, અને તેને બદલવું એ સંપાદન અને પછી રોલઆઉટ છે. પહોળી એન્ટ્રીને ક્લસ્ટરની વાસ્તવિક પોડ શ્રેણી સાથે બદલો, ક્લસ્ટરની અંદરની ટ્રાફિકને હજી જરૂર હોય તો બીજા ખાનગી બ્લોક રાખો, અને કારણ ન હોય તો resyncInterval જેમ છે તેમ રાખો. લાગુ કરો, એજન્ટના પોડ ફરી શરૂ થયા તેની ખાતરી કરો, અને કર્નલના નિયમો બદલાયા તેની ખાતરી કરો.

આ વાસ્તવિક અસર ત્રિજ્યા ધરાવતું આખા ક્લસ્ટરનું પરિવર્તન છે. તે લાગુ થયા પછી, પહેલા પોતાનું પોડ સ્રોત રાખતી ટ્રાફિક હવે નોડ પર ફરી લખાઈને આવે છે, તેથી તે પોડ સરનામાં પર આધારિત બધું અલગ મોકલનાર જુએ છે. ભોગ બનનારા પોડ સરનામાં નામ આપતા લોગ, પરવાનગી યાદીઓ અને સ્થાનિક ફાયરવોલ નિયમો છે, અને તે શાંતિથી નિષ્ફળ જાય છે. પરિવર્તનને સુધારા તરીકે નહીં, વર્તન પરિવર્તન તરીકે જાહેર કરો.

ઘણા નોડ પૂલ ધરાવતા ક્લસ્ટરમાં, એજન્ટ તે નોડ પર નિર્ધારિત છે કે નહીં જ્યાં અસરગ્રસ્ત પોડ ખરેખર ચાલે છે તે તપાસો. DaemonSet વગરનો પૂલ પોતાના જૂના નિયમો રાખે છે, અને ConfigMap માં તે દર્શાવતું કંઈ હશે નહીં.

વિકલ્પ અને તેની કિંમત

બીજો વિકલ્પ પોડ સરનામાં અકબંધ રાખે છે અને માર્ગને તેના વિશે શીખવે છે. પોડ CIDR Cloud VPN ના ટ્રાફિક પસંદગીકારોમાં જાય છે, અને સ્થાનિક બાજુને જવાબો ક્યાં જવું તે જાણવા માટે તેના માટે પરત માર્ગની જરૂર છે. આ કેટલાક સુરક્ષા મોડેલોની માંગેલી પોડ ઓળખ જાળવે છે, અને સામી બાજુએ સ્વીકારવાની રહેતી રાઉટિંગ અને ફાયરવોલ બંનેની વ્યાપ્તિ વધારે છે.

સોદો વાંચનક્ષમતા વિરુદ્ધ વ્યાપ્તિ છે. અનુવાદ સ્થાનિક બાજુને દરેક નોડ માટે એક સરનામું દર્શાવે છે, જે પરવાનગી યાદીમાં મૂકવું સહેલું છે અને કયા પોડે શું મોકલ્યું તે છુપાવે છે. અનુવાદ ન કરો તો પોડ સરનામું શરૂઆતથી અંત સુધી રહે છે, જે જવાબદારી નક્કી કરવા માટે સારું અને નવી શ્રેણી શીખવાની હોય તેવા માર્ગના દરેક ઉપકરણ માટે ખરાબ છે. કોઈ પણ વિકલ્પ Docker કે CNI ખામી નથી; બંને ઓપરેશનલ બિલ ધરાવતા રાઉટિંગ નિર્ણયો છે. તમારી ટીમ જેનું બિલ ભરી શકે તે પસંદ કરો, અને કેમ તે લખો.

ચકાસો અને પાછું ખેંચો

એ જ કેપ્ચર ફરી ચલાવો. તમારા સંપાદન પછી પણ નોડ-સ્તરીય કેપ્ચર પોડનું સરનામું છાપે તો, ConfigMap શું કહે તે ગમે તે, નિયમો કદી બદલાયા નથી. તાર જ વાસ્તવિકતા છે; બાકી બધું અનુમાન છે.

પછી વિરુદ્ધ દિશા તપાસો, કારણ કે આ પરિવર્તનોમાંથી અડધા ફક્ત બહારની દિશામાં ચકાસાય છે. ખાતરી કરો કે જવાબ વિનંતી મોકલનાર નોડ કે પોડ સુધી પહોંચે છે, અને ખાતરી કરો કે એપ્લિકેશને ફક્ત SYN લીધા વિના પૂર્ણ થયું. જવાબ વગરની વિનંતી દર્શાવતું કેપ્ચર સામી બાજુની રાઉટિંગ સમસ્યા છે, આ બાજુની masquerade સમસ્યા નથી.

પાછું ખેંચવું એટલે અગાઉનું ConfigMap, તે જ રીતે લાગુ કરીને, એ જ ખાતરી સાથે કે એજન્ટ ફરી શરૂ થયો અને નિયમો બદલાયા. પરિવર્તન રેકોર્ડમાં એક જાણીતી વિનંતીનું સ્રોત સરનામું પહેલા અને પછી રાખો, કારણ કે એ જ એક લીટી સાબિત કરે છે કે પરિવર્તને તમે કહ્યું તે કર્યું. GKE IP masquerade એજન્ટ માર્ગદર્શિકા ડિફોલ્ટ અને ConfigMap ક્ષેત્રોનું દસ્તાવેજીકરણ કરે છે. રોલઆઉટ પછી સ્રોત સરનામું ન બદલાય તો તે નોડ પર એજન્ટ ચાલતો નથી અને કેટલું પણ YAML સંપાદન તેને સુધારશે નહીં.