Таны зөөврийн компьютер образыг асуудалгүй татдаг, гэвч pod ImagePullBackOff дээр гацдаг. Корпорацийн VPN клиентийг sidecar болгон ажиллуулах санал тус болохгүй, учир нь татах үйлдэл таны контейнер үүсэхээс өмнө болдог: kubelet node дээрх container runtime-аас образыг авчрахыг хүсдэг ба runtime нь node-ын сүлжээний namespace ашигладаг.

Үйлдлийн дараалал давхаргыг тодорхойлно

Эхлээд нэрийн шийдэл, дараа нь холболт, баталгаажуулалт, давхаргын таталт, тэгээд л контейнер эхэлдэг. Pod-ын VPN-тэй хийдэг бүхэн энэ дарааллын дараа болдог тул кластер дотор ажиллаж буй туннель таталтын баталгаа биш.

Тиймээс кэш дэх образ маш итгэмжтэй худал: долоо хоногийн өмнө образ татсан node үргэлжлүүлэн өгдөг, deployment эрүүл харагдана, алдаа нь зөвхөн шинэ node дээр replica тавихад илэрнэ. scale-up эсвэл node солих нь шалтгаан биш, өдөөгч юм.

Гурван нөхцөл засварыг тодорхойлно

Хүртээмж нь маршрутлалт, нэрийн шийдэл, endpoint-ийн багцад тулгуурлана. Хэрэв node-ын subnet registry-ийн сүлжээ рүү маршрутлах боломжгүй бол ямар ч credential тус болохгүй. Хэрэв нэрийг node-ын DNS-ээр шийдэж чадахгүй бол холболт эхлэхгүй. Зөвхөн manifest хүрч, blob хүрэхгүй бол таталт дундаа тасарна.

ConditionTypical symptomWhere to look
Node subnet has no route to the registry networkTimeout, no connectionEffective routes on the node NIC, gateway transit, return path on-premises
Node resolver cannot see the private zoneName resolution failure in eventsVNet DNS settings and the resolver the node actually uses
Only the manifest endpoint is reachableAuth succeeds, layer download failsEvery hostname the registry hands out during the pull
TLS or identity is wrongCertificate error, 401 or 403Server certificate name and trust, scoped pull identity

Зөвхөн VNet peering нь бүх gateway transit тохиргоог өгөхгүй, нэг чиглэлийн маршрут нь ажилладаг маршрут биш. Node-д зориулсан VPN gateway-ээр дамжсан дэмжигдсэн зам, registry талд node-ын subnet рүү буцах маршрут хэрэгтэй.

Шийдэл сонгохын өмнө алдааг уншаарай

Pod-ын үйл явдал болон түүний буусан node-оос эхэл, бодит нэрээр: kubectl describe pod app-example -n team-example ба kubectl get pod app-example -n team-example -o wide. Үйл явдлын текст нь шийдэгдээгүй hostname-ыг timeout-оос, сертификатын татгалзлыг байхгүй образоос, зөвшөөрлийн алдааг бүгдээс ялгана.

Баталгаажуулалт бол хамгийн хэт үнэлэгдсэн хэрэгсэл. imagePullSecret нь runtime-д registry-ийн credential өгдөг; энэ нь маршрут суулгахгүй, resolver-ыг өөрчлөхгүй, итгэмжгүй сертификатыг хүчинтэй болгохгүй. Үйл явдал таталт зөвшөөрөгдөөгүй гэвэл таних тэмдгийн хүрээг хар; холболт хугацаа хэтэрсэн гэвэл credential хамааралгүй.

Kubernetes-ийн образын баримт бичиг нь таталтын зан төлөв болон хувийн registry-ийн credential-ийн эх сурвалж бөгөөд сүлжээг өөрчлөхийн өмнө нэг удаа унших нь зүйтэй, учир нь баталгаажуулалт ба тээврийн хоорондын хил хязгаарыг тодорхой болгодог.

Pod-ын доор замыг байгуул

Энэ дарааллаар ажилла. Эхлээд node-ын сүлжээг маршрутла: subnet-д registry-ийн сүлжээ рүү дэмжигдсэн зам байгааг батал, node дээрх үр дүнтэй маршрут, хоёр талын аюулгүй байдлын дүрэм, registry талын буцах маршрутыг шалга.

Дараа нь нэрийг node-ын контекстээс шийд. Node-ын resolver нь pod-ын DNS тохиргоо биш, pod доторх амжилт нь host runtime-ийн баталгаа биш. Байнгын hosts бичлэгийн оронд удирдлагатай хувийн DNS ашигла; бичлэг node солигдох хүртэл амьдарч, дараа нь чимээгүй алга болно.

Дараа нь endpoint бүрийг батал. Registry нь клиентэд тусдаа баталгаажуулалтын үйлчилгээ, тусдаа blob хадгалалт өгч болно. Manifest-д хүрэх нь давхаргын тухай бараг юу ч батлахгүй. Эцэст нь TLS ба зөвшөөрлийг гүйцээ: registry-ийн нэрэнд хүчинтэй, дэмжигдсэн node тохиргоогоор итгэмжлэгдсэн сертификат, мөн тухайн repository-г уншихаар хязгаарлагдсан татах таних тэмдэг.

Гараар засаагүй node дээр шалга

Жинхэнэ туршилт бол тохирох node дээр шинээр татах ба бүх давхаргыг бүрэн татах, ялангуяа scale эсвэл солисноор үүссэн node дээр. Энэ нь workload байрлуулж болох бүх pool-ыг, мартсаныг ч хамарна. Нэг node дээрх гарын засвар нь deployment загвар биш, дараагийн autoscale үйл явдал цоорхойг олно.

Кластерыг өөр VNet-д дахин байгуулах нь замыг өөрчилж болох ч энэ нь эхний оношлогооны алхам биш, сүүлчийн арга. Шилжилт санал болгохын өмнө одоогийн node-ын сүлжээг шаардлагатай хувийн маршрут болон дэмжигдсэн AKS сүлжээний хяналттай харьцуул, ажилласны дараах аппын холболтыг тусдаа шалгалт болгон хадгал: pod-ын backend-тэй ярилцах нь node-ын образ татахаас өөр шалгалт.

Холбоотой нийтлэлүүд