Hoe jo DNS ferpartsje tusken Kubernetes en in OpenVPN-sidecar

In sidecar-pod hat twa namwrâlden nedich. Wys ien loopback-resolver nei it kluster en de tunnel, en stop mei fertrouwen op in bewurke resolv.conf.

Pods dy't in OpenVPN-sidecar draaie, mislearje namresolûsje yn in werkenber patroan: klusternammen hingje, fiere nammen antwurdzje oant de pod werstart, en jo bewurke resolver-triem komt werom. Neat yn dy searje is in tunneldefekt. In pod hat ien resolver-triem en twa namwrâlden, en de triem kin servers yn folchoarder listje mar kin gjin sônes útdrukke. De duorsume oplossing is in resolver dy't yn 'e pod draait en de splitsing besit, sadat de triem triviaal bliuwt en gjin belied in reden hat om it werôver te skriuwen.

Wêrom't de bewurking dy't jo makken hieltyd ferdwynt

De triem heart by de kubelet, net by jo. Under dnsPolicy: ClusterFirst generearret de kubelet him om nei it kluster-DNS te wizen, en regenerearret him eltse kear as in container startet. Alles wat jo feroarje fia kubectl exec libbet yn 'e skriuwbere laach fan 'e container, dus in werstart, in útsetting of in rollout smyt it fuort. De pod-spesifikaasje draacht noch itselde belied, en dêrom komt deselde triem werom.

It ynstellen fan dnsPolicy: None stopet de regeneraasje en hellet ek de klusterresolûsje fuort. Jo krije in triem dy't jo behearskje en ferlieze de nammen dy't jo nedich hiene. Dy ruil is it hiele probleem: resolv.conf hat gjin begryp fan sônes, allinnich fan servers om yn folchoarder te besykjen, dus it kin cluster.local net nei ien adres stjoere en in privee sône nei in oar.

Dreau ien resolver yn 'e pod, op loopback

Wys de pod nei ien namserver op loopback, lit dan in CoreDNS-container dy't de netwurknamromte fan 'e pod dielt antwurdzje op poarte 53. Set it belied op None, jou de pod dat iene adres, en foegje de DNS-container njonken de VPN en de applikaasje ta:

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

Alle trije containers diele ien netwurknamromte, dus 127.0.0.1:53 fan 'e applikaasjecontainer berikt CoreDNS sûnder tsjinst, sûnder port-forward en sûnder omwei troch it klusternetwurk. It mounten fan 'e Corefile út in ConfigMap hâldt him as in ferzjeare ynfier yn stee fan in triem dy't op it plak bewurke wurdt. De generearre resolv.conf hâldt dan ien namserver en neat oars, wat in tastân is dêr't jo oer neitinke kinne.

Twa details bite hjir. De offisjele image bynt poarte 53 as root, en guon klusterbeliedsregels freegje jo dat eksplisyt te skriuwen. Eltse container yn 'e pod hinget no ôf fan dat iene container dat omheech is, dus foegje in readiness-probe ta tsjin in ûnskeadlik namme en lit de applikaasje startmislearrings ferneare.

Jou elke privee sône syn eigen upstream

In Corefile is in list fan sônes, elk neamt de server dy't it antwurdzje kin. Ien blok beslacht de tunnelsône, en it blok dat alles fangt komt lêst en nimt alles wat gjin eksplisyt blok opeaske hat. It blok dat alles fangt moat op in echte upstream rjochtsje, nea werom nei de pod: .:53 { forward . 10.100.0.10 } brûkt de klusterresolver opnij omdat dy resolver al publike nammen trochstjoert nei de resolvers fan 'e node sels. Neat oars yn 'e pod hoecht te witten by hokker netwurk in namme heart.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Lês it klusteradres fan 'e kube-dns-tsjinst yn kube-system yn stee fan ien út in artikel te kopiearjen, want tsjinst-CIDR's ferskille. It tunneladres komt fan 'e dhcp-option DNS-wearde dy't de OpenVPN-server stjoert, of fan 'e autoritative server foar dy sône. As jo klusterresolver gjin publike nammen antwurdet, set dan it resolveradres fan 'e node yn it blok dat alles fangt, lêzen op 'e node en net yn 'e pod.

Rjochtsje it blok dat alles fangt net op /etc/resolv.conf, dat is de ferliedlike ienrigel en in falstrik yn krekt dizze opset. Under dnsPolicy: None befettet de triem fan 'e pod sels de iene namserver 127.0.0.1, dus dat doel is CoreDNS sels en elke net-matchende fraach rekurrearret oant it ferfalt. In blok mei de namme svc.acme.internal matcht dy namme en elke namme dêrûnder, wat db.svc.acme.internal beslacht en svc.acme.internal.example.net útslût. De efterste punt is kosmetysk, want sônenammen wurde normalisearre nei folslein kwalifisearre foarm; de efterheakselgrins beslút wêr't in fraach lânet.

Beslút oft it trochstjoeren by de klusterresolver heart

As elke workload yn 'e namespace de tunnelsône nedich hat, is in trochstjoerblok yn 'e CoreDNS ConfigMap ûnder kube-system goedkeaper as in sidecar per pod. Dy feroaring is op klusterskaal: it freget administratorrjochten en in werstart fan in deployment dêr't elkenien fan ôfhinklik is. Behein it ta dy iene sône, nea ta de woartel. It tunneladres fan ien workload wurdt dan de resolver fan elke pod foar de sône, en de dei dat de tunnel falt ferliest it hiele kluster de namme.

De sidecar hâldt de eksploazjeradius binnen ien pod, wat de bettere standert is as mar in pear tsjinsten it fiere netwurk nedich hawwe. Hokker jo ek kieze, skriuw op hokker resolver de sône besit, want de folgjende persoan dy't in timeout debûgget sil it freegje.

Nammen dy't resolvje wylst ferbiningen noch mislearje

Resolûsje is ien fan de twa dingen dy't de tunnel drage moat; de oare is it werompaad, en it podnetwurk ferberget it goed. As de OpenVPN-server sels as pod draait, behearskje regels dy't jo yn dy container tafoegje gjin ferkear dat troch de node fuortgiet. Dy mislearring is smel: allinnich pods op 'e node dy't ek de server draaide krigen antwurden, en al it oare ferfoel.

It draaien fan 'e server mei hostNetwork: true set him werom yn 'e namromte fan 'e node, dêr't in FORWARD-regel en boarnetranslaasje effekt hawwe. Translearrje de kliïntpool op 'e wei út, oars hat gjin fiere node in rûte werom nei in tunneladres lykas 10.8.0.6. Kontrolearje beide rjochtingen foardat jo de Corefile wer oanreitsje. In tunnel dy't de fraach draacht en net it antwurd produsearret krekt deselde timeout as in resolver dy't de fraach nea krige.

Ferifiearje fan in nije pod, net fan 'e sesje dy't jo reparearre hawwe

Freegje beide sônes eksplisyt, en werhelje dan de fraach nei't de pod ferfongen is. Konfiguraasje dy't allinnich yn in draaiende container bestiet is gjin konfiguraasje:

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

As it earste pear antwurdet en it pear nei de ferfanging net, is de Corefile goed en de pod-spesifikaasje net. As beide antwurdzje en de applikaasje noch gjin ferbining meitsje kin, stopje dan mei it debûgjen fan DNS en test it TCP-paad mei nc -vz db.svc.acme.internal 5432 fan binnen de container. Hâld de dig-útfier yn 'e ticket, want dat is it artefakt dat in namprobleem fan in routingprobleem skiedt.

Relatearre artikelen