Jinsi ya kugawanya DNS kati ya Kubernetes na sidecar ya OpenVPN

Pod zinazoendesha OpenVPN sidecar hushindwa katika utatuzi wa majina kwa mtindo unaotambulika: majina ya cluster yananing'inia, majina ya mbali hujibu hadi pod ianzishwe upya, na faili ya resolver uliyohariri inarudi. Hakuna kitu katika mfuatano huo ni hitilafu ya handaki. Pod ina faili moja ya resolver na dunia mbili za majina, na faili inaweza kuorodhesha seva kwa mpangilio lakini haiwezi kueleza kanda. Suluhisho la kudumu ni resolver inayoendesha ndani ya pod na inayomiliki mgawanyo, kwa hivyo faili inabaki rahisi na hakuna sera inayokuwa na sababu ya kuiandika upya.

Kwa nini mabadiliko uliyofanya yanatoweka kila mara

Faili ni mali ya kubelet, si yako. Chini ya dnsPolicy: ClusterFirst kubelet huizalisha ili ielekee DNS ya cluster, na huizalisha upya kila kontena inapoanza. Kila kitu unachobadilisha kupitia kubectl exec huishi katika tabaka linaloweza kuandikwa la kontena, kwa hivyo kuanzisha upya, kuondoa au rollout huitupa. Vipimo vya pod bado hubeba sera hiyo hiyo, ndiyo sababu faili hiyo hiyo inarudi.

Kuweka dnsPolicy: None kunasitisha uundaji upya na pia kuondoa utatuzi wa cluster. Unapata faili unayoidhibiti na unapoteza majina uliyohitaji. Kubadilishana huku ni tatizo zima: resolv.conf haina dhana ya kanda, ni seva zinazojaribiwa kwa mpangilio tu, kwa hivyo haiwezi kutuma cluster.local kwenye anwani moja na kanda ya faragha kwenye nyingine.

Endesha resolver moja ndani ya pod, kwenye loopback

Elekeza pod kwenye seva moja ya majina kwenye loopback, kisha acha kontena la CoreDNS linaloshiriki nafasi ya majina ya mtandao wa pod lijibu kwenye lango 53. Weka sera kuwa None, ipe pod anwani hiyo moja, na uongeze kontena la DNS kando ya VPN na programu:

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

Kontena zote tatu zinashiriki nafasi moja ya majina ya mtandao, kwa hivyo 127.0.0.1:53 kutoka kontena la programu hufikia CoreDNS bila huduma, bila port-forward na bila mzunguko kupitia mtandao wa cluster. Kuweka Corefile kutoka ConfigMap kunaiweka kama ingizo lenye matoleo badala ya faili inayohaririwa papo hapo. resolv.conf iliyozalishwa basi inashikilia seva moja ya majina na hakuna kingine, hali ambayo unaweza kufikiria juu yake.

Maelezo mawili yanauma hapa. Picha rasmi hufunga lango 53 kama root, na sera zingine za cluster hukulazimu kuandika hilo wazi. Kila kontena katika pod sasa inategemea kontena hilo moja kuwa hai, kwa hivyo ongeza probe ya readiness dhidi ya jina lisilo na madhara na uache programu ivumili kushindwa kwa kuanza.

Ipe kila kanda ya faragha upstream yake

Corefile ni orodha ya kanda, kila moja ikitaja seva inayoweza kuijibu. Kizuizi kimoja hufunika kanda ya handaki, na kizuizi cha kukamata kila kitu huja mwisho na huchukua kila kitu ambacho hakuna kizuizi wazi kilichodai. Kizuizi cha kukamata kila kitu lazima kielekee upstream halisi, kamwe kisirudi kwenye pod: .:53 { forward . 10.100.0.10 } hutumia tena resolver ya cluster kwa sababu tayari hupeleka majina ya umma kwenye resolver za node yenyewe. Hakuna kingine katika pod kinachohitaji kujua jina ni la mtandao gani.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

Soma anwani ya cluster kutoka huduma ya kube-dns katika kube-system badala ya kunakili moja kutoka makala, kwa sababu CIDR za huduma zinatofautiana. Anwani ya handaki inatoka kwa thamani ya dhcp-option DNS ambayo seva ya OpenVPN hutuma, au kutoka kwa seva yenye mamlaka ya kanda hiyo. Ikiwa resolver yako ya cluster haijibu majina ya umma, weka anwani ya resolver ya node kwenye kizuizi cha kukamata kila kitu, iliyosomwa kwenye node na si ndani ya pod.

Usielekeze kizuizi cha kukamata kila kitu kwenye /etc/resolv.conf, ambayo ni mstari mmoja unaovutia na mtego katika usanidi huu kamili. Chini ya dnsPolicy: None faili ya pod yenyewe ina seva moja tu ya majina 127.0.0.1, kwa hivyo lengo hilo ni CoreDNS yenyewe na kila swali lisilolingana hujirudia hadi muda uishe. Kizuizi kinachoitwa svc.acme.internal kinalingana na jina hilo na kila jina chini yake, ambayo inashughulikia db.svc.acme.internal na haijumuishi svc.acme.internal.example.net. Nukta ya mwisho ni ya urembo, kwa sababu majina ya kanda husawazishwa kuwa umbo lililostahiki kikamilifu; mpaka wa kiambishi huamua swali linatua wapi.

Amua ikiwa upelekaji ni wa resolver ya cluster

Ikiwa kila mzigo wa kazi katika nafasi ya majina unahitaji kanda ya handaki, kizuizi cha upelekaji katika ConfigMap ya CoreDNS chini ya kube-system ni cha bei nafuu kuliko sidecar kwa kila pod. Mabadiliko hayo ni ya ngazi ya cluster: yanahitaji haki za msimamizi na kuanzisha upya deployment ambayo kila mtu hutegemea. Iweke kwenye kanda hiyo moja, kamwe si kwenye mzizi. Anwani ya handaki ya mzigo mmoja wa kazi basi inakuwa resolver ya kila pod kwa kanda hiyo, na siku handaki linapoanguka cluster yote inapoteza jina.

Sidecar huweka eneo la mlipuko ndani ya pod moja, ambayo ni chaguo-msingi bora wakati huduma chache tu zinahitaji mtandao wa mbali. Chochote unachochagua, andika ni resolver gani inamiliki kanda, kwa sababu mtu anayefuata kutatua timeout atauliza.

Majina yanayotatuliwa wakati miunganisho bado inashindwa

Utatuzi ni moja ya mambo mawili ambayo handaki lazima ibebe; lingine ni njia ya kurudi, na mtandao wa pod unaificha vizuri. Ikiwa seva ya OpenVPN yenyewe inaendesha kama pod, sheria unazoongeza kwenye kontena hilo hazidhibiti trafiki inayotoka kupitia node. Hitilafu hiyo ni nyembamba: ni pod tu kwenye node iliyoendesha pia seva zilizopata majibu, na kila kitu kingine kilimaliza muda.

Kuendesha seva na hostNetwork: true kunairudisha kwenye nafasi ya majina ya node, ambapo sheria ya FORWARD na tafsiri ya chanzo hufanya kazi. Tafsiri bwawa la wateja unapotoka, vinginevyo hakuna node ya mbali yenye njia ya kurudi kwenye anwani ya handaki kama 10.8.0.6. Angalia pande zote mbili kabla ya kugusa Corefile tena. Handaki inayobeba swali lakini si jibu huzalisha timeout sawa kabisa na resolver ambayo haikupokea swali kamwe.

Thibitisha kutoka pod mpya, si kutoka kikao ulichokirekebisha

Uliza kanda zote mbili kwa uwazi, kisha rudia swali baada ya pod kubadilishwa. Usanidi unaokuwepo tu katika kontena linaloendesha si usanidi:

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

Ikiwa jozi ya kwanza inajibu na jozi baada ya ubadilishaji haijibu, Corefile ni sahihi na vipimo vya pod si sahihi. Ikiwa zote zinajibu lakini programu bado haiwezi kuunganisha, acha kutatua DNS na ujaribu njia ya TCP na nc -vz db.svc.acme.internal 5432 kutoka ndani ya kontena. Hifadhi matokeo ya dig kwenye tiketi, kwa sababu ndiyo kifaa kinachotenganisha tatizo la majina na tatizo la uelekezaji.