ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ DNS ಲುಕಪ್

ಸೂಚನೆ. ಅನುವಾದ.: ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ DNS ಸಮಸ್ಯೆ, ಅಥವಾ ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಪ್ಯಾರಾಮೀಟರ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ndots, ಆಶ್ಚರ್ಯಕರವಾಗಿ ಜನಪ್ರಿಯವಾಗಿದೆ, ಮತ್ತು ಈಗಾಗಲೇ ಮೊದಲಲ್ಲ ಹೋ. ಈ ವಿಷಯದ ಕುರಿತು ಮತ್ತೊಂದು ಟಿಪ್ಪಣಿಯಲ್ಲಿ, ಅದರ ಲೇಖಕ, ಭಾರತದಲ್ಲಿನ ದೊಡ್ಡ ಬ್ರೋಕರೇಜ್ ಕಂಪನಿಯ DevOps ಇಂಜಿನಿಯರ್, ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸಹೋದ್ಯೋಗಿಗಳಿಗೆ ತಿಳಿದುಕೊಳ್ಳಲು ಏನು ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಅತ್ಯಂತ ಸರಳ ಮತ್ತು ಸಂಕ್ಷಿಪ್ತ ರೀತಿಯಲ್ಲಿ ಮಾತನಾಡುತ್ತಾರೆ.

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುವುದರ ಮುಖ್ಯ ಪ್ರಯೋಜನವೆಂದರೆ ತಡೆರಹಿತ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ವೇಷಣೆ. ಸೇವಾ ಪರಿಕಲ್ಪನೆಗೆ ಧನ್ಯವಾದಗಳು (ಇಂಟ್ರಾ-ಕ್ಲಸ್ಟರ್ ಪರಸ್ಪರ ಕ್ರಿಯೆಯನ್ನು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸಲಾಗಿದೆಸೇವೆ), ಇದು ಪಾಡ್ ಐಪಿ ವಿಳಾಸಗಳ ಗುಂಪನ್ನು ಬೆಂಬಲಿಸುವ ವರ್ಚುವಲ್ ಐಪಿ ಆಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಸೇವೆ ವೇಳೆ vanilla ಸೇವೆಯನ್ನು ಸಂಪರ್ಕಿಸಲು ಬಯಸುತ್ತದೆ chocolate, ಇದು ವರ್ಚುವಲ್ IP ಅನ್ನು ನೇರವಾಗಿ ಪ್ರವೇಶಿಸಬಹುದು chocolate. ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ: ಈ ಸಂದರ್ಭದಲ್ಲಿ DNS ವಿನಂತಿಯನ್ನು ಯಾರು ಪರಿಹರಿಸುತ್ತಾರೆ chocolate ಮತ್ತೆ ಹೇಗೆ?

DNS ಹೆಸರಿನ ರೆಸಲ್ಯೂಶನ್ ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಬಳಸಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ CoreDNS. Kubelet ಫೈಲ್‌ಗಳಲ್ಲಿ ನೇಮ್‌ಸರ್ವರ್‌ನಂತೆ CoreDNS ನೊಂದಿಗೆ ಪಾಡ್ ಅನ್ನು ನೋಂದಾಯಿಸುತ್ತದೆ /etc/resolv.conf ಎಲ್ಲಾ ಬೀಜಕೋಶಗಳು. ನೀವು ವಿಷಯವನ್ನು ನೋಡಿದರೆ /etc/resolv.conf ಯಾವುದೇ ಪಾಡ್, ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

ಈ ಸಂರಚನೆಯನ್ನು DNS ಕ್ಲೈಂಟ್‌ಗಳು DNS ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಬಳಸುತ್ತಾರೆ. ಕಡತದಲ್ಲಿ resolv.conf ಕೆಳಗಿನ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ:

• ನೇಮ್ ಸರ್ವರ್: DNS ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವ ಸರ್ವರ್. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು CoreDNS ಸೇವೆಯ ವಿಳಾಸವಾಗಿದೆ;
• ಹುಡುಕಾಟ: ನಿರ್ದಿಷ್ಟ ಡೊಮೇನ್‌ಗಾಗಿ ಹುಡುಕಾಟ ಮಾರ್ಗವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಎಂಬುದು ಕುತೂಹಲಕಾರಿಯಾಗಿದೆ google.com ಅಥವಾ mrkaran.dev FQDN ಅಲ್ಲ (ಸಂಪೂರ್ಣ ಅರ್ಹ ಡೊಮೇನ್ ಹೆಸರುಗಳು) ಹೆಚ್ಚಿನ DNS ಪರಿಹಾರಕಗಳು ಅನುಸರಿಸುವ ಪ್ರಮಾಣಿತ ಸಂಪ್ರದಾಯದ ಪ್ರಕಾರ, ಮೂಲ ವಲಯವನ್ನು ಪ್ರತಿನಿಧಿಸುವ "." ಡಾಟ್‌ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವವುಗಳನ್ನು ಮಾತ್ರ ಸಂಪೂರ್ಣ ಅರ್ಹತೆ (FDQN) ಡೊಮೇನ್‌ಗಳೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಕೆಲವು ಪರಿಹರಿಸುವವರು ಸ್ವತಃ ಒಂದು ಬಿಂದುವನ್ನು ಸೇರಿಸಬಹುದು. ಹೀಗಾಗಿ, mrkaran.dev. ಸಂಪೂರ್ಣ ಅರ್ಹ ಡೊಮೇನ್ ಹೆಸರು (FQDN), ಮತ್ತು mrkaran.dev - ಇಲ್ಲ;
• ಚುಕ್ಕೆಗಳು: ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಪ್ಯಾರಾಮೀಟರ್ (ಈ ಲೇಖನವು ಅದರ ಬಗ್ಗೆ). ndots "ಸಂಪೂರ್ಣ ಅರ್ಹ" ಡೊಮೇನ್ ಹೆಸರು ಎಂದು ಪರಿಗಣಿಸುವ ಮೊದಲು ವಿನಂತಿಯ ಹೆಸರಿನಲ್ಲಿ ಚುಕ್ಕೆಗಳ ಮಿತಿ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ನಾವು DNS ಲುಕಪ್ ಅನುಕ್ರಮವನ್ನು ವಿಶ್ಲೇಷಿಸಿದಾಗ ನಾವು ಇದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಮಾತನಾಡುತ್ತೇವೆ.

ನಾವು ಕೇಳಿದಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ mrkaran.dev ಪಾಡ್ನಲ್ಲಿ:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

ಈ ಪ್ರಯೋಗಕ್ಕಾಗಿ, ನಾನು CoreDNS ಲಾಗಿಂಗ್ ಮಟ್ಟವನ್ನು ಹೊಂದಿಸಿದ್ದೇನೆ all (ಇದು ಸಾಕಷ್ಟು ಮಾತಿನಂತೆ ಮಾಡುತ್ತದೆ). ಪಾಡ್ನ ದಾಖಲೆಗಳನ್ನು ನೋಡೋಣ coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

ಫ್ಯೂ. ಇಲ್ಲಿ ಎರಡು ವಿಷಯಗಳು ನಿಮ್ಮ ಗಮನವನ್ನು ಸೆಳೆಯುತ್ತವೆ:

• ಪ್ರತಿಕ್ರಿಯೆಯು ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿರುವವರೆಗೆ ವಿನಂತಿಯು ಹುಡುಕಾಟದ ಎಲ್ಲಾ ಹಂತಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ NOERROR (DNS ಕ್ಲೈಂಟ್‌ಗಳು ಅದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಪರಿಣಾಮವಾಗಿ ಅದನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ). NXDOMAIN ಕೊಟ್ಟಿರುವ ಡೊಮೇನ್ ಹೆಸರಿಗೆ ಯಾವುದೇ ದಾಖಲೆ ಕಂಡುಬಂದಿಲ್ಲ ಎಂದರ್ಥ. ಏಕೆಂದರೆ ದಿ mrkaran.dev FQDN ಹೆಸರಲ್ಲ (ಅನುಸಾರ ndots=5), ಪರಿಹರಿಸುವವರು ಹುಡುಕಾಟ ಮಾರ್ಗವನ್ನು ನೋಡುತ್ತಾರೆ ಮತ್ತು ವಿನಂತಿಗಳ ಕ್ರಮವನ್ನು ನಿರ್ಧರಿಸುತ್ತಾರೆ;
• ಪೋಸ್ಟ್‌ಗಳು А и АААА ಸಮಾನಾಂತರವಾಗಿ ಆಗಮಿಸುತ್ತಾರೆ. ವಾಸ್ತವವೆಂದರೆ ಒಂದು ಬಾರಿ ವಿನಂತಿಸುತ್ತದೆ /etc/resolv.conf ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, IPv4 ಮತ್ತು IPv6 ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಮಾನಾಂತರ ಹುಡುಕಾಟಗಳನ್ನು ನಿರ್ವಹಿಸುವ ರೀತಿಯಲ್ಲಿ ಅವುಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ಆಯ್ಕೆಯನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ನೀವು ಈ ನಡವಳಿಕೆಯನ್ನು ರದ್ದುಗೊಳಿಸಬಹುದು single-request в resolv.conf.

ಗಮನಿಸಿ: glibc ಈ ವಿನಂತಿಗಳನ್ನು ಅನುಕ್ರಮವಾಗಿ ಕಳುಹಿಸಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು, ಮತ್ತು musl - ಇಲ್ಲ, ಆದ್ದರಿಂದ ಆಲ್ಪೈನ್ ಬಳಕೆದಾರರು ಗಮನಿಸಬೇಕು.

ಡಾಟ್‌ಗಳೊಂದಿಗೆ ಪ್ರಯೋಗ

ಇನ್ನೂ ಸ್ವಲ್ಪ ಪ್ರಯೋಗ ಮಾಡೋಣ ndots ಮತ್ತು ಈ ಪ್ಯಾರಾಮೀಟರ್ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ. ಕಲ್ಪನೆ ಸರಳವಾಗಿದೆ: ndots DNS ಕ್ಲೈಂಟ್ ಡೊಮೇನ್ ಅನ್ನು ಸಂಪೂರ್ಣ ಅಥವಾ ಸಂಬಂಧಿ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಸರಳವಾದ Google DNS ಕ್ಲೈಂಟ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಡೊಮೇನ್ ಸಂಪೂರ್ಣವಾಗಿದೆಯೇ ಎಂದು ಅದು ಹೇಗೆ ತಿಳಿಯುತ್ತದೆ? ನೀವು ಹೊಂದಿಸಿದರೆ ndots 1 ಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಹೇಳುತ್ತಾರೆ: "ಓಹ್, ಇನ್ google ಒಂದೇ ಒಂದು ಬಿಂದು ಇಲ್ಲ; ನಾನು ಸಂಪೂರ್ಣ ಹುಡುಕಾಟ ಪಟ್ಟಿಯ ಮೂಲಕ ಹೋಗುತ್ತೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಆದಾಗ್ಯೂ, ನೀವು ಕೇಳಿದರೆ google.com, ವಿನಂತಿಸಿದ ಹೆಸರು ಮಿತಿಯನ್ನು ಪೂರೈಸುವ ಕಾರಣ ಪ್ರತ್ಯಯಗಳ ಪಟ್ಟಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತದೆ ndots (ಕನಿಷ್ಠ ಒಂದು ಅಂಶವಿದೆ).

ಇದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳೋಣ:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

CoreDNS ಲಾಗ್‌ಗಳು:

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

ರಿಂದ mrkaran ಒಂದೇ ಒಂದು ಅಂಶವಿಲ್ಲ, ಪ್ರತ್ಯಯಗಳ ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯಾದ್ಯಂತ ಹುಡುಕಾಟವನ್ನು ನಡೆಸಲಾಯಿತು.

ಗಮನಿಸಿ: ಪ್ರಾಯೋಗಿಕವಾಗಿ ಗರಿಷ್ಠ ಮೌಲ್ಯ ndots 15ಕ್ಕೆ ಸೀಮಿತ; ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಇದು 5 ಆಗಿದೆ.

ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್

ಅಪ್ಲಿಕೇಶನ್ ಬಹಳಷ್ಟು ಬಾಹ್ಯ ನೆಟ್‌ವರ್ಕ್ ಕರೆಗಳನ್ನು ಮಾಡಿದರೆ, ಸಕ್ರಿಯ ದಟ್ಟಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ DNS ಒಂದು ಅಡಚಣೆಯಾಗಬಹುದು, ಏಕೆಂದರೆ ಹೆಸರಿನ ರೆಸಲ್ಯೂಶನ್ ಅನೇಕ ಅನಗತ್ಯ ಪ್ರಶ್ನೆಗಳನ್ನು ಮಾಡುತ್ತದೆ (ಸಿಸ್ಟಮ್ ಸರಿಯಾದದನ್ನು ಪಡೆಯುವ ಮೊದಲು). ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಡೊಮೇನ್ ಹೆಸರುಗಳಿಗೆ ಮೂಲ ವಲಯವನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಹ್ಯಾಕ್‌ನಂತೆ ಧ್ವನಿಸುತ್ತದೆ. ಅಂದರೆ ಕೇಳುವ ಬದಲು api.twitter.com, ನೀವು ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡಬಹುದು api.twitter.com. (ಡಾಟ್‌ನೊಂದಿಗೆ) ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ, ಇದು ಸಂಪೂರ್ಣ ಡೊಮೇನ್‌ನಲ್ಲಿ ನೇರವಾಗಿ ಅಧಿಕೃತ ಲುಕಪ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು DNS ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಪ್ರೇರೇಪಿಸುತ್ತದೆ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕುಬರ್ನೆಟ್ಸ್ ಆವೃತ್ತಿ 1.14, ವಿಸ್ತರಣೆಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ dnsConfig и dnsPolicy ಸ್ಥಿರ ಸ್ಥಿತಿಯನ್ನು ಪಡೆದರು. ಹೀಗಾಗಿ, ಪಾಡ್ ಅನ್ನು ನಿಯೋಜಿಸುವಾಗ, ನೀವು ಮೌಲ್ಯವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು ndots, ಹೇಳಿ, 3 ವರೆಗೆ (ಮತ್ತು 1 ವರೆಗೆ!). ಈ ಕಾರಣದಿಂದಾಗಿ, ನೋಡ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಸಂದೇಶವು ಪೂರ್ಣ ಡೊಮೇನ್ ಅನ್ನು ಒಳಗೊಂಡಿರಬೇಕು. ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಪೋರ್ಟಬಿಲಿಟಿ ನಡುವೆ ನೀವು ಆಯ್ಕೆ ಮಾಡಬೇಕಾದಾಗ ಇದು ಕ್ಲಾಸಿಕ್ ಟ್ರೇಡ್-ಆಫ್‌ಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅತಿ ಕಡಿಮೆ ಲೇಟೆನ್ಸಿ ಪ್ರಮುಖವಾಗಿದ್ದರೆ ಮಾತ್ರ ನೀವು ಇದರ ಬಗ್ಗೆ ಚಿಂತಿಸಬೇಕು ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ, ಏಕೆಂದರೆ DNS ಫಲಿತಾಂಶಗಳನ್ನು ಆಂತರಿಕವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.

ಉಲ್ಲೇಖಗಳು

ಈ ವೈಶಿಷ್ಟ್ಯದ ಬಗ್ಗೆ ನಾನು ಮೊದಲು ಕಲಿತಿದ್ದೇನೆ K8s-ಸಭೆ, ಜನವರಿ 25 ರಂದು ನಡೆಯಿತು. ಇತರ ವಿಷಯಗಳ ನಡುವೆ ಈ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಚರ್ಚೆ ನಡೆಯಿತು.

ಹೆಚ್ಚಿನ ಅನ್ವೇಷಣೆಗಾಗಿ ಕೆಲವು ಲಿಂಕ್‌ಗಳು ಇಲ್ಲಿವೆ:

• ವಿವರಣೆ, ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ndots=5 ಏಕೆ;
• ಗ್ರೇಟ್ ಸ್ಟಫ್ ndot ಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ;
• ವ್ಯತ್ಯಾಸಗಳು musl ಮತ್ತು glibc ಪರಿಹಾರಕಗಳ ನಡುವೆ.

ಗಮನಿಸಿ: ನಾನು ಬಳಸದಿರಲು ನಿರ್ಧರಿಸಿದೆ dig ಈ ಲೇಖನದಲ್ಲಿ. dig ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಡಾಟ್ (ಮೂಲ ವಲಯ ಗುರುತಿಸುವಿಕೆ) ಸೇರಿಸುತ್ತದೆ, ಡೊಮೇನ್ ಅನ್ನು "ಸಂಪೂರ್ಣ ಅರ್ಹತೆ" (FQDN) ಮಾಡುತ್ತದೆ ಕೇವಲ ಮೊದಲು ಅದನ್ನು ಹುಡುಕಾಟ ಪಟ್ಟಿಯ ಮೂಲಕ ಚಲಾಯಿಸುವ ಮೂಲಕ. ನಲ್ಲಿ ಈ ಬಗ್ಗೆ ಬರೆದಿದ್ದಾರೆ ಹಿಂದಿನ ಪ್ರಕಟಣೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಸಾಮಾನ್ಯವಾಗಿ, ಪ್ರಮಾಣಿತ ನಡವಳಿಕೆಗಾಗಿ ಪ್ರತ್ಯೇಕ ಧ್ವಜವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕು ಎಂಬುದು ಸಾಕಷ್ಟು ಆಶ್ಚರ್ಯಕರವಾಗಿದೆ.

ಹ್ಯಾಪಿ ಡಿಎನ್‌ಸಿಂಗ್! ಆಮೇಲೆ ಸಿಗೋಣ!

ಅನುವಾದಕರಿಂದ PS

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

• «ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನೆಟ್ವರ್ಕಿಂಗ್ಗಾಗಿ ಕ್ಯಾಲಿಕೊ: ಪರಿಚಯ ಮತ್ತು ಸ್ವಲ್ಪ ಅನುಭವ";
• «CoreDNS - ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಪ್ರಪಂಚಕ್ಕಾಗಿ DNS ಸರ್ವರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ಗಾಗಿ ಸೇವಾ ಡಿಸ್ಕವರಿ";
• "ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನೆಟ್ವರ್ಕಿಂಗ್ಗೆ ಒಂದು ಸಚಿತ್ರ ಮಾರ್ಗದರ್ಶಿ": ಭಾಗಗಳು 1 ಮತ್ತು 2 (ನೆಟ್‌ವರ್ಕ್ ಮಾದರಿ, ಓವರ್‌ಲೇ ನೆಟ್‌ವರ್ಕ್‌ಗಳು), ಭಾಗ 3 (ಸೇವೆಗಳು ಮತ್ತು ಸಂಚಾರ ಪ್ರಕ್ರಿಯೆ).

ಮೂಲ: www.habr.com