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 ಎಲೆದುಗಳನ್ನು ಟಿಕೆಟ್ನಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಅದು ಹೆಸರಿನ ಸಮಸ್ಯೆಯನ್ನು ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸುವ ಕಲಾಕೃತಿ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು