VPN-ի կողային կոնտեյներին պետք է մեկնարկի կանոն և ձախողման կանոն

Pod-ը մեկնարկում է թունելի կոնտեյները հավելվածից առաջ, և առաջին հարցումները հաջողվում են, ինչը հենց այն դեպքն է, որը թաքցնում է խնդիրը։ Հերթականությունը շտկում է մեկ մրցավազք և ոչինչ չի ասում այն տրաֆիկի մասին, որը հավելվածը սկսում է չորս ժամ անց՝ թունելի ձախողումից հետո։ Դրանք երկու առանձին որոշումներ են։ Սովորաբար նախագծվում է դրանցից միայն մեկը։

Հերթականությունը սահմանափակում է միայն առաջին հարցումը

Kubernetes-ը աջակցում է վերագործարկվող init կոնտեյներներից կառուցված կողային կոնտեյների կենսացիկլին։ Այդ մոդելում մեկնարկի զոնդը կարող է հետ պահել հաջորդ ինիցիալիզացիայի քայլը, մինչև թունելը հաղորդի պատրաստականության մասին։ Սա իսկական բարելավում է, և արժե այն օգտագործել գիտակցաբար՝ մուտքի կետի սկրիպտին sleep ավելացնելու փոխարեն։ Դարպասը այնքան լավն է, որքան լավն է այն պայմանը, որը նա ստուգում է։

Այդ մոդելից դուրս հերթականության իմաստաբանությունը պատկանում է այն runtime-ին կամ կախվածությունների համակարգին, որն օգտագործում եք, և դրանք պարտավոր չեն համընկնել։ Այլ հարթակից պատճենված տեղակայումը կարող է թվալ, թե սպասում է թունելին, որովհետև հավելվածը պատահաբար դանդաղ է մեկնարկում։ Սա նույն երաշխիքը չէ, և այն ձախողվում է ծանրաբեռնվածության տակ։

Ասեք, թե ինչ է դիտարկում դարպասը՝ գործընթաց կա, ինտերֆեյս կա, handshake-ը ավարտված է։ Դրանցից յուրաքանչյուրը ավելի թույլ պնդում է, քան «այս pod-ին անհրաժեշտ նպատակակետերի տվյալների ուղին աշխատում է»։

Պարտադրեք տվյալների ուղին՝ այն ենթադրելու փոխարեն

Զոնդը մեկ պահի ստուգում է, իսկ firewall-ը՝ պահերի միջև գործող հատկություն։ Եթե պահանջն այն է, որ հավելվածի տրաֆիկը երբեք դուրս չգա թունելից, ապա այն պետք է արտահայտվի ընդհանուր ցանցային անվանատարածքում որպես ընդունել-կամ-հեռացնել կանոն։ Կոնտեյներների մեկնարկի հերթականությունը չի կարող կրել այդ պահանջը։ Միայն կանոնը կարող է։

Մեկ pod-ի կոնտեյներները կիսում են այդ անվանատարածքը, ուստի պարտադրման կետը հենց անվանատարածքն է։ Ինչ էլ գրեք, այն պետք է հասանելի թողնի թունելի սեփական արտաքին կապը, որովհետև այն արգելափակելը հավելվածը պաշտպանելու համար կտրում է այն ուղին, որն անհրաժեշտ է հավելվածին։

Ձախողման քաղաքականությունը որոշեք բացահայտորեն՝ պե՞տք է հավելվածի տրաֆիկը ամբողջությամբ դադարի, երբ թունելը առողջ չէ, թե՞ շարունակվի և նշվի որպես անպաշտպան։ Երկուսն էլ արդարացված են, և ոչ մեկը չէ այն, ինչ ստանում եք կոնտեյներները որոշակի հերթականությամբ մեկնարկելով։

Փորձարկեք այն տրաֆիկը, որը չհիշատակեցիք

Վերցրեք նոր հարցում վերահսկվող թունելի ձախողման ընթացքում և տեսեք՝ այն դուրս է գալիս։ Այնուհետև կրկնեք ստուգումը այն ուղիների համար, որոնց ելքի հասցեի թեստը երբեք չի դիպչում՝ DNS լուծումը կլաստերի ներսում, IPv6 նպատակակետերը և ծառայությունները, որոնց հասնում են կլաստերի ներքին հասցեներով, այլ ոչ թե հանրային ինտերնետով։ Սրանք այն ուղիներն են, որոնք թունելի մահից հետո հանգիստ շարունակում են աշխատել։

Ելքի հասցեի էջը ապացուցում է, որ մեկ հարցում գնացել է այնտեղ, որտեղ դուք սպասում էիք այդ պահին։ Այն չի կարող գույքագրել մյուս ուղիները, և ձեր փորձարկածի ու pod-ի հասանելիքի միջև ընկած բացն է, որտեղ ապրում են հետաքրքիր ձախողումները։

Կրկնեք թեստը կողային կոնտեյների վերագործարկումից հետո, այլ ոչ միայն մաքուր մեկնարկից հետո։ Վերագործարկված թունելի կոնտեյները կարող է անվանատարածքը թողնել երթուղիներով և քաղաքականությամբ միջանկյալ վիճակում։

Գրեք տեղակայման գրառումը

Տեղակայման նշումներին պատկանում է երեք փաստ՝ պատրաստականության թեստը և այն, ինչ նա դիտարկում է, վերականգնման գործողությունը, երբ այդ թեստը ձախողվում է, և պարտադրման կանոնը, որը կարգավորում է ելքը։ Կողային կոնտեյներների փաստաթղթերը ընդգրկում են կենսացիկլի մեխանիկան և այդ քաղաքական որոշումը թողնում են ձեզ։ Այդ բաժանումը ճիշտ է, և դա էլ պատճառն է, որ քաղաքականությունը սովորաբար բացակայում է։

Պաշտպանության հետ շփոթված առողջության ստուգումը ամենաթանկ տեսակի կանաչ ցուցիչն է, որովհետև այն կանգնեցնում է մարդկանց հարցեր տալուց։ Փաստաթղթերում այն ճշգրիտ անվանելը արժե մեկ նախադասություն և կանխում է դա։

Վերջապես, մեկ անգամ փորձարկեք վերականգնման ուղին հավելվածը աշխատելիս։ Դիզայնը, որը պահանջում է pod-ի վերաստեղծում ելքը վերականգնելու համար, որոշում է, և այն պետք է լինի ձեր կայացրածը, ոչ թե ձեր հայտնաբերածը։