DNS

DNS vardų sistema yra labai svarbi bet kurios kompiuterinių tinklų sistemos dalis, įskaitant ir „Kubernetes“. Vidiniam tinklo adresų valdymui „Kubernetes“ naudoja „CoreDNS“ vardų sistemos serverį, kuris puikiai susitvarko su konteinerių tinklo sistemos ypatumais. Vienas jų - vidinių „Kubernetes“ tarnybų ir konteinerių adresų valdymas. Kiekvienas „Service“ tipo objektas „Kubernetes“ tinkle gauna savo DNS įrašą ir jį galima pasiekit tiek pirmojo lygio vardu: „serviso_vardas“, tiek antrojo: „serviso_vardas.vardu_sritis“, tiek ir „pilnu“ (FQDN vardo gale turi būti taškas) vardu: „serviso_vardas.vardu_sritis.svc.cluster.local“. Taip supaprastinamas „Kubernetes“ pritaikytų programinių sistemų kūrimas, nes pakanka žinoti sukurto serviso vardą ir programa galės naudotis tos tinklo tarnybos paslaugomis, nes „CoreDNS“ pasirūpins IP adreso suradimu ir bus galima užmegzti tinklo ryšį.

Tačiau prireikus rasti išorinės sistemos IP adresą, pavyzdžiui, konteineriui prireikus atlikti paiešką „Google“ paieškos sistemoje, pasireiškia tinklo vardų radimo subtilybės. Gavęs „google.com“ užklausą, konteineris nieko nežino apie „Google“, nes jo požiūriu tai yra bandymas rasti „google“ „Service“ tipo objekto adresą, „com“ vardų srityje. Tik nepavykus rasti tokio įrašo visuose klasterio „search domains“ domenų aprašuose, ši užklausa bus siunčiama į išorinius DNS vardų serverius, vienas kurių gali būti vietinio tinklo DNS serveris. Ir štai čia vietinio tinklo DNS serveris gali „pakišti kiaulę“, įtraukdamas savo vietinio tinklo domeno, pavyzdžiui, „home.lan“ į „Kubernetes“ „search domains“ sąrašą. Nepavykus rasti „google.com“ „Kubernetes“ tinkle, suformuojama užklausa rasti „google.com.home.lan“ adresą. Savaime suprantama, kad namų tinkle tokio adreso nėra. Tačau užuot atsiuntusi „NXDOMAIN“ atsakymą, nurodantį, kad įrašo rasti nepavyko ir reikia bandyti toliau, t.y. ieškoti tikro išorinio adreso, tinklo maršrutizatoriaus „DNSMasq“ tarnyba kažkodėl gražindavo „NODATA“ atsakymą. Tai sutrikdydavo vardų paieškos bandymų seką, konteineris nebeieškodavo „google.com“ domeno, nuspręsdamas, kad toks vardas neegzistuoja.

Tingintiems skaityti toliau - problemą pavyko išspręsti tinklo maršrutizatoriaus „DNSMasq“ programoje išjungus „Do not cache negative replies, e.g. for non existing domains“ nuostatą. Ją išjungus, „DNSMasq“ ėmė teisingai gražinti NXDOMAIN atsakymą ne tik neegzistuojantis.home.lan adresui, bet ir antro.lygio.home.lan ar google.com.home.lan adresams. Tiesa, gali būti, kad buvo kažkoks laikinas sutrikimas, nes dabar net ir įjungus šią nuostatą, DNS sistema gražina teisingą NXDOMAIN atsakymą. Na, o besidomintys DNS viduriais, gali skaityti toliau.

Praėjo turbūt jau daugiau, nei 5 metai, kai atsinaujinau savo interneto maršrutizatorių, pakeisdamas Asus RT14U į TP Link AC1750. Negaliu sakyti, kad TP Link, valdomas OpenWRT veikė prastai, tačiau ryšio kokybė nebuvo visiškai patenkinama. Turėjau įtarimą, kad TP Link nelabai susitvarko su maršrutizavimu, tačiau, anot anekdoto, širdimi jaučiu, kad litras, bet įrodyt negaliu. Na, o 5 GHz WiFi 5 ryšys per kelias sienas, tai neveikė akivaizdžiai. Tai reikėjo kažkaip spręsti, tad galiausiai nusprendžiau, kad reikia pabandyti pakeisti maršrutizatorių kuo nors rimtesniu. Tas rimtesnis pasirinkimas tapo Mikrotik hAP AC³ ir, žinoma, „Router OS“.

Po kokių 2 ar 3 sistemos atkūrimų ir jau nebesuskaičiuojamo skaičiaus momentų, kai pakeitus nuostatą, dingdavo ryšys su Mikrotik įrenginiu, galiu pasakyti, kad šita padla, vadinama „Router OS“ įnoringa, o sistemos autoriai apie patogią ir informatyvią sąsają turbūt nėra girdėję. Pagaliau pavykus paleisti internetą - galiu pasakyti viskas veikia pastebimai greičiau. Ne sparčiau, o būtent greičiau. Kažkaip ryšio seansų inicializavimas su TP Link vykdavo pastebimai ilgiau ir puslapių įkrovimo pradžios tekdavo laukti gerokai ilgiau. Taigi tai pliusas. Bet nuo to „Router OS“ draugiškesnė nepasidarė.