Sut i rannu DNS rhwng Kubernetes a sidecar OpenVPN

Mae pod sidecar angen dau fyd enwi. Pwyntiwch un datryswr loopback at y clwstwr a'r twnnel, a stopiwch ddibynnu ar resolv.conf wedi'i olygu.

Mae podau sy'n rhedeg OpenVPN sidecar yn methu datrys enwau mewn patrwm adnabyddadwy: mae enwau'r clwstwr yn hongian, mae enwau anghysbell yn ateb nes bod y pod yn ailgychwyn, ac mae eich ffeil datryswr wedi'i golygu yn dychwelyd yn ôl. Nid yw dim yn y dilyniant hwnnw'n ddiffyg twnnel. Mae gan bod un ffeil datryswr a dau fyd enwi, a gall y ffeil restru gweinyddwyr yn eu trefn ond ni all fynegi parthau. Y gwelliant parhaol yw datryswr sy'n rhedeg y tu mewn i'r pod ac sy'n berchen ar y rhaniad, felly mae'r ffeil yn parhau'n syml ac nid oes gan unrhyw bolisi reswm i'w hailysgrifennu.

Pam mae'r golygiad a wnaethoch yn diflannu'n barhaus

Mae'r ffeil yn perthyn i'r kubelet, nid i chi. O dan dnsPolicy: ClusterFirst mae'r kubelet yn ei chynhyrchu i bwyntio at DNS y clwstwr, ac yn ei hailgynhyrchu pryd bynnag y bydd cynhwysydd yn cychwyn. Mae popeth a newidiwch drwy kubectl exec yn byw yn haen ysgrifennadwy'r cynhwysydd, felly mae ailgychwyn, troi allan neu rollout yn ei daflu. Mae manyleb y pod yn dal i gario'r un polisi, a dyna pam mae'r un ffeil yn dychwelyd.

Mae gosod dnsPolicy: None yn atal yr ailgynhyrchu ac yn tynnu datrysiad y clwstwr hefyd. Fe gewch ffeil rydych yn ei rheoli ac fe gollwch yr enwau roeddech eu hangen. Y fasnach hon yw'r broblem gyfan: nid oes gan resolv.conf syniad o barthau, dim ond o weinyddwyr i'w profi yn eu trefn, felly ni all anfon cluster.local at un cyfeiriad a pharth preifat at un arall.

Rhedwch un datryswr yn y pod, ar loopback

Pwyntiwch y pod at un gweinydd enwau ar loopback, yna gadewch i gynhwysydd CoreDNS sy'n rhannu gofod enw rhwydwaith y pod ateb ar borth 53. Gosodwch y polisi i None, rhowch y cyfeiriad unig hwnnw i'r pod, ac ychwanegwch y cynhwysydd DNS wrth ymyl y VPN a'r cymhwysiad:

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

Mae'r tri chynhwysydd yn rhannu un gofod enw rhwydwaith, felly mae 127.0.0.1:53 o gynhwysydd y cymhwysiad yn cyrraedd CoreDNS heb wasanaeth, heb port-forward a heb osgoi drwy rwydwaith y clwstwr. Mae mowntio'r Corefile o ConfigMap yn ei gadw'n fewnbwn fersiynog yn lle ffeil a olygir yn ei lle. Yna mae resolv.conf a gynhyrchwyd yn dal un gweinydd enwau a dim byd arall, sef cyflwr y gallwch resymu amdano.

Mae dau fanylyn yn brathu yma. Mae'r ddelwedd swyddogol yn rhwymo porth 53 fel root, ac mae rhai polisïau clwstwr yn mynnu eich bod yn nodi hynny'n benodol. Mae pob cynhwysydd yn y pod nawr yn dibynnu ar fod y cynhwysydd un hwnnw i fyny, felly ychwanegwch brawf parodrwydd yn erbyn enw diniwed a gadewch i'r cymhwysiad oddef methiannau cychwyn.

Rhowch i bob parth preifat ei upstream ei hun

Mae Corefile yn rhestr o barthau, pob un yn enwi'r gweinydd a all ateb. Mae un bloc yn cwmpasu parth y twnnel, ac mae'r bloc sy'n dal popeth yn dod yn olaf ac yn cymryd popeth na hawliodd unrhyw floc penodol. Rhaid i'r bloc sy'n dal popeth anelu at upstream go iawn, byth yn ôl at y pod: mae .:53 { forward . 10.100.0.10 } yn ailddefnyddio datryswr y clwstwr oherwydd bod y datryswr hwnnw eisoes yn anfon enwau cyhoeddus at ddatryswyr y nod ei hun. Nid oes angen i ddim arall yn y pod wybod i ba rwydwaith y mae enw'n perthyn.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Darllenwch gyfeiriad y clwstwr o'r gwasanaeth kube-dns yn kube-system yn lle copïo un o erthygl, oherwydd mae CIDRau gwasanaeth yn wahanol. Mae cyfeiriad y twnnel yn dod o'r gwerth dhcp-option DNS y mae'r gweinydd OpenVPN yn ei wthio, neu o'r gweinydd awdurdodol ar gyfer y parth hwnnw. Os nad yw eich datryswr clwstwr yn ateb enwau cyhoeddus, rhowch gyfeiriad datryswr y nod yn y bloc sy'n dal popeth, wedi'i ddarllen ar y nod ac nid y tu mewn i'r pod.

Peidiwch â phwyntio'r bloc sy'n dal popeth at /etc/resolv.conf, sef yr un llinell demtasiwn a chyfrwystra yn y gosodiad hwn yn union. O dan dnsPolicy: None mae ffeil y pod ei hun yn cynnwys yr un gweinydd enwau 127.0.0.1, felly'r targed hwnnw yw CoreDNS ei hun ac mae pob ymholiad heb ei gydweddu yn ailadrodd nes iddo ddod i ben. Mae bloc o'r enw svc.acme.internal yn cyfateb i'r enw hwnnw ac i bob enw oddi tano, sy'n cwmpasu db.svc.acme.internal ac yn eithrio svc.acme.internal.example.net. Mae'r dot olaf yn gosmetic, oherwydd mae enwau parthau'n cael eu normaleiddio i ffurf llawn gymwys; y ffin ôl-ddodiad sy'n penderfynu lle mae ymholiad yn glanio.

Penderfynwch a yw'r anfon yn perthyn i ddatryswr y clwstwr

Os oes angen parth y twnnel ar bob llwyth gwaith yn y namespace, mae bloc anfon yn y CoreDNS ConfigMap o dan kube-system yn rhatach na sidecar fesul pod. Mae'r newid hwnnw ar raddfa clwstwr: mae angen hawliau gweinyddwr ac ailgychwyn deployment y mae pawb yn dibynnu arno. Cyfyngwch ef i'r un parth hwnnw, byth i'r gwraidd. Yna daw cyfeiriad twnnel un llwyth gwaith yn ddatryswr pob pod ar gyfer y parth, a'r diwrnod y bydd y twnnel yn cwympo bydd y clwstwr cyfan yn colli'r enw.

Mae'r sidecar yn cadw'r radiws ffrwydrad o fewn un pod, sef y diofyn gwell pan mai dim ond ychydig o wasanaethau sydd angen y rhwydwaith anghysbell. Pa un bynnag a ddewiswch, nodwch pa ddatryswr sy'n berchen ar y parth, oherwydd bydd y person nesaf sy'n dadfygu terfyn amser yn gofyn.

Enwau sy'n datrys tra bo cysylltiadau'n dal i fethu

Mae datrysiad yn un o'r ddau beth y mae'n rhaid i'r twnnel eu cario; y llall yw y llwybr yn ôl, ac mae rhwydwaith y pod yn ei guddio'n dda. Os yw'r gweinydd OpenVPN ei hun yn rhedeg fel pod, nid yw'r rheolau a ychwanegwch y tu mewn i'r cynhwysydd hwnnw'n llywodraethu traffig sy'n gadael drwy'r nod. Mae'r methiant hwnnw'n gul: dim ond podau ar y nod a oedd hefyd yn rhedeg y gweinydd gafodd atebion, a daeth popeth arall i ben.

Mae rhedeg y gweinydd gyda hostNetwork: true yn ei roi yn ôl yng ngofod enw'r nod, lle mae rheol FORWARD a chyfieithu ffynhonnell yn cael effaith. Cyfieithwch y pool cleientiaid ar y ffordd allan, neu nid oes gan unrhyw nod anghysbell lwybr yn ôl i gyfeiriad twnnel fel 10.8.0.6. Gwiriwch y ddau gyfeiriad cyn i chi gyffwrdd â'r Corefile eto. Mae twnnel sy'n cario'r ymholiad ac nid yr ateb yn cynhyrchu'r un terfyn amser yn union â datryswr na chafodd yr ymholiad erioed.

Gwiriwch o bod newydd, nid o'r sesiwn a wnaethoch yn iawn

Gofynnwch am y ddau barth yn benodol, yna ailadroddwch yr ymholiad ar ôl i'r pod gael ei ddisodli. Nid yw cyfluniad sy'n bodoli mewn cynhwysydd sy'n rhedeg yn unig yn gyfluniad:

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

Os yw'r pâr cyntaf yn ateb ac nad yw'r pâr ar ôl y disodliad yn ateb, mae'r Corefile yn iawn ac nid yw manyleb y pod. Os yw'r ddau yn ateb ac nad yw'r cymhwysiad yn dal i allu cysylltu, stopiwch ddadfygu DNS a phrofwch y llwybr TCP gyda nc -vz db.svc.acme.internal 5432 o fewn y cynhwysydd. Cadwch allbwn dig yn y tocyn, oherwydd hwnnw yw'r arteffact sy'n gwahanu problem enwi oddi wrth broblem llwybro.

Erthyglau cysylltiedig