Страничният контейнер на VPN се нуждае от правило за стартиране и правило за отказ

Pod стартира контейнера на тунела преди приложението и първите заявки успяват — точно случаят, който скрива проблема. Подредбата покрива едно състезание и не казва нищо за трафика, който приложението започва четири часа по-късно, след като тунелът е отказал. Това са две отделни решения. Обикновено се проектира само едното.

Подредбата ограничава само първата заявка

Kubernetes поддържа жизнен цикъл на страничен контейнер, изграден от рестартиращи се init контейнери. В този модел стартова проба може да задържи следващата стъпка на инициализация, докато тунелът не отчете готовност. Това е истинско подобрение и си струва да се използва умишлено, вместо да се добавя sleep към скрипт за входна точка. Портата е само толкова добра, колкото е условието, което проверява.

Извън този модел семантиката на подредбата принадлежи на каквато среда за изпълнение или система за зависимости използвате и не е задължително да съвпада. Внедряване, копирано от друга платформа, може да изглежда, че чака тунела, защото приложението случайно стартира бавно. Това не е същата гаранция и се проваля под натоварване.

Кажете какво наблюдава портата: процес съществува, интерфейс съществува, ръкостискане е завършено. Всяко от тях е по-слабо твърдение от „пътят на данните до дестинациите, от които този pod се нуждае, работи“.

Налагайте пътя на данните, вместо да го предполагате

Пробата е проверка в един момент, а защитната стена е свойство, което важи между моментите. Ако изискването е трафикът на приложението никога да не излиза извън тунела, то трябва да бъде изразено в споделеното мрежово пространство от имена като правило за приемане или отхвърляне. Редът на стартиране на контейнерите не може да носи това изискване. Само правило може.

Контейнерите в един pod споделят това пространство от имена, затова точката на налагане е самото пространство от имена. Каквото и да напишете, то трябва да оставя достъпна собствената външна връзка на тунела, защото блокирането ѝ, за да защитите приложението, прерязва пътя, от който приложението се нуждае.

Решете политиката при отказ изрично: трябва ли трафикът на приложението да спре напълно, когато тунелът е нездрав, или да продължи и да бъде отбелязан като незащитен? И двете са защитими и нито едното не е това, което получавате, като стартирате контейнерите в определен ред.

Тествайте трафика, който не споменахте

Направете нова заявка при контролиран отказ на тунела и вижте дали излиза. След това повторете проверката за пътищата, които тестът на изходния адрес никога не докосва: разрешаване на DNS вътре в клъстера, дестинации по IPv6 и услуги, достигани през вътрешни за клъстера адреси, а не през публичния интернет. Това са пътищата, които тихо продължават да работят, след като тунелът умре.

Страницата с изходния адрес доказва, че една заявка е отишла там, където сте очаквали в онзи момент. Тя не може да направи опис на другите пътища и разликата между това, което сте тествали, и това, което pod може да достигне, е мястото, където живеят интересните откази.

Повторете теста след рестарт на страничния контейнер, а не само след чисто стартиране. Рестартиран контейнер на тунела може да остави пространството от имена с маршрути и политика в междинно състояние.

Запишете записа за внедряване

Три факта принадлежат в бележките за внедряване: тестът за готовност и какво наблюдава, действието за възстановяване, когато този тест се провали, и правилото за налагане, което управлява изходящия трафик. Документацията за странични контейнери обхваща механиката на жизнения цикъл и оставя това политическо решение на вас. Това разделение е правилно и точно затова политиката обикновено липсва.

Проверка за здраве, сбъркана със защита, е най-скъпият вид зелен индикатор, защото спира хората да задават въпроси. Точното ѝ назоваване в документацията струва едно изречение и предотвратява това.

Накрая, тествайте пътя за възстановяване веднъж, докато приложението работи. Дизайн, който изисква пресъздаване на pod, за да възстанови изходящия трафик, е решение и трябва да е това, което сте взели, а не това, което сте открили.