🥇 DNS ຊອກຫາໃນ Kubernetes

ຫມາຍເຫດ. ແປ.: ບັນຫາ DNS ໃນ Kubernetes, ຫຼືຫຼາຍທີ່ຊັດເຈນ, ການຕັ້ງຄ່າພາລາມິເຕີ ndots, ເປັນທີ່ນິຍົມທີ່ຫນ້າປະຫລາດໃຈ, ແລະແລ້ວ ບໍ່ແມ່ນຄັ້ງທໍາອິດ год. ໃນບັນທຶກອື່ນໃນຫົວຂໍ້ນີ້, ຜູ້ຂຽນຂອງຕົນ, ວິສະວະກອນ DevOps ຈາກບໍລິສັດນາຍຫນ້າຂະຫນາດໃຫຍ່ໃນປະເທດອິນເດຍ, ສົນທະນາໃນລັກສະນະທີ່ງ່າຍດາຍແລະ concise ກ່ຽວກັບສິ່ງທີ່ເປັນປະໂຫຍດສໍາລັບເພື່ອນຮ່ວມງານທີ່ດໍາເນີນການ Kubernetes ທີ່ຈະຮູ້.

ຫນຶ່ງໃນຜົນປະໂຫຍດຕົ້ນຕໍຂອງການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກໃນ Kubernetes ແມ່ນການຄົ້ນພົບຄໍາຮ້ອງສະຫມັກທີ່ບໍ່ມີ seamless. ປະຕິສໍາພັນພາຍໃນກຸ່ມແມ່ນງ່າຍດາຍຫຼາຍຍ້ອນແນວຄວາມຄິດການບໍລິການ (ການບໍລິການ), ເຊິ່ງເປັນ IP virtual ທີ່ສະຫນັບສະຫນູນຊຸດຂອງທີ່ຢູ່ IP ຂອງ pod. ຕົວຢ່າງ, ຖ້າການບໍລິການ vanilla ຕ້ອງການຕິດຕໍ່ບໍລິການ chocolate, ມັນໂດຍກົງສາມາດເຂົ້າເຖິງ IP virtual ສໍາລັບ chocolate. ຄໍາຖາມທີ່ເກີດຂື້ນ: ໃຜໃນກໍລະນີນີ້ຈະແກ້ໄຂການຮ້ອງຂໍ DNS ກັບ chocolate ແລະແນວໃດ?

ການແກ້ໄຂຊື່ DNS ຖືກຕັ້ງຄ່າຢູ່ໃນກຸ່ມ Kubernetes ໂດຍໃຊ້ CoreDNS. Kubelet ລົງທະບຽນ pod ກັບ CoreDNS ເປັນ nameserver ໃນໄຟລ໌ /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 ມີຂໍ້ມູນຕໍ່ໄປນີ້:

nameserver: ເຊີບເວີທີ່ການຮ້ອງຂໍ 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 (ເຊິ່ງເຮັດໃຫ້ມັນຂ້ອນຂ້າງ verbose). ຂໍໃຫ້ເບິ່ງໄມ້ທ່ອນຂອງຝັກ 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 protocols. ທ່ານສາມາດຍົກເລີກພຶດຕິກໍານີ້ໄດ້ໂດຍການເພີ່ມທາງເລືອກ single-request в resolv.conf.

ຫມາຍເຫດ: glibc ສາມາດຖືກຕັ້ງຄ່າເພື່ອສົ່ງຄໍາຮ້ອງຂໍເຫຼົ່ານີ້ຕາມລໍາດັບ, ແລະ musl - ບໍ່, ດັ່ງນັ້ນຜູ້ໃຊ້ Alpine ຄວນເອົາໃຈໃສ່.

ການທົດລອງກັບ ndots

ໃຫ້ທົດລອງຕື່ມອີກເລັກນ້ອຍກັບ 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 ບໍ່ມີຈຸດດຽວ, ການຄົ້ນຫາໄດ້ຖືກປະຕິບັດໃນທົ່ວບັນຊີລາຍຊື່ຂອງ suffixes ທັງຫມົດ.

ຫມາຍເຫດ: ໃນການປະຕິບັດຄ່າສູງສຸດ ndots ຈໍາກັດເຖິງ 15; ໂດຍຄ່າເລີ່ມຕົ້ນໃນ Kubernetes ມັນແມ່ນ 5.

ຄໍາຮ້ອງສະຫມັກໃນການຜະລິດ

ຖ້າແອັບພລິເຄຊັນເຮັດການໂທເຄືອຂ່າຍພາຍນອກຫຼາຍ, DNS ສາມາດກາຍເປັນຂໍ້ບົກຜ່ອງໃນກໍລະນີຂອງການຈະລາຈອນທີ່ຫ້າວຫັນ, ນັບຕັ້ງແຕ່ການແກ້ໄຂຊື່ເຮັດໃຫ້ການສອບຖາມທີ່ບໍ່ຈໍາເປັນຫຼາຍ (ກ່ອນທີ່ລະບົບຈະໄປຫາທີ່ຖືກຕ້ອງ). ປົກກະຕິແລ້ວແອັບພລິເຄຊັນບໍ່ເພີ່ມເຂດຮາກໃສ່ຊື່ໂດເມນ, ແຕ່ນີ້ຄືການແຮັກ. ນັ້ນແມ່ນ, ແທນທີ່ຈະຖາມ api.twitter.com, ທ່ານສາມາດ 'hardcode' ມັນ api.twitter.com. (ມີຈຸດ) ໃນແອັບພລິເຄຊັນ, ເຊິ່ງຈະກະຕຸ້ນໃຫ້ລູກຄ້າ DNS ດໍາເນີນການຊອກຫາສິດອໍານາດໂດຍກົງໃນໂດເມນຢ່າງແທ້ຈິງ.

ນອກຈາກນັ້ນ, ເລີ່ມຕົ້ນດ້ວຍ Kubernetes ຮຸ່ນ 1.14, ສ່ວນຂະຫຍາຍ dnsConfig и dnsPolicy ໄດ້ຮັບສະຖານະພາບທີ່ຫມັ້ນຄົງ. ດັ່ງນັ້ນ, ເມື່ອນໍາໃຊ້ຝັກ, ທ່ານສາມາດຫຼຸດລົງມູນຄ່າ ndots, ເວົ້າວ່າ, ເຖິງ 3 (ແລະເຖິງແມ່ນເຖິງ 1!). ເນື່ອງຈາກວ່ານີ້, ທຸກໆຂໍ້ຄວາມພາຍໃນ node ຈະຕ້ອງປະກອບມີໂດເມນເຕັມ. ນີ້ແມ່ນ ໜຶ່ງ ໃນການຊື້ຂາຍແບບຄລາສສິກໃນເວລາທີ່ທ່ານຕ້ອງເລືອກລະຫວ່າງການປະຕິບັດແລະການກະພາ. ມັນເບິ່ງຄືວ່າຂ້ອຍຄວນກັງວົນກ່ຽວກັບເລື່ອງນີ້ເທົ່ານັ້ນຖ້າເວລາ latency ຕ່ໍາແມ່ນສໍາຄັນຕໍ່ຄໍາຮ້ອງສະຫມັກຂອງທ່ານ, ເພາະວ່າຜົນໄດ້ຮັບ DNS ຍັງຖືກເກັບໄວ້ພາຍໃນ.

ເອກະສານ

ຂ້າພະເຈົ້າທໍາອິດໄດ້ຮຽນຮູ້ກ່ຽວກັບຄຸນນະສົມບັດນີ້ກ່ຽວກັບ K8s-meetup, ໄດ້ຈັດຂຶ້ນໃນວັນທີ 25 ມັງກອນ. ມີການສົນທະນາກ່ຽວກັບບັນຫານີ້, ໃນບັນດາສິ່ງອື່ນໆ.

ນີ້ແມ່ນບາງການເຊື່ອມຕໍ່ສໍາລັບການຂຸດຄົ້ນເພີ່ມເຕີມ:

ຄໍາອະທິບາຍ, ເປັນຫຍັງ ndots=5 ໃນ Kubernetes;
ສິ່ງທີ່ຍິ່ງໃຫຍ່ ການປ່ຽນແປງ ndots ມີຜົນກະທົບຕໍ່ການປະຕິບັດຂອງແອັບພລິເຄຊັນແນວໃດ;
ຄວາມແຕກຕ່າງ ລະຫວ່າງ musl ແລະຕົວແກ້ໄຂ glibc.

ຫມາຍເຫດ: ຂ້ອຍເລືອກທີ່ຈະບໍ່ໃຊ້ dig ໃນບົດຄວາມນີ້. dig ເພີ່ມຈຸດອັດຕະໂນມັດ (ຕົວລະບຸເຂດຮາກ), ເຮັດໃຫ້ໂດເມນ "ມີຄຸນສົມບັດຄົບຖ້ວນ" (FQDN), ບໍ່ ໂດຍທໍາອິດແລ່ນມັນຜ່ານລາຍການຄົ້ນຫາ. ຂຽນກ່ຽວກັບເລື່ອງນີ້ໃນ ຫນຶ່ງໃນສິ່ງພິມທີ່ຜ່ານມາ. ຢ່າງໃດກໍ່ຕາມ, ມັນເປັນເລື່ອງແປກທີ່ໂດຍທົ່ວໄປແລ້ວ, ທຸງແຍກຕ່າງຫາກຕ້ອງໄດ້ຮັບການກໍານົດສໍາລັບພຶດຕິກໍາມາດຕະຖານ.

ຍິນດີ DNSing! ແລ້ວພົບກັນ!