Pod запускае кантэйнер тунеля да праграмы, і першыя запыты паспяховыя, а гэта менавіта той выпадак, які хавае праблему. Парадак закрывае адну гонку і нічога не кажа пра трафік, які праграма пачынае праз чатыры гадзіны, пасля таго як тунель адмовіў. Гэта два асобныя рашэнні. Звычайна праектуецца толькі адно з іх.

Парадак закрывае толькі першы запыт

Kubernetes падтрымлівае жыццёвы цыкл сайдкара, пабудаваны з перазапускаемых init-кантэйнераў. У гэтай мадэлі стартавая проба можа стрымліваць наступны крок ініцыялізацыі, пакуль тунель не паведаміць пра гатоўнасць. Гэта сапраўднае паляпшэнне, і яго варта выкарыстоўваць свядома, а не дадаваць sleep у скрыпт кропкі ўваходу. Брама не лепшая за ўмову, якую яна правярае.

Па-за гэтай мадэллю семантыка парадку належыць таму асяроддзю выканання або сістэме залежнасцяў, якую вы выкарыстоўваеце, і яны не абавязаны супадаць. Разгортванне, скапіяванае з іншай платформы, можа выглядаць як чаканне тунеля, бо праграма выпадкова стартуе павольна. Гэта не тая ж гарантыя, і яно падае пад нагрузкай.

Скажыце, што назірае брама: працэс існуе, інтэрфейс існуе, рукапоціск завершаны. Кажнае з гэтага — слабейшае сцвярджэнне, чым “шлях даных да прызначэнняў, патрэбных гэтаму pod, працуе”.

Забяспечце шлях даных, а не мяркуйце пра яго

Проба — гэта праверка ў адзін момант, а фaервол — уласцівасць, якая дзейнічае паміж момантамі. Калі патрабаванне ў тым, каб трафік праграмы ніколі не выходзіў па-за тунель, яго трэба выказаць у супольнай сеткавай прасторы імёнаў як правіла прыняцця або адкідання. Парадак запуску кантэйнераў не можа несці гэта патрабаванне. Толькі правіла можа.

Кантэйнеры ў адным pod дзеляць гэтую прастору імёнаў, таму пункт забеспячэння — сама прастора імёнаў. Што б вы ні напісалі, яно павінна пакідаць даступным знешняе злучэнне самога тунеля, бо блакаванне яго дзеля абароны праграмы рэжа шлях, патрэбны праграме.

Вырашыце палітыку збою яўна: ці павінен трафік праграмы цалкам спыняцца, калі тунель нездаровы, ці працягвацца і пазначацца як незаабаронены? Абодва варыянты абараняльныя, і ні адзін з іх не атрымліваецца ад запуску кантэйнераў у пэўным парадку.

Праверце трафік, пра які вы не згадвалі

Вазьміце новы запыт падчас кіраванага збою тунеля і паглядзіце, ці ён выходзіць. Затым паўтарыце праверку для шляхоў, якіх тэст адраса выхаду ніколі не кранае: развязанне DNS унутры кластара, прызначэнні IPv6 і сэрвісы, якія дасягаюцца праз унутраныя адрасы кластара, а не праз публічны інтэрнэт. Гэта тыя шляхі, якія ціха працягваюць працаваць пасля смерці тунеля.

Старонка адраса выхаду даказвае, што адзін запыт пайшоў туды, куды вы чакалі ў той момант. Яна не можа праінвентарызаваць іншыя шляхі, і прамежак паміж тым, што вы праверылі, і тым, да чаго pod можа дацягнуцца, — гэта месца, дзе жывуць цікавыя збоі.

Паўтарыце тэст пасля перазапуску сайдкара, а не толькі пасля чыстага старту. Перазапушчаны кантэйнер тунеля можа пакінуць прастору імёнаў з маршрутамі і палітыкай у прамежкавым стане.

Запішыце запіс разгортвання

У нататкі разгортвання ўваходзяць тры факты: тэст гатоўнасці і тое, што ён назірае, дзеянне аднаўлення, калі гэты тэст падае, і правіла забеспячэння, якое кіруе выхадам. Дакументацыя па кантэйнерах-сайдкарах апісвае механіку жыццёвага цыклу і пакідае гэта палітычнае рашэнне вам. Гэты падзел правільны, і менавіта таму палітыка звычайна адсутнічае.

Праверка здароўя, якую блытаюць з абаронай, — самы дарагі від зялёнага індыкатара, бо яна спыняе людзей задаваць пытанні. Дакладнае называнне яе ў дакументацыі каштуе аднаго сказа і прадухіляе гэта.

Нарэшце, праверце шлях аднаўлення адзін раз, калі праграма працуе. Дызайн, які патрабуе перастварэння pod для аднаўлення выхаду, — гэта рашэнне, і яно павінна быць тым, якое вы прынялі, а не тым, якое вы выявілі.

Падобныя артыкулы