VPN-нің бүйір контейнеріне іске қосу ережесі мен істен шығу ережесі қажет

Pod туннель контейнерін қосымшадан бұрын іске қосады және алғашқы сұраныстар сәтті болады, бұл дәл мәселені жасыратын жағдай. Реттілік бір жарысты түзейді және туннель істен шыққаннан кейін төрт сағаттан соң қосымша бастайтын трафик туралы ештеңе айтпайды. Бұл екі бөлек шешім. Әдетте олардың тек біреуі ғана жобаланады.

Реттілік тек бірінші сұранысты шектейді

Kubernetes қайта іске қосылатын init контейнерлерден құрылған бүйір контейнердің өмірлік циклін қолдайды. Бұл модельде іске қосу пробасы туннель дайындық туралы хабарлағанша келесі инициализация қадамын ұстап тұра алады. Бұл нақты жақсарту, және оны кіру нүктесінің скриптіне sleep қосудың орнына әдейі пайдаланған жөн. Қақпа қаншалықты жақсы болса, ол тексеретін шарт та соншалықты жақсы.

Бұл модельден тыс, реттілік семантикасы сіз пайдаланатын орындалу ортасына немесе тәуелділік жүйесіне жатады және олардың сәйкес келуі міндетті емес. Басқа платформадан көшірілген орналастыру туннельді күтіп тұрғандай көрінуі мүмкін, себебі қосымша кездейсоқ баяу басталады. Бұл сол кепілдік емес және жүктеме кезінде істен шығады.

Қақпа нені бақылайтынын айтыңыз: процесс бар, интерфейс бар, handshake аяқталды. Олардың әрқайсысы «осы pod қажет ететін межелерге дейінгі деректер жолы жұмыс істейді» дегеннен әлсіз тұжырым.

Деректер жолын болжаудың орнына оны міндеттеңіз

Проба бір сәттегі тексеру, ал firewall сәттер арасында қолданылатын қасиет. Егер талап қосымша трафигінің туннельден ешқашан шықпауы болса, оны ортақ желілік аттар кеңістігінде қабылдау-немесе-тастау ережесі ретінде көрсету керек. Контейнерлерді іске қосу тәртібі бұл талапты көтере алмайды. Тек ереже ғана көтере алады.

Бір pod-тағы контейнерлер осы аттар кеңістігін бөліседі, сондықтан орындату нүктесі аттар кеңістігінің өзі. Не жазсаңыз да, ол туннельдің өз сыртқы байланысын қолжетімді қалдыруы керек, өйткені оны қосымшаны қорғау үшін блоктау қосымшаға қажет жолды кеседі.

Істен шығу саясатын анық шешіңіз: туннель сау болмаған кезде қосымша трафигі толығымен тоқтауы керек пе, әлде жалғасып, қорғалмаған деп белгіленуі керек пе? Екеуі де қорғауға болады және ешқайсысы контейнерлерді белгілі бір тәртіппен іске қосу арқылы алынбайды.

Атап өтпеген трафикті сынаңыз

Бақыланатын туннель ақауы кезінде жаңа сұраныс алып, оның сыртқа шығатынын қараңыз. Содан кейін шығу мекенжайы сынағы ешқашан тимейтін жолдар үшін тексеруді қайталаңыз: кластер ішіндегі DNS шешімі, IPv6 межелері және қоғамдық интернеттің орнына кластердің ішкі мекенжайлары арқылы қол жеткізілетін қызметтер. Туннель өлгеннен кейін де үнсіз жұмысын жалғастыратын жолдар осылар.

Шығу мекенжайының беті бір сұраныстың сол сәтте күткен жерге барғанын дәлелдейді. Ол басқа жолдарды түгендей алмайды, және сіз тексерген мен pod қол жеткізе алатын нәрсенің арасындағы алшақтық — қызықты ақаулар тұратын жер.

Сынақты тек таза іске қосудан кейін емес, бүйір контейнер қайта іске қосылғаннан кейін де қайталаңыз. Қайта іске қосылған туннель контейнері аттар кеңістігін маршруттар мен саясатпен аралық күйде қалдыруы мүмкін.

Орналастыру жазбасын жазыңыз

Орналастыру жазбаларына үш факт кіреді: дайындық сынағы және оның нені бақылайтыны, сол сынақ сәтсіз болғандағы қалпына келтіру әрекеті, және шығыс трафигін реттейтін міндеттеу ережесі. Бүйір контейнерлер құжаттамасы өмірлік цикл механизмін қамтиды және бұл саяси шешімді сізге қалдырады. Бұл бөлініс дұрыс, және саясаттың әдетте жоқ болуының себебі де осы.

Қорғаныспен шатастырылған денсаулық тексеруі — ең қымбат жасыл көрсеткіш, өйткені ол адамдардың сұрақ қоюын тоқтатады. Оны құжаттамада дәл атау бір сөйлемге тұрарлық және соны болдырмайды.

Соңында, қалпына келтіру жолын қосымша жұмыс істеп тұрғанда бір рет сынаңыз. Шығысты қалпына келтіру үшін pod-ты қайта жасауды талап ететін дизайн — бұл шешім, және ол сіз қабылдаған шешім болуы керек, ашқан нәрсеңіз емес.