VPN-ийн хажуугийн контейнерт эхлүүлэх дүрэм ба бүтэлгүйтлийн дүрэм хэрэгтэй

Pod нь аппаас өмнө туннелийн контейнерийг эхлүүлж, эхний хүсэлтүүд амжилттай болдог бөгөөд энэ нь асуудлыг нуудаг яг тэр тохиолдол юм. Дараалал нь нэг уралдааныг засдаг бөгөөд туннель доголдсоны дараа дөрвөн цагийн дараа апп эхлүүлэх траффикийн талаар юу ч хэлдэггүй. Эдгээр нь хоёр тусдаа шийдвэр юм. Ихэвчлэн зөвхөн нэгийг нь зохион бүтээдэг.

Дараалал нь зөвхөн эхний хүсэлтийг хязгаарлана

Kubernetes нь дахин эхлүүлэх боломжтой init контейнеруудаас бүрдсэн хажуугийн контейнерийн амьдралын мөчлөгийг дэмждэг. Тэр загварт эхлүүлэх проб нь туннель бэлэн байдлын мэдээлэл өгөх хүртэл дараагийн эхлүүлэлтийн алхмыг саатуулж чадна. Энэ бол жинхэнэ сайжруулалт бөгөөд орох цэгийн скриптэд sleep нэмэхийн оронд зориуд ашиглах нь зүйтэй. Хаалга нь шалгаж буй нөхцөл шигээ л сайн.

Тэр загвараас гадна дарааллын семантик нь таны ашиглаж буй ажиллагааны орчин эсвэл хамаарлын системд хамаарах бөгөөд тэдгээр нь заавал тохирох шаардлагагүй. Өөр платформоос хуулсан байршуулалт нь апп санамсаргүйгээр удаан эхэлдэг учраас туннелийг хүлээж байгаа мэт харагдаж болно. Энэ нь ижил баталгаа биш бөгөөд ачааллын дор бүтэлгүйтдэг.

Хаалга юуг ажиглаж байгааг хэлээрэй: процесс байна, интерфейс байна, handshake дууссан. Эдгээр нь тус бүр «энэ pod-д хэрэгтэй очих газрууд руу мэдээллийн зам ажиллаж байна» гэснээс сул мэдэгдэл юм.

Мэдээллийн замыг таамаглахын оронд хэрэгжүүл

Проб нь нэг мөчийн шалгалт, firewall нь мөчүүдийн хооронд үйлчлэх шинж чанар юм. Хэрэв аппын траффик туннелиас хэзээ ч гарахгүй байх шаардлагатай бол үүнийг хуваалцсан сүлжээний нэрийн орон зайд хүлээж авах эсвэл хаях дүрэм хэлбэрээр илэрхийлэх ёстой. Контейнеруудыг эхлүүлэх дараалал энэ шаардлагыг дааж чадахгүй. Зөвхөн дүрэм л чадна.

Нэг pod дахь контейнерууд тэр нэрийн орон зайг хуваалцдаг, тиймээс хэрэгжүүлэх цэг нь нэрийн орон зай өөрөө. Юу ч бичсэн, энэ нь туннелийн өөрийн гадаад холболтыг ашиглах боломжтой үлдээх ёстой, учир нь аппыг хамгаалахын тулд түүнийг блоклох нь аппд хэрэгтэй замыг таслана.

Бүтэлгүйтлийн бодлогыг тодорхой шийдээрэй: туннель эрүүл бус үед аппын траффик бүрэн зогсох ёстой юу, эсвэл үргэлжилж, хамгаалалтгүй гэж тэмдэглэгдэх ёстой юу? Хоёулаа үндэслэлтэй бөгөөд аль нь ч контейнеруудыг тодорхой дарааллаар эхлүүлснээр олддоггүй.

Таны дурдаагүй траффикийг туршина уу

Хяналттай туннелийн доголдлын үед шинэ хүсэлт авч, гадагш гарч байгаа эсэхийг хар. Дараа нь гарах хаягийн шалгалт хэзээ ч хүрдэггүй замуудын хувьд шалгалтыг давт: кластер доторх DNS шийдвэрлэлт, IPv6 очих газрууд, нийтийн интернетийн оронд кластерын дотоод хаягаар хүрдэг үйлчилгээнүүд. Туннель үхсэний дараа ч чимээгүй үргэлжлүүлэн ажилладаг замууд эдгээр юм.

Гарах хаягийн хуудас нь нэг хүсэлт тэр мөчид таны хүлээсэн газар явсныг нотолдог. Энэ нь бусад замыг бүртгэж чадахгүй бөгөөд таны туршсан зүйл ба pod-ын хүрч чадах зүйлийн хоорондох зай нь сонирхолтой бүтэлгүйтлүүд амьдардаг газар юм.

Зөвхөн цэвэр эхлэлийн дараа биш, хажуугийн контейнерыг дахин эхлүүлсний дараа ч туршилтыг давт. Дахин эхэлсэн туннелийн контейнер нэрийн орон зайг маршрут, бодлогын хамт завсрын төлөвт үлдээж болно.

Байршуулалтын бүртгэлийг бич

Байршуулалтын тэмдэглэлд гурван баримт орно: бэлэн байдлын шалгалт ба түүний ажиглаж буй зүйл, тэр шалгалт бүтэлгүйтэх үеийн сэргээх үйлдэл, гарцыг зохицуулах хэрэгжүүлэх дүрэм. Хажуугийн контейнеруудын баримт бичиг амьдралын мөчлөгийн механизмыг хамарч, тэр бодлогын шийдвэрийг танд үлдээдэг. Тэр хуваарилалт зөв бөгөөд бодлого ихэвчлэн дутагддаг шалтгаан нь ч мөн энэ.

Хамгаалалт гэж андуурсан эрүүл мэндийн шалгалт нь хамгийн үнэтэй төрлийн ногоон үзүүлэлт, учир нь хүмүүсийг асуулт асуухаас зогсоодог. Баримт бичигт үүнийг зөв нэрлэх нь нэг өгүүлбэрийн зардал бөгөөд үүнийг сэргийлдэг.

Эцэст нь, апп ажиллаж байхад сэргээх замыг нэг удаа турш. Гарцыг сэргээхийн тулд pod-ыг дахин үүсгэх шаардлагатай загвар нь шийдвэр бөгөөд энэ нь таны олж мэдсэн биш, таны гаргасан шийдвэр байх ёстой.