VPN સાઇડકારને સ્ટાર્ટ નિયમ અને ફેલ નિયમ જોઈએ છે

એક pod એપ પહેલાં ટનલ કન્ટેનર શરૂ કરે છે અને પ્રથમ વિનંતીઓ સફળ થાય છે, જે બરાબર એ જ કિસ્સો છે જે સમસ્યાને છુપાવે છે. ક્રમ એક રેસ ઠીક કરે છે અને ટનલ ફેલ થયા પછી ચાર કલાક પછી એપ જે ટ્રાફિક શરૂ કરે તે વિશે કંઈ કહેતો નથી. આ બે અલગ નિર્ણયો છે. સામાન્ય રીતે તેમાંથી ફક્ત એક જ ડિઝાઇન થાય છે.

ક્રમ ફક્ત પ્રથમ વિનંતીને અટકાવે છે

Kubernetes પુનઃશરૂ કરી શકાય તેવા init કન્ટેનરમાંથી બનેલી સાઇડકાર લાઇફસાઇકલને સપોર્ટ કરે છે. તે મોડેલમાં સ્ટાર્ટઅપ પ્રોબ ટનલ તૈયાર હોવાનું જાહેર ન કરે ત્યાં સુધી આગળના ઇનિશિયલાઇઝેશન પગલાને રોકી શકે છે. તે સાચો સુધારો છે, અને એન્ટ્રીપોઇન્ટ સ્ક્રિપ્ટમાં sleep ઉમેરવાને બદલે તેનો જાણી જોઈને ઉપયોગ કરવો યોગ્ય છે. ગેટ ફક્ત તેટલો સારો છે જેટલી તે ચકાસે છે તે શરત.

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

ગેટ શું નિરીક્ષણ કરે તે કહો: પ્રોસેસ છે, ઇન્ટરફેસ છે, હેન્ડશેક પૂર્ણ થઈ છે. તેમાંથી દરેક “આ pod ને જરૂરી લક્ષ્યો સુધીનો ડેટા પાથ કામ કરે છે” કરતાં નબળો દાવો છે.

ડેટા પાથને ધારવાને બદલે લાગુ કરો

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

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

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

તમે ઉલ્લેખ ન કર્યો તે ટ્રાફિકની પરીક્ષા કરો

નિયંત્રિત ટનલ ફેલ દરમિયાન નવી વિનંતી લો અને જુઓ કે તે બહાર જાય છે કે નહીં. પછી એ માર્ગો માટે તપાસનું પુનરાવર્તન કરો જેને એક્ઝિટ-એડ્રેસ ટેસ્ટ ક્યારેય સ્પર્શતું નથી: ક્લસ્ટરની અંદર DNS રિઝોલ્યુશન, IPv6 લક્ષ્યો, અને જાહેર ઇન્ટરનેટને બદલે ક્લસ્ટર-આંતરિક સરનામાંઓ દ્વારા પહોંચાતી સેવાઓ. આ એ માર્ગો છે જે ટનલ મર્યા પછી પણ શાંતિથી કામ કરતા રહે છે.

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

ફક્ત સ્વચ્છ શરૂઆત પછી જ નહીં, સાઇડકાર રીસ્ટાર્ટ પછી પણ ટેસ્ટનું પુનરાવર્તન કરો. રીસ્ટાર્ટ થયેલ ટનલ કન્ટેનર નેમસ્પેસને રૂટ્સ અને પોલિસી સાથે મધ્યવર્તી સ્થિતિમાં છોડી શકે છે.

ડિપ્લોયમેન્ટ રેકોર્ડ લખો

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

સુરક્ષા માની લેવાયેલી હેલ્થ ચેક સૌથી મોંઘો લીલો સંકેત છે, કારણ કે તે લોકોને પ્રશ્ન પૂછતા અટકાવે છે. દસ્તાવેજીકરણમાં તેને સચોટ રીતે નામ આપવાનો ખર્ચ એક વાક્ય છે અને તે અટકાવે છે.

છેલ્લે, એપ ચાલુ હોય ત્યારે રિકવરી માર્ગની એક વાર પરીક્ષા કરો. એગ્રેસ પુનઃસ્થાપિત કરવા pod ફરીથી બનાવવાની જરૂર પડે તેવી ડિઝાઇન એ એક નિર્ણય છે, અને તે તમે લીધેલો નિર્ણય હોવો જોઈએ, તમે શોધેલી વસ્તુ નહીં.