Pod туннелдин контейнерин колдонмодон мурун баштайт жана биринчи сурамдар ийгиликтүү болот, бул дал маселени жашырган учур. Тартип бир жарышты оңдойт жана туннель иштебей калгандан төрт саат өткөндөн кийин колдонмо баштаган трафик жөнүндө эч нерсе айтпайт. Бул эки өзүнчө чечим. Адатта алардын бирөө гана долбоорлонт.

Тартип биринчи сурамды гана чектейт

Kubernetes кайра башталуучу init контейнерлерден курулган каптал контейнердин жашоо цикли колдойт. Ал моделде баштоо пробасы туннель даярдык тууралуу билдиргенге чейин кийинки инициализация кадамын кармап тура алат. Бул чыныгы жакшыртуу жана аны кирүү чекитинин скриптине sleep кошуунун ордуна атайын колдонууга татыктуу. Дарбаза канчалык жакшы болсо, ал текшерген шарт да ошончолук жакшы.

Ал моделдин сыртында тартиптин семантикасы сиз колдонгон аткаруу чөйрөсүнө же көз карандылык системасына таандык жана алар дал келиши милдеттүү эмес. Башка платформадан көчүрүлгөн жайгаштыруу туннелди күтүп жаткандай көрүнүшү мүмкүн, анткени колдонмо кокустан жай башталат. Бул ошол эле кепилдик эмес жана жүк астында иштебей калат.

Дарбаза эмнени байкаарын айтыңыз: процесс бар, интерфейс бар, handshake аяктады. Алардын ар бири «бул pod керектеген багыттарга чейинки маалымат жолу иштейт» дегенден алсыз бекемдөө.

Маалымат жолун болжолдоонун ордуна талап кылыңыз

Проба бир учурдагы текшерүү, ал эми firewall учурлардын ортосунда колдонулуучу касиет. Эгер талап колдонмонун трафиги туннелден эч качан чыкпашы болсо, аны жалпы тармактык ат мейкиндигинде кабыл-ал-же-ташта эрежеси катары билдирүү керек. Контейнерлерди баштоо тартиби бул талапты көтөрө албайт. Бир гана эреже көтөрө алат.

Бир pod-догу контейнерлер ошол ат мейкиндигин бөлүшөт, ошондуктан аткаруу чекити ат мейкиндигинин өзү. Эмне жазбаңыз, ал туннелдин өз тышкы байланышын жеткиликтүү калтырышы керек, анткени аны колдонмону коргоо үчүн бөгөттөө колдонмого керектүү жолду кесип салат.

Ката саясатын ачык чечиңиз: туннель ден соолугу начар болгондо колдонмонун трафиги толугу менен токтошу керекпи, же уланып, корголбогон деп белгилениши керекпи? Экөө тең коргоого болот жана экөө тең контейнерлерди белгилүү тартипте баштоо менен алынбайт.

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

Көзөмөлдөнгөн туннель катасы учурунда жаңы сурам алып, анын тышка чыгарын караңыз. Андан кийин чыгуу дареги сынагы эч качан тийбеген жолдор үчүн текшерүүнү кайталаңыз: кластердин ичиндеги DNS чечүү, IPv6 багыттары жана коомдук интернеттин ордуна кластердин ички даректери аркылуу жеткиликтүү кызматтар. Туннель өлгөндөн кийин да үнсүз иштеп жаткан жолдор ушулар.

Чыгуу дарегинин бети бир сурам ошол учурда күткөн жерге барганын далилдейт. Ал башка жолдорду тизмелей албайт, жана сиз сынаган менен pod жеткиликтүү болгон нерсенин ортосундагы ажырым — кызыктуу каталар жашаган жер.

Сынакты таза баштоодон кийин гана эмес, каптал контейнер кайра башталгандан кийин да кайталаңыз. Кайра башталган туннель контейнери ат мейкиндигин маршруттар жана саясат менен аралык абалда калтырышы мүмкүн.

Жайгаштыруу жазуусун жазыңыз

Жайгаштыруу жазууларына үч факт кирет: даярдык сынагы жана ал эмнени байкайт, ал сынак иштебей калгандагы калыбына келтирүү аракети жана чыгууну жөнгө салган аткаруу эрежеси. Каптал контейнерлердин документтештирүүсү жашоо циклинин механизмдерин камтыйт жана бул саясий чечимди сизге калтырат. Бул бөлүнүү туура, жана саясаттын адатта жок болушунун себеби да ушул.

Коргоо деп жаңылыш кабыл алынган ден соолук текшерүүсү эң кымбат жашыл көрсөткүч, анткени ал адамдардын суроо берүүсүн токтотот. Аны документтештирүүдө так атоо бир сүйлөмгө турат жана муну болтурбайт.

Акырында, калыбына келтирүү жолун колдонмо иштеп турганда бир жолу сынаңыз. Чыгууну калыбына келтирүү үчүн pod-ду кайра түзүүнү талап кылган долбоор — бул чечим, жана ал сиз кабыл алган чечим болушу керек, тапкан нерсеңиз эмес.

Тектеш макалалар