Kubernetes மற்றும் OpenVPN சைட்காருக்கு இடையே DNS ஐ எவ்வாறு பிரிப்பது

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 வெளியீட்டை டிக்கெட்டில் வைக்கவும், ஏனெனில் அது பெயர் பிரச்சினை பாதையமைப்பு பிரச்சினையிலிருந்து பிரிக்கும் பொருளாகும்.