Kubernetes మరియు OpenVPN సైడ్‌కార్ మధ్య DNS ను ఎలా విభజించాలి

సైడ్‌కార్ పోడ్కు రెండు పేర్ల లోకాలు కావాలి. ఒక లూప్‌బ్యాక్ రిజోల్వర్ను క్లస్టర్ మరియు టనెల్కు చూపించి, సంపాదిత resolv.conf పై ఆధారపడటం ఆపండి.

OpenVPN సైడ్‌కార్ ను నడిపె పోడ్లు పేర్ల పరిష్కరణలో గుర్తించగల పడ్డతిలో విఫలమవుతాయి: క్లస్టర్ పేర్లు వ్యెలాడుతాయి, దూర పేర్లు పోడ్ మళ్ళీ ప్రారంభమయ్యే వరకు సమాధానం ఇస్తాయి, మీరు సంపాదించిన రిజోల్వర్ ఫైలు తిరిగి వెళ్తుంది. ఆ క్రమంలో ఏదీ టనెల్ లోపము కాదు. పోడ్కు ఒక రిజోల్వర్ ఫైలు మరియు రెండు పేర్ల లోకాలు ఉన్నాయి, ఫైలు సర్వర్లను క్రమంగా జాబితా చేయగలదు కానీ మండలాలను వ్యక్తపరచలేదు. శాశ్వత పరిష్కారం పోడ్ లోపల నడిచే మరియు విభజనను కలిగి ఉన్న రిజోల్వర్, కాబట్టి ఫైలు సరళంగా ఉంటుంది మరియు ఏ విధానానికైనా దాన్ని మళ్ళీ రాయడానికి కారణం ఉండదు.

మీరు చేసిన మార్పు ఎల్లప్పుడూ ఎలా అదృశమవుతుంది

ఫైలు kubelet కు చెందుతుంది, మీకు కాదు. dnsPolicy: ClusterFirst క్రింద kubelet దాన్ని క్లస్టర్ DNS వైపు చూపించేలా సృష్టిస్తుంది, కంటెయ్నర్ ప్రారంభమైన ప్రతిసారీ మళ్ళీ సృష్టిస్తుంది. kubectl exec ద్వారా మీరు మార్చేదల్లాం కంటెయ్నర్ యొక్క రాయగల పెదరులో ఉంటుంది, కాబట్టి పునరారంభం, బహిష్కరణ లేదా రోల్అవుట్ వాటిని పెరికి వేస్తాయి. పోడ్ స్పెసిఫికేషన్ ఇప్పటికీ అదే విధానను మొత్తం మొస్తారు, అందుకే అదే ఫైలు తిరిగి వస్తుంది.

dnsPolicy: None సెట్ చేయడం పునఃసృష్టిని ఆపుతుంది మరియు క్లస్టర్ పరిష్కరణను కూడా తొలగిస్తుంది. మీరు నియంత్రించే ఫైలును పొందుతారు, అవసరమైన పేర్లను కోల్పోతారు. ఈ మార్పుపు మొత్తం సమస్య: resolv.conf కు మండలాల భావన లేదు, క్రమంగా ప్రయత్నించాల్సిన సర్వర్లు మాత్రమే, కాబట్టి cluster.local ను ఒక చిరునామా కు, ప్రైవేట్ మండలం మరొకటికి పంపలేదు.

పోడ్ లో ఒక రిజోల్వర్ను నడపండి, లూప్‌బ్యాక్ పై

పోడ్ను లూప్‌బ్యాక్ పై ఉన్న ఒక నేమ్‌సర్వర్కు చూపండి, ఆ తరువాత పోడ్ యొక్క నెట్వర్క్ పేర్ల స్థానాన్ని పంచుకున్న CoreDNS కంటెయ్నర్ పోర్ట్ 53 లో సమాధానం ఇవ్వనివ్వండి. విధానాన్ని None గా సెట్ చేయండి, ఆ ఒక చిరునామాన్ని పోడ్కు ఇవ్వండి, VPN మరియు అప్లికేషన్ పక్కన DNS కంటెయ్నర్ను చేర్చండి:

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

మూడు కంటెయ్నర్లూ ఒక నెట్వర్క్ పేర్ల స్థానాన్ని పంచుకుంటాయి, కాబట్టి అప్లికేషన్ కంటెయ్నర్ నుండి 127.0.0.1:53 సేవ లేకుండా, port-forward లేకుండా మరియు క్లస్టర్ నెట్వర్క్ ద్వారా చుట్టుత్తు వెళ్లకుండా CoreDNS ను చేరుకుంటుంది. ConfigMap నుండి Corefile ను మౌంట్ చేయడం దాన్ని స్థలంలోనే సంపాదించే ఫైలుకి బదులుగా వెర్షన్ చేసిన ఇన్పుట్‌గా ఉంచుతుంది. తయారయ్యిన resolv.conf అప్పుడు ఒక నేమ్‌సర్వర్ మాత్రమే ఉంటుంది, అంతే కాక మరేదీ ఉండదు, దాని గురించి ఆలోచించగల స్థితి.

ఇక్కడ రెండు వివరాలు కటుతాయి. అధికృత ఇమేజ్ పోర్ట్ 53 ను root గా కట్టుతుంది, కొన్ని క్లస్టర్ విధానాలు దాన్ని స్పష్టంగా రాయమని బలవంతం చేస్తాయి. పోడ్లోని ప్రతి కంటెయ్నర్ ఇప్పుడు ఆ ఒక కంటెయ్నర్ నడుస్తున్నదా అన్ని ఆధారపడుతున్నాయి, కాబట్టి హానికరం లేని పేరుకు readiness ప్రోబ్ చేర్చి, అప్లికేషన్ ప్రారంభ విఫలతలను భరించుకోవనివ్వండి.

ప్రతి ప్రైవేట్ మండలానికి దాని స్వంత upstream ఇవ్వండి

Corefile అనేది మండలాల జాబితా, ప్రతి దానికి సమాధానం ఇవ్వగల సర్వర్ పేరు చెపుతుంది. ఒక బ్లాక్ టనెల్ మండలాన్ని కవర్ చేస్తుంది, అన్నింటినీ పట్టుకునే బ్లాక్ చివరగా వచ్చి, ఏ స్పష్ట బ్లాక్ కూడా కోరని అన్నిటినీ తీసుకుంటుంది. అన్నింటినీ పట్టుకునే బ్లాక్ నిజమైన upstream ను లక్ష్యం చేయాలి, ఎప్పుడూ పోడ్ వైపు తిరిగి వెళ్ళకూడదు: .:53 { forward . 10.100.0.10 } క్లస్టర్ రిజోల్వర్ను మళ్ళీ ఉపయోగిస్తుంది, ఎందుకంటే అది ఇప్పటికే ప్రపంచ పేర్లను నోడ్ యొక్క రిజోల్వర్లకు పంపుతుంది. పోడ్లో మరేదీ ఏదీ పేరు ఏ నెట్వర్క్‌కు చెందుతుందో తెలుసుకోవండటం అవసరం లేదు.

.:53 {
  errors
  cache 30
  forward . 10.100.0.10
}

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

క్లస్టర్ చిరునామాన్ని వ్యాసం నుండి కాపీ చేయకుండా kube-system లోని kube-dns సేవ నుండి చదవండి, ఎందుకంటే సేవ CIDR లు భేదపడతాయి. టనెల్ చిరునామా OpenVPN సర్వర్ పంపే dhcp-option DNS విలువ నుండో ఆ మండలం యొక్క అధికార సర్వర్ నుండో వస్తుంది. మీ క్లస్టర్ రిజోల్వర్ ప్రపంచ పేర్లకు సమాధానం ఇవ్వకపోతే, నోడ్ రిజోల్వర్ చిరునామాన్ని అన్నింటినీ పట్టుకునే బ్లాక్లో ఉంచండి, అది నోడ్ పై చదవబడినది గా ఉండాలి, పోడ్ లోపల కాదు.

అన్నింటినీ పట్టుకునే బ్లాక్‌ను /etc/resolv.conf వైపు చూపకండి, అది ఆస్కర్షణీయమైన ఒక పంక్తి మరియు ఈ ఖచ్చిత సెటపులో ఒక ఉడికి. dnsPolicy: None క్రింద పోడ్ యొక్క స్వంత ఫైలులో ఒకే నేమ్‌సర్వర్ 127.0.0.1 ఉంటుంది, కాబట్టి ఆ లక్ష్యం CoreDNS స్వయం, పొరుత్తని ప్రతి ప్రశ్న సమయం ముగిసే వరకు పునరావృతమవుతుంది. svc.acme.internal అనే పేరుతో ఉన్న బ్లాక్ ఆ పేరుకు మరియు దాని క్రింద ఉన్న ప్రతి పేరుకు సరిపోతుంది, అది db.svc.acme.internal ను కవర్ చేసి svc.acme.internal.example.net ను మినహాయిస్తుంది. చివరన బిందువు దృశ్యమానం మాత్రమే, ఎందుకంటే మండల పేర్లు పూర్ణమైన అర్హత రూపంలోకి సాధారణీకరించబడతాయి; ప్రత్యయ హద్దు ప్రశ్న ఎక్కడ దిగుతుందో నిర్ణయిస్తుంది.

ఫార్వర్డింగ్ క్లస్టర్ రిజోల్వర్కు చెందుతుందో లేదో నిర్ణయించండి

పేర్ల స్థానంలోని ప్రతి పనిభారంకు టనెల్ మండలం అవసరమైతే, kube-system క్రింద CoreDNS ConfigMap లో ఫార్వర్డింగ్ బ్లాక్ ప్రతి పోడ్కు సైడ్‌కార్ కంటే చవకగా ఉంటుంది. ఆ మార్పు క్లస్టర్ స్థాయిది: అది నిర్వాహక హక్కులను మరియు అందరూ ఆధారపడుతున్న డిప్లాయ్మెంట్ పునరారంభం అవసరం. దాన్ని ఆ ఒక మండలానికే పరిమితం చేయండి, ఎప్పుడూ మూలానికి కాదు. ఒక పనిభారం టనెల్ చిరునామా అప్పుడు ఆ మండలానికి ప్రతి పోడ్ రిజోల్వర్ అవుతుంది, టనెల్ పడిపోయే రోజు మొత్తం క్లస్టర్ పేరును కోల్పోతుంది.

సైడ్‌కార్ పిడుగు వ్యాసాన్ని ఒక పోడ్ లోపల ఉంచుతుంది, కొన్ని సేవలకు మాత్రమే దూర నెట్వర్క్ అవసరమైనప్పుడు అది మెరుగైన డిఫాల్ట్. మీరు ఏది ఎంచుకున్నా, ఏ రిజోల్వర్ మండలానికి యజమానురు అనేది రాసి ఉంచండి, ఎందుకంటే టైమ్అవుట్ డీబగ్ చేసే తరువాత వ్యక్తి అది అడుగుతారు.

కనెక్షన్లు ఇంకా విఫలమవుతున్నప్పుడూ పరిష్కరించబడే పేర్లు

పరిష్కరణం టనెల్ మొత్తుకునే రెండింటిలో ఒకటి; రెండవది తిరుగుబాట, మరియు పోడ్ నెట్వర్క్ దాన్ని బాగా దాచ్చుతుంది. OpenVPN సర్వర్ స్వయం పోడ్‌గా నడిస్తే, ఆ కంటెయ్నర్లో మీరు చేర్చే నియమాలు నోడ్ ద్వారా బయటకెళ్ళే ట్రాఫిక్‌ను నియంత్రించవు. ఆ విఫలత ఇటుమూతిది: సర్వర్ కూడా నడిపిన నోడ్ పైన ఉన్న పోడ్లకే సమాధానాలు వచ్చాయి, మిగిలినవి సమయం ముగిసిపోయాయి.

సర్వర్‌ను hostNetwork: true తో నడపడం అదిని నోడ్ పేర్ల స్థానంలోకి తిరిగి తెచ్చుతుంది, అక్కడ FORWARD నియమం మరియు మూల అనువాదం పనిచేస్తాయి. బయటకెళ్లేటప్పుడు క్లైంట్ పూల్ అనువదించండి, లేకపోతే 10.8.0.6 వంటి టనెల్ చిరునామాకు తిరిగి వెళ్ళే మార్గం ఏ దూర నోడ్కు ఉండదు. Corefileను మళ్ళీ తాకే ముందు రెండు దిశలనూ చెక్ చేయండి. ప్రశ్నను మొత్తుకుని సమాధానం మొత్తుకనీ టనెల్, ప్రశ్ననే ఎప్పుడూ అందుకోని రిజోల్వర్ లాంటే అదే టైమ్అవుట్‌ను ఉత్పత్తి చేస్తుంది.

మీరు మరమ్మర్చేసిన సెషన్ నుండి కాదు, కొత్త పోడ్ నుండి ధృవీకరించండి

రెండు మండలాలనూ స్పష్టంగా అడగండి, ఆ తరువాత పోడ్ మార్పు జరిగిన తరువాత ప్రశ్నను పునరావృతం చేయండి. నడుస్తున్న కంటెయ్నర్లో మాత్రమే ఉన్న కన్ఫిగరేషన్ కన్ఫిగరేషన్ కాదు:

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

మొదటి జోడీ సమాధానం ఇవ్వకుంటే మార్పు తరువాత జోడీ ఇవ్వకపోతే, Corefile సరైనది మరియు పోడ్ స్పెసిఫికేషన్ కాదు. రెండూ సమాధానం ఇవ్వకపోతే మరియు అప్లికేషన్ ఇంకా కనెక్ట్ కాకపోతే, DNS డీబగ్ చేయడం ఆపి, కంటెయ్నర్ లోపల నుండి nc -vz db.svc.acme.internal 5432 తో TCP మార్గం పరీక్షించండి. dig అవుట్‌పుట్‌ను టికెట్లో ఉంచండి, ఎందుకంటే అది పేర్ల సమస్యను రూటింగ్ సమస్య నుండి వేరు చేసే కలాకృతి.

సంబంధిత వ్యాసాలు