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 mount කිරීම එය ස්ථානයේම සංස්කරණය වන ගොනුවක් වෙනුවට අනුවාදිත ආදානයක් ලෙස තබා ගනී. ජනනය කළ resolv.conf පසුව එක් නම්සේවාදායකයෙක් පමණක් රඳවා ගන්නා අතර වෙනත් කිසිවක් නොමැත, එය ගැන තර්ක කළ හැකි තත්ත්වයකි.

මෙහි විස්තර දෙකක් දෂ්ට කරයි. නිල රූපය 53 වරාය root ලෙස බැඳ තබයි, සහ සමහර ක්ලස්ටර් ප්‍රතිපත්ති එය පැහැදිලිව ලියන්නට බල කරයි. පොඩ් හි සෑම කන්ටේනරයක්ම දැන් එම එකම කන්ටේනරය ක්‍රියාත්මක වීම මත රඳා පවතී, එබැවින් හානිකර නොවන නමකට readiness probe එකක් එක් කර යෙදුමට ආරම්භක අසාර්ථකතා ඉවසන්නට ඉඩ දෙන්න.

සෑම පෞද්ගලික කලාපයකටම තමන්ගේ 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 ප්‍රතිදානය ටිකට්පතේ තබන්න, මන්ද එය නම් ගැටලුව මාර්ගගත කිරීමේ ගැටලුවෙන් වෙන් කරන නිර්මාණයයි.

අදාළ ලිපි