VPN пратећи контејнер треба правило покретања и правило квара

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

Редослед само блокира први захтев

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

Изван тог модела, семантика редоследа припада оном runtime-у или систему зависности који користите и не мора да се подудара. Имплементација копирана са друге платформе може изгледати као да чека тунел јер апликација случајно споро креће. То није иста гаранција и пада под оптерећењем.

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

Наметните data пут уместо да га претпостављате

Проба је провера у једном тренутку, а firewall је својство које важи између тренутака. Ако је захтев да саобраћај апликације никада не изађе изван тунела, то се мора изразити у заједничком мрежном namespace-у као правило прихвати-или-одбаци. Редослед покретања контејнера не може носити тај захтев. Само правило може.

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

Одлуку о политици квара донесите изричито: треба ли саобраћај апликације потпуно стати када тунел није здрав, или наставити и бити означен као незаштићен? Оба су одржива и ниједно није оно што добијате покретањем контејнера у одређеном редоследу.

Тестирајте саобраћај који нисте споменули

Узмите нови захтев током контролисаног квара тунела и погледајте да ли излази. Затим поновите проверу за путање које тест излазне адресе никада не дотиче: DNS разрешавање унутар кластера, IPv6 одредишта и сервисе до којих се долази преко кластер-интерних адреса, а не јавног интернета. То су путање које тихо настављају да раде након што тунел умре.

Страница излазне адресе доказује да је један захтев отишао тамо где сте очекивали у том тренутку. Она не може да попише остале путање, а јаз између онога што сте тестирали и онога до чега pod може доћи место је где живе занимљиви кварови.

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

Запишите запис о имплементацији

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

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

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