ບັນຫາກັບ DNS ໃນ Kubernetes. ສົບສາທາລະນະ

ຫມາຍ​ເຫດ​ ການແປ: ນີ້ແມ່ນການແປຂອງ postmortem ສາທາລະນະຈາກ blog ວິສະວະກໍາຂອງບໍລິສັດ ພິເສດ. ມັນອະທິບາຍບັນຫາກັບ conntrack ໃນກຸ່ມ Kubernetes, ເຊິ່ງເຮັດໃຫ້ການຢຸດເວລາຂອງບາງບໍລິການການຜະລິດບາງສ່ວນ.

ບົດຄວາມນີ້ອາດຈະເປັນປະໂຫຍດສໍາລັບຜູ້ທີ່ຕ້ອງການຮຽນຮູ້ເພີ່ມເຕີມເລັກນ້ອຍກ່ຽວກັບການ postmortems ຫຼືປ້ອງກັນບາງບັນຫາ DNS ທີ່ເປັນໄປໄດ້ໃນອະນາຄົດ.

ນີ້ບໍ່ແມ່ນ DNS
ມັນບໍ່ສາມາດເປັນ DNS ໄດ້
ມັນແມ່ນ DNS

ເລັກນ້ອຍກ່ຽວກັບການເສຍຊີວິດແລະຂະບວນການໃນ Preply

Postmortem ອະທິບາຍເຖິງຄວາມຜິດປົກກະຕິຫຼືບາງເຫດການໃນການຜະລິດ. postmortem ປະ​ກອບ​ມີ​ກໍາ​ນົດ​ເວ​ລາ​ຂອງ​ເຫດ​ການ​, ຜົນ​ກະ​ທົບ​ຂອງ​ຜູ້​ໃຊ້​, ຮາກ​ຖານ​, ການ​ປະ​ຕິ​ບັດ​, ແລະ​ບົດ​ຮຽນ​ທີ່​ໄດ້​ຮັບ​.

ຊອກຫາ SRE

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

ບຸກຄົນທີ່ມີສ່ວນຮ່ວມໃນເຫດການຄວນຮູ້ສຶກວ່າເຂົາເຈົ້າສາມາດເວົ້າຢ່າງລະອຽດໂດຍບໍ່ຢ້ານການລົງໂທດ ຫຼືການລົງໂທດ. ບໍ່ມີຕໍານິ! ການຂຽນບົດສະຫຼຸບບໍ່ແມ່ນການລົງໂທດ, ແຕ່ເປັນໂອກາດການຮຽນຮູ້ສໍາລັບບໍລິສັດທັງຫມົດ.

Keep CALMS & DevOps: S ແມ່ນສໍາລັບການແບ່ງປັນ

ບັນຫາກັບ DNS ໃນ Kubernetes. Postmortem

ວັນ​ທີ່: 28.02.2020

ຜູ້ຂຽນ: Amet U., Andrey S., Igor K., Alexey P.

ສະຖານະພາບ: ສຳເລັດແລ້ວ

ສັ້ນ: ຄວາມບໍ່ມີ DNS ບາງສ່ວນ (26 ນາທີ) ສໍາລັບບາງບໍລິການໃນກຸ່ມ Kubernetes

ອິດທິພົນ: 15000 ເຫດການສູນເສຍສໍາລັບການບໍລິການ A, B ແລະ C

ສາເຫດຫຼັກ: Kube-proxy ບໍ່ສາມາດເອົາລາຍການເກົ່າອອກຈາກຕາຕະລາງ conntrack ໄດ້ຢ່າງຖືກຕ້ອງ, ດັ່ງນັ້ນບາງບໍລິການຍັງພະຍາຍາມເຊື່ອມຕໍ່ຫາພອດທີ່ບໍ່ມີຢູ່.

E0228 20:13:53.795782       1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...

ຕົວກະຕຸ້ນ: ເນື່ອງຈາກການໂຫຼດຕໍ່າຢູ່ພາຍໃນກຸ່ມ Kubernetes, CoreDNS-autoscaler ຫຼຸດລົງຈໍານວນຂອງຝັກໃນການນໍາໃຊ້ຈາກສາມຫາສອງ.

ການແກ້ໄຂ: ການປະຕິບັດຕໍ່ໄປຂອງແອັບພລິເຄຊັນໄດ້ລິເລີ່ມການສ້າງ nodes ໃໝ່, CoreDNS-autoscaler ໄດ້ເພີ່ມ pods ເພີ່ມເຕີມເພື່ອຮັບໃຊ້ກຸ່ມ, ເຊິ່ງກະຕຸ້ນໃຫ້ມີການຂຽນຄືນໃຫມ່ຂອງຕາຕະລາງ conntrack.

ການກວດຫາ: ການກວດສອບ Prometheus ໄດ້ກວດພົບຄວາມຜິດພາດ 5xx ຈໍານວນຫຼວງຫຼາຍສໍາລັບການບໍລິການ A, B ແລະ C ແລະໄດ້ເລີ່ມໂທຫາວິສະວະກອນທີ່ຢູ່ໃນຫນ້າທີ່.

5xx ຄວາມຜິດພາດໃນ Kibana

ການກະທໍາ

ຜົນກະທົບ
ປະເພດ
ຮັບຜິດຊອບ
ຈຸດປະສົງ

ປິດການນຳໃຊ້ຕົວຂະຫຍາຍອັດຕະໂນມັດສຳລັບ CoreDNS
ປ້ອງກັນ
Amet U.
DEVOPS-695

ຕັ້ງຄ່າເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ເກັບໄວ້ໃນຖານຄວາມຈໍາ
ຫຼຸດລົງ
ສູງສຸດ V.
DEVOPS-665

ຕັ້ງຄ່າການຕິດຕາມ conntrack
ປ້ອງກັນ
Amet U.
DEVOPS-674

ຖອດ​ຖອນ​ບົດ​ຮຽນ

ສິ່ງ​ທີ່​ເປັນ​ໄປ​ໄດ້​ດີ:

• ການຕິດຕາມເຮັດວຽກໄດ້ດີ. ການຕອບສະ ໜອງ ແມ່ນໄວແລະເປັນລະບຽບ
• ພວກ​ເຮົາ​ບໍ່​ໄດ້​ບັນ​ລຸ​ຂໍ້​ຈໍາ​ກັດ​ກ່ຽວ​ກັບ​ຂໍ້​ກໍາ​ນົດ​

ມີຫຍັງຜິດ:

• ຍັງບໍ່ຮູ້ສາເຫດທີ່ແທ້ຈິງ, ຄ້າຍຄືກັນກັບ ແມງໄມ້ສະເພາະ ໃນ​ການ​ຕິດ​ຕາມ
• ການ​ກະທຳ​ທັງ​ໝົດ​ແກ້​ໄຂ​ຜົນ​ຕາມ​ມາ​ເທົ່າ​ນັ້ນ, ບໍ່​ແມ່ນ​ຕົ້ນ​ເຫດ (bug)
• ພວກເຮົາຮູ້ວ່າໄວຫຼືຫຼັງຈາກນັ້ນພວກເຮົາອາດຈະມີບັນຫາກັບ DNS, ແຕ່ພວກເຮົາບໍ່ໄດ້ຈັດລໍາດັບຄວາມສໍາຄັນຂອງວຽກງານ

ບ່ອນທີ່ພວກເຮົາໂຊກດີ:

• ການນຳໃຊ້ຕໍ່ໄປແມ່ນໄດ້ກະຕຸ້ນໂດຍ CoreDNS-autoscaler, ເຊິ່ງຂຽນທັບຕາຕະລາງ conntrack
• ບັກນີ້ມີຜົນກະທົບພຽງແຕ່ບາງບໍລິການ

ທາມລາຍ (EET)

ເວລາ
ຜົນກະທົບ

22:13
CoreDNS-autoscaler ຫຼຸດລົງຈໍານວນຂອງຝັກຈາກສາມຫາສອງ

22:18
ວິສະວະກອນຢູ່ໃນຫນ້າທີ່ໄດ້ເລີ່ມຮັບສາຍຈາກລະບົບການຕິດຕາມ

22:21
ວິສະວະກອນຢູ່ໃນຫນ້າທີ່ໄດ້ເລີ່ມຕົ້ນຊອກຫາສາເຫດຂອງຄວາມຜິດພາດ.

22:39
ວິສະວະກອນຢູ່ໃນຫນ້າທີ່ໄດ້ເລີ່ມມ້ວນຫນຶ່ງຂອງການບໍລິການຫລ້າສຸດກັບສະບັບທີ່ຜ່ານມາ

22:40
5xx ຄວາມ​ຜິດ​ພາດ​ຢຸດ​ເຊົາ​ການ​ປາ​ກົດ​ຂຶ້ນ​, ສະ​ຖາ​ນະ​ການ​ໄດ້​ສະ​ຖຽນ​ລະ​ພາບ​

• ເວລາທີ່ຈະກວດພົບ: 4 min
• ເວລາກ່ອນການປະຕິບັດ: 21 min
• ເວລາທີ່ຈະແກ້ໄຂ: 1 min

ຂໍ້ມູນເພີ່ມເຕີມ

• ບັນທຶກ CoreDNS:

  I0228 20:13:53.507780       1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2

• ການເຊື່ອມຕໍ່ກັບ Kibana (ຕັດ), Grafana (ຕັດ)
• ບ່ອນທີ່ Linux conntrack ບໍ່ແມ່ນເພື່ອນຂອງເຈົ້າອີກຕໍ່ໄປ
• kube-proxy Subtleties: ການແກ້ບັນຫາການຕັ້ງການເຊື່ອມຕໍ່ແບບບໍ່ຢຸດຢັ້ງ
• ການໝົດເວລາຂອງການຄົ້ນຫາແບບ Racy ແລະ DNS

ເພື່ອຫຼຸດຜ່ອນການໃຊ້ CPU, Linux kernel ໃຊ້ບາງສິ່ງບາງຢ່າງທີ່ເອີ້ນວ່າ conntrack. ໃນສັ້ນ, ນີ້ແມ່ນຜົນປະໂຫຍດທີ່ມີບັນຊີລາຍຊື່ຂອງບັນທຶກ NAT ທີ່ເກັບໄວ້ໃນຕາຕະລາງພິເສດ. ເມື່ອຊຸດຕໍ່ໄປມາຮອດຈາກຝັກດຽວກັນໄປຫາຝັກດຽວກັນກັບກ່ອນ, ທີ່ຢູ່ IP ສຸດທ້າຍຈະບໍ່ຖືກຄິດໄລ່ຄືນໃຫມ່, ແຕ່ຈະຖືກນໍາມາຈາກຕາຕະລາງ conntrack.

ວິທີການເຮັດວຽກ conttrack

ຜົນໄດ້ຮັບ

ນີ້ແມ່ນຕົວຢ່າງຫນຶ່ງຂອງ postmortems ຂອງພວກເຮົາທີ່ມີບາງເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດ. ໂດຍສະເພາະໃນບົດຄວາມນີ້, ພວກເຮົາແບ່ງປັນຂໍ້ມູນທີ່ອາດຈະເປັນປະໂຫຍດກັບບໍລິສັດອື່ນໆ. ນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາບໍ່ຢ້ານທີ່ຈະເຮັດຜິດພາດແລະນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາເຮັດໃຫ້ຫນຶ່ງໃນການເສຍຊີວິດຂອງພວກເຮົາເປັນສາທາລະນະ. ນີ້ແມ່ນບາງເຫດການ postmortems ສາທາລະນະທີ່ຫນ້າສົນໃຈຫຼາຍ:

• GitLab: Postmortem ຂອງ​ການ​ສູນ​ເສຍ​ຖານ​ຂໍ້​ມູນ​ຂອງ​ເດືອນ​ມັງ​ກອນ 31​
• Dropbox: Outage post-mortem
• Spotify: ຄວາມສໍາພັນຄວາມຮັກ / ຄວາມກຽດຊັງຂອງ Spotify ກັບ DNS
• ຄົນອື່ນຈໍານວນຫຼາຍຈາກ ບົດ​ຄວາມ​ນີ້ ແລະ repository Kubernetes ເລື່ອງຄວາມລົ້ມເຫລວ
• ນອກຈາກນັ້ນ ຕົວຢ່າງ postmortem ສາ​ທາ​ລະ​ນະ​ກັບ SRE Book

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