AKS не можа загрузіць вобраз з прыватнага registry за VPN
kubelet загружае вобраз праз сетку node, а не праз VPN pod. Вызначайце па маршрутах node, DNS node, кожным endpoint загрузкі, затым TLS і ідэнтычнасці.
На вашым ноўтбуку вобраз загружаецца без праблем, а pod затрымліваецца ў ImagePullBackOff, і хтосьці прапануе запускаць карпаратыўны VPN-кліент як sidecar. Гэта не дапаможа, бо загрузка адбываецца раней, чым існуе ваш кантэйнер: kubelet просіць container runtime на node загрузіць вобраз, а runtime выкарыстоўвае сеткавы namespace node. VPN унутры workload не мае маршруту для гэтага шляху, а яго ўласны дапаможны вобраз трэба спачатку загрузіць.
Парадак аперацый вызначае ўзровень
Спачатку ідзе развязанне імені вобраза. kubelet праз runtime развязвае імя registry, усталёўвае злучэнне, аўтэнтыфікуецца, спампоўвае слаі і толькі пасля гэтага запускае кантэйнер. Усё, што ваш pod робіць з VPN, адбываецца пасля завяршэння гэтай паслядоўнасці, таму працоўны тунель у кластары не доказ адносна загрузкі.
Таму кэшаваны вобраз — такі пераканаўчы падман. Node, які загрузіў вобраз тыдні таму, працягвае яго аддаваць, deployment выглядае здаровым, і збой праяўляецца толькі тады, калі планавальнік змяшчае рэпліку на навейшы node. Калі ў храналогіі падзей ёсць маштабаванне, замена node або абнаўленне pool, лічыце гэта трыгерам, а не прычынай.
Тры ўмовы вызначаюць рамонт
Дасягальнасць прыватнага registry з кіраванага pool зводзіцца да маршрутызацыі, развязання імёнаў і набору endpoint. Калі падсетка node не мае маршруту да сеткі registry, ніякія ўліковыя дадзеныя не дапамогуць. Калі маршрут ёсць, але імя registry не развязваецца праз DNS-шлях node, злучэнне не пачнецца. Калі абодва працуюць для manifest, але не для blob, куды registry перанакіроўвае кліента, загрузка абарвецца на палове шляху.
| Condition | Typical symptom | Where to look |
|---|---|---|
| Node subnet has no route to the registry network | Timeout, no connection | Effective routes on the node NIC, gateway transit, return path on-premises |
| Node resolver cannot see the private zone | Name resolution failure in events | VNet DNS settings and the resolver the node actually uses |
| Only the manifest endpoint is reachable | Auth succeeds, layer download fails | Every hostname the registry hands out during the pull |
| TLS or identity is wrong | Certificate error, 401 or 403 | Server certificate name and trust, scoped pull identity |
Адно peering VNet не дае аўтаматычна ўсіх варыянтаў gateway transit, і маршрут у адзін бок не азначае працоўны маршрут. Node патрэбны падтрыманы шлях праз патрэбны VPN gateway або зацверджаны прыбор, а бок registry мае патрэбны зваротны маршрут да падсеткі node.
Спачатку прачытайце збой, потым выбірайце рашэнне
Пачніце з падзей pod і node, на які ён трапіў, з вашымі рэальнымі імёнамі: kubectl describe pod app-example -n team-example і kubectl get pod app-example -n team-example -o wide. Тэкст падзеі адрознівае нявырашанае імя хоста ад тайм-аўту, адмову сертыфіката ад адсутнага вобраза, а памылку аўтарызацыі ад усіх іх. Гэтыя чатыры маюць чатырох розных уладальнікаў.
Аўтэнтыфікацыя — найбольш пераацэнены рычаг. imagePullSecret дае runtime уліковыя дадзеныя для registry; ён не ўсталёўвае маршрут, не змяняе resolver node і не робіць недавераны сертыфікат сапраўдным. Калі падзея кажа, што загрузка не была аўтарызавана, глядзіце на межы ідэнтычнасці. Калі кажа, што злучэнне скончылася тайм-аўтам, уліковыя дадзеныя не маюць значэння.
Дакументацыя Kubernetes пра вобразы — крыніца пра паводзіны загрузкі і ўліковыя дадзеныя прыватных registry, і яе варта прачытаць адзін раз перад зменай сеткі, бо яна ясна паказвае мяжу паміж аўтэнтыфікацыяй і транспартам.
Пабудуйце шлях ніжэй за pod
Працуйце ў гэтым парадку, бо кожны крок бессэнсоўны, пакуль не выкананы папярэдні. Спачатку маршрутызуйце сетку node: пераканайцеся, што падсетка node мае падтрыманы шлях да сеткі registry, праверце эфектыўныя маршруты на node, правілы бяспекі на абодвух канцах і зваротны маршрут на баку registry.
Затым развяжыце імя з кантэксту node. Resolver node не тое самае, што DNS-канфігурацыя pod, і поспех унутры pod не доказ для host runtime. Выкарыстоўвайце кіраваны прыватны DNS замест пастаяннага запісу ў hosts; запіс жыве да замены node і потым ціха знікае.
Затым дакажыце кожны endpoint. Registry можа даць кліенту асобны сэрвіс аўтэнтыфікацыі і асобнае сховішча blob. Дасягненне manifest амаль нічога не даказвае пра слаі. Нарэшце завершыце TLS і аўтарызацыю: сертыфікат, сапраўдны для імені registry і давераны праз падтрыманую канфігурацыю node, плюс ідэнтычнасць загрузкі з правам чытання гэтага рэпазіторыя.
Праверце на node, які вы не рамантавалі ўручную
Сапраўдны тэст — свежая загрузка і поўнае спампоўванне ўсіх слаёў на прыдатным node, лепш за ўсё створаным маштабаваннем або заменай. Гэта ахоплівае ўсе pool, якія могуць размясціць workload, уключаючы забытыя. Ручны рамонт на адным node не мадэль разгортвання, і наступная падзея аўтамаштабавання знойдзе прабел.
Перастварэнне кластара ў іншым VNet можа змяніць шлях, але гэта апошні сродак, а не першы дыягнастычны крок. Параўнайце існуючую сетку node з патрэбным прыватным маршрутам і падтрыманымі сродкамі кіравання сеткай AKS перад прапановай міграцыі, і трымайце злучнасць праграмы пасля запуску асобнай праверкай: размова pod з яго backend — іншая праверка, чым спампоўванне вобраза node.