Страничниот контејнер на VPN бара правило за стартување и правило за неуспех

Pod го стартува контејнерот на тунелот пред апликацијата и првите барања успеваат, што е токму случајот што го крие проблемот. Редоследот решава една трка и не кажува ништо за сообраќајот што апликацијата го започнува четири часа подоцна, откако тунелот откажал. Тоа се две одделни одлуки. Обично се дизајнира само едната.

Редоследот го ограничува само првото барање

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

Надвор од тој модел, семантиката на редоследот им припаѓа на околината за извршување или системот за зависности што го користите и не мора да се совпаѓаат. Распоредување копирано од друга платформа може да изгледа како да го чека тунелот зашто апликацијата случајно стартува бавно. Тоа не е истата гаранција и пропаѓа под оптоварување.

Кажете што набљудува портата: постои процес, постои интерфејс, handshake е завршен. Секое од тие е послаба тврдња од „патеката на податоци до дестинациите што му се потребни на овој pod работи“.

Наметнете ја патеката на податоци наместо да ја претпоставувате

Пробата е проверка во еден момент, а firewall е својство што важи меѓу моментите. Ако барањето е сообраќајот на апликацијата никогаш да не излегува надвор од тунелот, тоа мора да се изрази во заедничкиот мрежен namespace како правило прими-или-отфрли. Редоследот на стартување на контејнерите не може да го носи тоа барање. Само правило може.

Контејнерите во еден pod го делат тој namespace, па точката на спроведување е самиот namespace. Што и да напишете, мора да ја остави достапна сопствената надворешна врска на тунелот, зашто нејзиното блокирање за да се заштити апликацијата ја сече патеката што ѝ е потребна на апликацијата.

Одлучете ја политиката за неуспех експлицитно: треба ли сообраќајот на апликацијата целосно да запре кога тунелот не е здрав, или да продолжи и да биде означен како незаштитен? Двете се одбранливи и ниту едното не е она што го добивате со стартување контејнери во одреден редослед.

Тестирајте го сообраќајот што не го споменавте

Земете ново барање за време на контролиран неуспех на тунелот и видете дали излегува. Потоа повторете ја проверката за патеките што тестот на излезна адреса никогаш не ги допира: DNS резолуција во кластерот, дестинации IPv6 и услуги до кои се доаѓа преку внатрешни адреси на кластерот, а не преку јавниот интернет. Тоа се патеките што тивко продолжуваат да работат откако тунелот ќе умре.

Страницата на излезната адреса докажува дека едно барање во тој момент отишло каде што очекувавте. Таа не може да ги попише другите патеки, а јазот меѓу тоа што сте го тестирале и тоа до што pod може да стигне е местото каде живеат интересните неуспеси.

Повторете го тестот по рестарт на страничниот контејнер, а не само по чисто стартување. Рестартиран контејнер на тунелот може да го остави namespace со рути и политика во средна состојба.

Запишете го записот за распоредување

Три факти припаѓаат во белешките за распоредување: тестот за подготвеност и што набљудува, дејството за враќање кога тој тест откажува и правилото за спроведување што го уредува излезот. Документацијата за странични контејнери ја покрива механиката на животниот циклус и таа политичка одлука ја остава на вас. Таа поделба е точна и затоа политиката обично недостасува.

Здравствена проверка заменета со заштита е најскапиот вид зелен индикатор, зашто ги спречува луѓето да поставуваат прашања. Нејзиното точно именување во документацијата чини една реченица и го спречува тоа.

Најпосле, тестирајте ја патеката за враќање еднаш додека апликацијата работи. Дизајн што бара повторно создавање на pod за да се врати излезот е одлука и треба да биде онаа што сте ја донеле вие, а не онаа што сте ја откриле.