/etc/resolv.conf ສໍາລັບ Kubernetes pods, ndots:5 ທາງເລືອກ, ສິ່ງນີ້ມີຜົນກະທົບທາງລົບຕໍ່ການປະຕິບັດຂອງແອັບພລິເຄຊັນແນວໃດ

ພວກເຮົາບໍ່ດົນມານີ້ໄດ້ເປີດຕົວ Kubernetes 1.9 ໃນ AWS ໂດຍໃຊ້ Kops. ມື້ວານນີ້, ໃນຂະນະທີ່ເຮັດໃຫ້ການຈະລາຈອນໃຫມ່ເຂົ້າໄປໃນກຸ່ມ Kubernetes ທີ່ໃຫຍ່ທີ່ສຸດຂອງພວກເຮົາ, ຂ້ອຍເລີ່ມສັງເກດເຫັນຄວາມຜິດພາດການແກ້ໄຂຊື່ DNS ທີ່ຜິດປົກກະຕິທີ່ເຂົ້າສູ່ລະບົບໂດຍແອັບພລິເຄຊັນຂອງພວກເຮົາ.

ມີຫຼາຍຢ່າງກ່ຽວກັບເລື່ອງນີ້ຢູ່ໃນ GitHub ເວົ້າ, ສະນັ້ນຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈທີ່ຈະຄິດອອກຄືກັນ. ໃນທີ່ສຸດ, ຂ້າພະເຈົ້າໄດ້ຮັບຮູ້ວ່າໃນກໍລະນີຂອງພວກເຮົານີ້ແມ່ນເກີດມາຈາກການໂຫຼດເພີ່ມຂຶ້ນ kube-dns и dnsmasq. ສິ່ງທີ່ຫນ້າສົນໃຈແລະໃຫມ່ທີ່ສຸດສໍາລັບຂ້ອຍແມ່ນເຫດຜົນສໍາລັບການເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍໃນການເຂົ້າຊົມການຮ້ອງຂໍ DNS. ຂໍ້ຄວາມຂອງຂ້ອຍແມ່ນກ່ຽວກັບເລື່ອງນີ້ແລະສິ່ງທີ່ຕ້ອງເຮັດກ່ຽວກັບມັນ.

ຄວາມລະອຽດ DNS ພາຍໃນກ່ອງບັນຈຸ - ຄືກັບລະບົບ Linux ໃດກໍ່ຕາມ - ຖືກກໍານົດໂດຍໄຟລ໌ການຕັ້ງຄ່າ /etc/resolv.conf. Kubernetes ເລີ່ມຕົ້ນ dnsPolicy ມັນ ClusterFirst, ຊຶ່ງຫມາຍຄວາມວ່າຄໍາຮ້ອງຂໍ DNS ຈະຖືກສົ່ງຕໍ່ໄປຫາ dnsmasq, ແລ່ນຢູ່ໃນຝັກ kube-dns ພາຍໃນກຸ່ມ, ເຊິ່ງໃນນັ້ນຈະສົ່ງຕໍ່ຄໍາຮ້ອງຂໍໄປຍັງແອັບພລິເຄຊັນ kube-dns, ຖ້າຊື່ລົງທ້າຍດ້ວຍຄໍາຕໍ່ທ້າຍກຸ່ມ, ຫຼື, ຖ້າບໍ່ດັ່ງນັ້ນ, ໄປຫາເຄື່ອງແມ່ຂ່າຍ DNS ລະດັບສູງກວ່າ.

ເອກະສານ /etc/resolv.conf ພາຍໃນແຕ່ລະ container ຄ່າເລີ່ມຕົ້ນຈະມີລັກສະນະດັ່ງນີ້:

nameserver 100.64.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local 
eu-west-1.compute.internal
options ndots:5

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ມີສາມຄໍາແນະນໍາ:

1. ເຄື່ອງແມ່ຂ່າຍຊື່ແມ່ນ IP ຂອງການບໍລິການ kube-dns
2. 4 ໂດເມນຄົ້ນຫາໃນທ້ອງຖິ່ນທີ່ລະບຸໄວ້ search
3. ມີທາງເລືອກ ndots:5

ສ່ວນທີ່ຫນ້າສົນໃຈຂອງການຕັ້ງຄ່ານີ້ແມ່ນວິທີການໂດເມນຄົ້ນຫາໃນທ້ອງຖິ່ນແລະການຕັ້ງຄ່າ ndots:5 ເຂົ້າກັນໄດ້. ເພື່ອເຂົ້າໃຈເລື່ອງນີ້, ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈວິທີການແກ້ໄຂ DNS ສໍາລັບຊື່ທີ່ບໍ່ມີເງື່ອນໄຂເຮັດວຽກ.

ຊື່ເຕັມແມ່ນຫຍັງ?

ຊື່ທີ່ມີຄຸນວຸດທິຄົບຖ້ວນແມ່ນຊື່ທີ່ບໍ່ມີການຄົ້ນຫາໃນທ້ອງຖິ່ນແລະຊື່ຈະຖືກພິຈາລະນາຢ່າງແທ້ຈິງໃນລະຫວ່າງການແກ້ໄຂຊື່. ໂດຍສົນທິສັນຍາ, ຊອບແວ DNS ພິຈາລະນາຊື່ທີ່ຈະມີຄຸນສົມບັດຢ່າງເຕັມທີ່ຖ້າມັນລົງທ້າຍດ້ວຍຈຸດ (.), ແລະບໍ່ມີຄຸນສົມບັດຄົບຖ້ວນ. ນັ້ນ​ແມ່ນ google.com. ກໍາ​ນົດ​ຢ່າງ​ເຕັມ​ທີ່​ແລະ​ google.com - ບໍ່.

ຊື່ທີ່ບໍ່ມີເງື່ອນໄຂຖືກຈັດການແນວໃດ?

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

ຈາກຄູ່ມື resolv.conf:

ndots:n

устанавливает порог для количества точек, которые должны появиться в имени, прежде чем будет сделан начальный абсолютный запрос. Значение по умолчанию для n равно 1, что означает, что если в имени есть какие-либо точки, имя будет сначала опробовано как абсолютное имя, прежде чем к нему будут добавлены какие-либо элементы списка поиска.

ນີ້ຫມາຍຄວາມວ່າຖ້າສໍາລັບ ndots ໃຫ້ມູນຄ່າຂອງ 5 ແລະຊື່ມີຫນ້ອຍກວ່າ 5 ຈຸດ, ການໂທຫາລະບົບຈະພະຍາຍາມແກ້ໄຂມັນຕາມລໍາດັບ, ທໍາອິດຜ່ານໂດເມນຄົ້ນຫາໃນທ້ອງຖິ່ນທັງຫມົດ, ແລະ, ຖ້າບໍ່ສໍາເລັດ, ໃນທີ່ສຸດການແກ້ໄຂມັນເປັນຊື່ຢ່າງແທ້ຈິງ.

ເປັນຫຍັງຫຼັງຈາກນັ້ນ ndots:5 ມັນສາມາດສົ່ງຜົນກະທົບທາງລົບຕໍ່ການປະຕິບັດຂອງແອັບພລິເຄຊັນບໍ?

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

ຕາຕະລາງຕໍ່ໄປນີ້ສະແດງໃຫ້ເຫັນການຈາລະຈອນທັງຫມົດໃນ 3 ໂມດູນ kube-dns ຂອງພວກເຮົາກ່ອນແລະຫຼັງຈາກພວກເຮົາປ່ຽນຊື່ໂຮດຈໍານວນຫນ້ອຍທີ່ຖືກຕັ້ງຄ່າໃນແອັບພລິເຄຊັນຂອງພວກເຮົາໃຫ້ກັບຜູ້ທີ່ມີຄຸນສົມບັດຄົບຖ້ວນ.

ແຜນວາດຕໍ່ໄປນີ້ສະແດງໃຫ້ເຫັນເຖິງການຊັກຊ້າຂອງແອັບພລິເຄຊັນກ່ອນ ແລະຫຼັງຈາກພວກເຮົາປ່ຽນຊື່ໂຮດຫຼາຍໆອັນທີ່ຕັ້ງຢູ່ໃນແອັບພລິເຄຊັນຂອງພວກເຮົາເປັນຊື່ເຕັມ (ເສັ້ນສີຟ້າຕັ້ງແມ່ນການນຳໃຊ້):

ການແກ້ໄຂ #1 - ໃຊ້ຊື່ທີ່ມີຄຸນສົມບັດຄົບຖ້ວນ

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

ນີ້ບໍ່ແມ່ນການແກ້ໄຂສຸດທ້າຍ, ແຕ່ມັນຈະຊ່ວຍໃຫ້ໄວ, ເຖິງແມ່ນວ່າບໍ່ສະອາດ, ປັບປຸງສະຖານະການ. ພວກເຮົາໄດ້ນໍາໃຊ້ patch ນີ້ເພື່ອແກ້ໄຂບັນຫາຂອງພວກເຮົາ, ຜົນໄດ້ຮັບທີ່ໄດ້ສະແດງໃຫ້ເຫັນໃນ screenshots ຂ້າງເທິງ.

ການແກ້ໄຂ #2 - ການປັບແຕ່ງ ndots в dnsConfig

ໃນ Kubernetes 1.9, ການທໍາງານປາກົດຢູ່ໃນໂຫມດ alpha (ລຸ້ນ beta v1.10), ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດຄວບຄຸມຕົວກໍານົດການ DNS ໄດ້ດີຂຶ້ນໂດຍຜ່ານຄຸນສົມບັດ pod ໃນ dnsConfig. ໃນບັນດາສິ່ງອື່ນໆ, ມັນຊ່ວຍໃຫ້ທ່ານສາມາດກໍາຫນົດຄ່າໄດ້ ndots ສໍາລັບຝັກສະເພາະ, i.e.

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

ແຫຼ່ງຂໍ້ມູນ

• ຄຸນສົມບັດຊື່ DNS ແມ່ນຫຍັງ
• Kubernetes: DNS ສໍາລັບການບໍລິການ ແລະ Pods

ອ່ານບົດຄວາມອື່ນໆໃນ blog ຂອງພວກເຮົາ:

• ຄວາມເຂົ້າໃຈຊຸດ Context ໃນ Golang
• ສາມ tricks ງ່າຍດາຍທີ່ຈະຫຍໍ້ຮູບພາບ Docker
• ຂໍ້ມູນສຳຮອງໃນ Kubernetes
• ການສໍາຮອງຂອງຈໍານວນຂະຫນາດໃຫຍ່ຂອງໂຄງການເວັບໄຊຕ໌ heterogeneous
• Telegram bot ສໍາລັບ Redmine. ວິທີການເຮັດໃຫ້ຊີວິດງ່າຍສໍາລັບຕົວທ່ານເອງແລະຄົນອື່ນ

ແຫຼ່ງຂໍ້ມູນ: www.habr.com