Sida loo kala qaybiyo DNS-ka Kubernetes iyo sidecar-ka OpenVPN

Pod-yada socodsiiya OpenVPN sidecar waxay ku guuldareystaan xallinta magacyada qaab la aqoonsan karo: magacyada cluster-ka way dhega laadaan, magacyada fog waxay ka jawaabaan ilaa pod-ka dib loo bilaabo, iyo faylka resolver-ka ee aad tafatirtay way dib u noqdaan. Wax ka mid ah taxanahaas ma aha cilad tunnel. Pod-ku wuxuu leeyahay hal fayl resolver iyo laba adduun oo magacyo, faylkuna wuxuu liis garayn karaa server-yada si kala duwan laakiin ma muujin karo aagag. Xalka waaraya waa resolver ku shaqeeya pod-ka gudihiisa oo leh qaybinta, sidaas darteed faylku wuu fududaanayaa oo siyaasadna sabab uma haysato inuu dib u qoro.

Sababta isbeddelka aad sameysay uu mar walba u lumo

Faylku waxaa leh kubelet, ma aha adiga. dnsPolicy: ClusterFirst hoostiisa kubelet wuxuu abuuraa si uu u tilmaamo DNS-ka cluster-ka, wuxuuna dib u abuuraa mar kasta oo container-ku bilaabmo. Wax kasta oo aad ku beddesho kubectl exec waxay ku noolaataa lakabka la qori karo ee container-ka, sidaas darteed dib u bilaabid, ka saarid ama rollout way tuurayaan. Qeexitaanka pod-ku wali wuxuu qaadaa isla siyaasaddaas, taasna waa sababta isla faylkaas u soo noqdo.

Dejinta dnsPolicy: None waxay joojisaa dib u abuurista waxayna sidoo kale meesha ka saaraysaa xallinta cluster-ka. Waxaad heshaa fayl aad maamusho oo waxaad lumisaa magacyadii aad u baahnayd. Is-weydaarsigan waa dhammaan dhibaatada: resolv.conf ma yaqaan fikradda aagag, kaliya server-yo si kala duwan loo tijaabiyo, sidaas darteed ma diri karo cluster.local hal cinwaan iyo aag gaar ah mid kale.

Ku socodsii hal resolver pod-ka gudihiisa, loopback-ka

U hagaaji pod-ka hal server magac oo ku yaal loopback, ka dibna u oggolow container-ka CoreDNS ee la wadaaga booska magaca shabakada pod-ka inuu ka jawaabo port 53. Deji siyaasadda None, sii pod-ka cinwaankaas kaliya, oo ku dar container-ka DNS agagaarka VPN iyo barnaamijka:

spec:
  dnsPolicy: None
  dnsConfig:
    nameservers:
      - 127.0.0.1
    options:
      - name: ndots
        value: "5"
  containers:
    - name: dns
      image: coredns/coredns
      args: ["-conf", "/etc/coredns/Corefile"]
      volumeMounts:
        - {name: corefile, mountPath: /etc/coredns, readOnly: true}
    - name: vpn
      image: your-openvpn-client-image
    - name: app
      image: your-app-image
  volumes:
    - name: corefile
      configMap:
        name: split-dns-corefile

Saddexda container waxay wadaagaan hal boos magac shabakadeed, sidaas darteed 127.0.0.1:53 container-ka barnaamijka wuxuu gaaraa CoreDNS iyada oo aan adeeg lahayn, iyada oo aan port-forward lahayn iyo iyada oo aan ku wareegayn shabakada cluster-ka. Ku dhejinta Corefile ka ConfigMap waxay ku haysaa sidii gelin noocaysan halkii ay ahaan lahayd fayl goobta lagu tafatiray. resolv.conf la soo saaray markaas wuxuu hayaa hal server magac iyo wax kale ma jiro, xaalad laga fekiri karo.

Laba tafaasiil ayaa halkan qaniina. Sawirka rasmiga ah wuxuu port 53 ku xiraa root, siyaasadaha cluster-ka qaarkoodna waxay ku qasbaan inaad si cad u qorto. Container kasta oo pod-ka ku jira hadda wuxuu ku tiirsan yahay inuu container-kaas kaliya shaqeeyo, sidaas darteed ku dar readiness probe magac aan waxyeello lahayn oo u oggolow barnaamijka inuu u adkaysto guuldarada bilaabista.

Sii aag kasta oo gaar ah upstream u gaar ah

Corefile waa liis aagag ah, mid kastaa wuxuu magacaabaa server-ka ka jawaabi kara. Hal block wuxuu daboolaa aagga tunnel-ka, block-ka wax walba qabtaana wuxuu yimaadaa ugu dambeeya oo qaata wax kasta oo aan block cad sheegan. Block-ka wax walba qabtaa waa inuu u jeestaa upstream dhab ah, marnaba dib ugu noqon pod-ka: .:53 { forward . 10.100.0.10 } wuxuu dib u isticmaalaa resolver-ka cluster-ka sababtoo ah wuxuu horey u gudbiyaa magacyada dadweynaha resolver-yada node-ka laftiisa. Wax kale oo pod-ka ku jira uma baahna inay ogaadaan shabakada magacu ka tirsan yahay.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

svc.acme.internal:53 {
  errors
  cache 30
  forward . 192.168.240.1
}

Ka akhri cinwaanka cluster-ka adeegga kube-dns ee ku jira kube-system halkii aad ka koobi lahayd maqaal, sababtoo ah CIDR-yada adeegga way kala duwan yihiin. Cinwaanka tunnel-ka wuxuu ka yimaadaa qiimaha dhcp-option DNS ee uu diro server-ka OpenVPN, ama server-ka awoodda leh ee aaggaas. Haddii resolver-kaaga cluster-ku aanu ka jawaabin magacyada dadweynaha, geli cinwaanka resolver-ka node-ka block-ka wax walba qabtaa, oo lagu akhriyay node-ka ee aan pod-ka gudihiisa ahayn.

Ha u jeedin block-ka wax walba qabtaa /etc/resolv.conf, taas oo ah safka hal-line ee soo jiidashada leh iyo dabin ku jirta isla habkan. dnsPolicy: None hoostiisa faylka pod-ka laftiisu wuxuu ka kooban yahay server-ka magaca kaliya 127.0.0.1, sidaas darteed bartilmaameedkaas waa CoreDNS laftiisa oo su'aal kasta oo aan is waafajin waxay ku celcelinaysaa ilaa waqtigu dhammaado. Block lagu magacaabo svc.acme.internal wuxuu is waafajiyaa magacaas iyo magac kasta oo ka hooseeya, taas oo daboolaysa db.svc.acme.internal oo ka saaraysa svc.acme.internal.example.net. Dhibicda ugu dambeysa waa muuqaal, sababtoo ah magacyada aagagga waa la caadiyeeyaa qaab buuxa; xadka halkudhigga ayaa go'aamiya halka su'aashu ku dhacdo.

Go'aami haddii gudbintu ay leedahay resolver-ka cluster-ka

Haddii culeyska shaqo kasta oo ku jira booska magaca uu u baahan yahay aagga tunnel-ka, block gudbin oo ku jira ConfigMap-ka CoreDNS ee kube-system hoostiisa ayaa ka jaban sidecar-ka pod kasta. Isbeddelkaas waa heer cluster: wuxuu u baahan yahay xuquuqda maamulaha iyo dib u bilaabista deployment ay qof walba ku tiirsan yahay. Ku xaddid aaggaas kaliya, marnaba xididka. Cinwaanka tunnel-ka hal culeys shaqo ayaa markaas noqda resolver-ka pod kasta ee aagga, maalinta tunnel-ku dhaco cluster-ka oo dhan wuxuu lumiyaa magaca.

Sidecar-ku wuxuu hayaa gacan-qabadka qaraxa hal pod gudihiisa, taas oo ah caadi wanaagsan marka kaliya dhowr adeeg u baahan yihiin shabakada fog. Wax kasta oo aad dooratid, qor resolver-ka leh aagga, sababtoo ah qofka xiga ee wax ka qabanaya timeout-ka wuu weydiin doonaa.

Magacyo xalliya inta isku xirka wali guuldareysta

Xallintu waa mid ka mid ah labada shay ee tunnel-ku waa inuu qaado; kan kale waa wadada dib u soo noqoshada, shabakada pod-kuna si fiican ayay u qarinaysaa. Haddii server-ka OpenVPN laftiisu u shaqeeyo sidii pod, xeerarka aad ku darto container-kaas ma maamulaan taraafikada ka baxa node-ka. Guuldaradaas way cidhiidhi: kaliya pod-yada node-ka sidoo kale socodsiiyay server-ka ayaa jawaabo helay, wax kale oo dhan waqtigii wuu dhammaaday.

Socodsiinta server-ka hostNetwork: true waxay ku celinaysaa booska magaca node-ka, halkaas oo xeerka FORWARD iyo tarjumaadda isha ay shaqeeyaan. Tarjun barkadda macmiilka markaad baxayso, haddii kale node fog ma laha waddo dib ugu noqota cinwaan tunnel sida 10.8.0.6. Hubi labada jiho ka hor inta aadan mar kale taaban Corefile. Tunnel-ka qaada su'aasha laakiin aan qaadin jawaabta wuxuu soo saaraa isla timeout-kaas uu soo saaro resolver aan waligiis helin su'aasha.

Ka xaqiiji pod cusub, ma aha kulanka aad hagaajisay

Weydii labada aag si cad, ka dibna ku celi su'aasha ka dib marka pod-ka la beddelo. Qaabeynta ku jirta kaliya container socda ma aha qaabeyn:

kubectl exec -it deploy/app -- dig @127.0.0.1 kubernetes.default.svc.cluster.local +short
kubectl exec -it deploy/app -- dig @127.0.0.1 db.svc.acme.internal +short
kubectl delete pod -l app=your-app
kubectl wait --for=condition=Ready pod -l app=your-app --timeout=90s
kubectl exec -it deploy/app -- dig @127.0.0.1 db.svc.acme.internal +short

Haddii lammaanaha koowaad jawaabto lammaanaha beddelka ka dibna aan jawaabin, Corefile waa sax qeexitaanka pod-kana ma aha. Haddii labaduba jawaabaan barnaamijkuna wali isku xiri karin, jooji cilad-baadhista DNS oo tijaabi wadada TCP nc -vz db.svc.acme.internal 5432 gudaha container-ka. Kaydi soo-saarka dig tigidhka, sababtoo ah waa shayga kala sooca dhibaatada magacyada iyo dhibaatada marin-hagaajinta.