kubectl не може да реши API приватног кластера преко OpenVPN-а

kubectl не успева при тражењу имена док је тунел активан, а приватна адреса API-ја још одговара на ping. Рута је у реду; клијент пита резолвер који никада није чуо за приватну зону кластера. Најчешће се користе две поправке: послати резолвер виртуелне мреже сваком VPN клијенту или причврстити име локално записом у hosts или условним прослеђивачем. Оне решавају исти симптом с различитом одговорношћу, а њихово мешање доводи до тога да тимови уређују hosts датотеке сваки пут када се крајња тачка поново изгради.

Решавање и доступност не успевају на различитим слојевима

Изведите претрагу сами пре него што било шта промените. getent hosts у Linux-у или nslookup у Windows-у каже да ли клијент уопште добија одговор; истек времена или NXDOMAIN указују на резолвер, док одговор са погрешном адресом указује на застарео запис или јавни пропуст.

Затим потврдите на који сервер се kubectl заправо повезује. kubeconfig контекст чува URL, а VPN рута га не преписује: ако контекст наводи јавну крајњу тачку, DNS може бити савршен, а команда ипак не успева.

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

Трећи сигнал је облик квара након претраге. Име које се реши на приватну адресу, а затим добије TCP истек времена, проблем је заштитног зида или ауторизоване мреже. Име које се реши на јавну адресу значи да је упит изашао из приватне зоне. Држите та три исхода одвојено; сваки вас води другом власнику.

Опција А: пошаљите резолвер виртуелне мреже у тунел

Када VPN сервер ради унутар виртуелне мреже, клијенти могу користити исти резолвер као домаћин сервера. У OpenVPN Community сервер шаље DNS опцију; Access Server приказује исто подешавање у административном интерфејсу, а клијенти морају поново да преузму профил јер DNS директива путује унутар њега.

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

Линија руте је важна у split tunnel профилима. Слање адресе резолвера није исто што и чињење те адресе доступном: ако кроз тунел пролази само подмрежа кластера, упит на 10.0.0.4 излази преко локалног LAN-а и умире. Пошаљите руту домаћина за резолвер или укључите његову подмрежу у тунел.

Страна која прима такође има политику. Резолвер доступан из опсега адреса клијента ипак може одбијати упите са њега, а приватна зона повезана са виртуелном мрежом одговара само клијентима који долазе кроз DNS пут те мреже. Ако претрага истекне након слања, прегледајте сопствене логове резолвера пре него што поново дирате клијента.

На клијенту проверите шта је примењено: resolvectl status у Linux-у са systemd-resolved, scutil --dns у macOS-у, ipconfig /all у Windows-у. Послат DNS сервер који се никада не појави значи да профил није поново учитан.

Опција Б: записи у hosts и условно прослеђивање

Запис у hosts је најмања могућа поправка и најкрхкија. Пресликава једно име на једну адресу на једном рачунару, па ради за демонстрацију, а пада када се приватна крајња тачка или њена IP поново изграде. Такође скрива стварну празнину од остатка тима.

Условни прослеђивач се боље скалира без слања DNS-а сваком клијенту. dnsmasq може послати једну зону VNet резолверу, а све остало оставити на миру: server=/cluster.internal/10.0.0.4. Windows DNS има условне прослеђиваче, а Windows клијенти могу користити NRPT правило за исту поделу. Прослеђивачу и даље треба рута до VNet резолвера.

Прослеђивање задржава уобичајено прегледање локално, што је важно на split tunnel-у. Оно вам даје и једно место за бележење упита за приватну зону и једно место које пада када се домаћин прослеђивача премести.

Бирајте према власништву, не према удобности

Пошаљите резолвер када контролишете VPN профил и желите да свако приватно име ради, не само API. Изаберите прослеђивач када клијенти морају да задрже локални DNS за све остало или када VPN води други тим од кластера.

Записи у hosts су дијагностика, а не примена. Користите један да докажете да је API доступан, затим га уклоните и поправите пут резолвера; ако га оставите, питање рутирања касније се претвара у потрагу за благом. Коју год опцију да изаберете, запишите зону, адресу резолвера и руту која носи упит.

Тестирајте крајњу тачку API-ја, не само име

Када претрага успе, преузмите крајњу тачку верзије API-ја са CA кластера. curl --cacert ca.crt https://api.internal.example:6443/version раздваја TLS и ауторизацијске кварове од DNS-а. 403 значи да име и веза раде, а идентитет не.

Проверите и да ли опсег адреса клијента дозвољавају ауторизоване мреже или заштитни зид кластера. Приватни кластери често прихватају API саобраћај само из VNet или peered опсега, па тунел који додељује адресе из другог пула повезује се на мрежном слоју и бива одбачен на API-ју.

Забележите четири чињенице када ескалирате: резолвер који је клијент користио, адресу коју је вратио, URL сервера у изабраном kubeconfig контексту и прву радњу која није успела. Тај запис говори следећем инжењеру треба ли мењати DNS, рутирање или политику заштитног зида, и зауставља следеће уређивање hosts датотеке.

Почните са претрагом, изаберите пут резолвера који одговара власнику зоне, затим проверите крајњу тачку. Ако сва три прођу, преостали проблем је ауторизација, а не решавање имена.