ການປ່ຽນແປງ Tinder ໄປ Kubernetes

ຫມາຍ​ເຫດ​. ແປ.: ພະນັກງານຂອງບໍລິການ Tinder ທີ່ມີຊື່ສຽງຂອງໂລກເມື່ອບໍ່ດົນມານີ້ໄດ້ແບ່ງປັນບາງລາຍລະອຽດດ້ານວິຊາການຂອງການເຄື່ອນຍ້າຍພື້ນຖານໂຄງລ່າງຂອງພວກເຂົາໄປ Kubernetes. ຂະບວນການດັ່ງກ່າວໄດ້ໃຊ້ເວລາເກືອບສອງປີແລະສົ່ງຜົນໃຫ້ມີການເປີດຕົວແພລະຕະຟອມຂະຫນາດໃຫຍ່ຫຼາຍໃນ K8s, ປະກອບດ້ວຍບໍລິການ 200 ທີ່ເປັນເຈົ້າພາບໃນ 48 ພັນຕູ້ຄອນເທນເນີ. ວິສະວະກອນ Tinder ປະສົບກັບຄວາມຫຍຸ້ງຍາກອັນໃດທີ່ຫນ້າສົນໃຈແລະຜົນໄດ້ຮັບແມ່ນຫຍັງ? ອ່ານຄໍາແປນີ້.

ເປັນຫຍັງ?

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

ພວກເຮົາຍັງຊອກຫາວິທີແກ້ໄຂບັນຫາຂອງການຂະຫຍາຍ ແລະສະຖຽນລະພາບ. ເມື່ອການປັບຂະ ໜາດ ກາຍເປັນຄວາມ ສຳ ຄັນ, ພວກເຮົາມັກຈະຕ້ອງລໍຖ້າຫຼາຍໆນາທີເພື່ອໃຫ້ຕົວຢ່າງ EC2 ໃໝ່ ໝູນ. ຄວາມຄິດຂອງການເປີດຕົວຕູ້ຄອນເທນເນີແລະເລີ່ມຕົ້ນໃຫ້ບໍລິການການຈະລາຈອນໃນວິນາທີແທນທີ່ຈະເປັນນາທີໄດ້ກາຍເປັນທີ່ຫນ້າສົນໃຈຫຼາຍສໍາລັບພວກເຮົາ.

ຂະບວນການດັ່ງກ່າວໄດ້ກາຍມາເປັນຄວາມຫຍຸ້ງຍາກ. ໃນລະຫວ່າງການເຄື່ອນຍ້າຍຂອງພວກເຮົາໃນຕົ້ນປີ 2019, ກຸ່ມ Kubernetes ໄດ້ບັນລຸເຖິງຈໍານວນທີ່ສໍາຄັນ ແລະພວກເຮົາເລີ່ມພົບບັນຫາຕ່າງໆເນື່ອງຈາກປະລິມານການສັນຈອນ, ຂະໜາດຂອງກຸ່ມ ແລະ DNS. ຄຽງຄູ່ກັບວິທີການ, ພວກເຮົາໄດ້ແກ້ໄຂບັນຫາທີ່ຫນ້າສົນໃຈຫຼາຍທີ່ກ່ຽວຂ້ອງກັບການເຄື່ອນຍ້າຍ 200 ການບໍລິການແລະການຮັກສາກຸ່ມ Kubernetes ທີ່ປະກອບດ້ວຍ 1000 nodes, 15000 pods ແລະ 48000 containers ແລ່ນ.

ແນວໃດ?

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

ການສ້າງຮູບພາບສໍາລັບ Kubernetes

ພວກເຮົາມີຫຼາຍກວ່າ 30 source code repositories ສໍາລັບ microservices ທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມ Kubernetes. ລະຫັດໃນ repositories ເຫຼົ່ານີ້ແມ່ນຂຽນເປັນພາສາທີ່ແຕກຕ່າງກັນ (ຕົວຢ່າງ: Node.js, Java, Scala, Go) ທີ່ມີສະພາບແວດລ້ອມ runtime ຫຼາຍສໍາລັບພາສາດຽວກັນ.

ລະບົບການກໍ່ສ້າງໄດ້ຖືກອອກແບບເພື່ອໃຫ້ "ສະພາບການສ້າງ" ທີ່ສາມາດປັບແຕ່ງໄດ້ຢ່າງເຕັມສ່ວນສໍາລັບແຕ່ລະ microservice. ມັນມັກຈະປະກອບດ້ວຍ Dockerfile ແລະບັນຊີລາຍຊື່ຂອງຄໍາສັ່ງ shell. ເນື້ອຫາຂອງພວກເຂົາແມ່ນສາມາດປັບແຕ່ງໄດ້ຢ່າງສົມບູນ, ແລະໃນເວລາດຽວກັນ, ການກໍ່ສ້າງທັງຫມົດເຫຼົ່ານີ້ຖືກຂຽນຕາມຮູບແບບມາດຕະຖານ. ການສ້າງມາດຕະຖານ contexts ອະນຸຍາດໃຫ້ລະບົບການກໍ່ສ້າງດຽວສາມາດຈັດການກັບ microservices ທັງຫມົດ.

ຮູບທີ 1-1. ຂະບວນການສ້າງມາດຕະຖານຜ່ານ Builder container

ເພື່ອບັນລຸຄວາມສອດຄ່ອງສູງສຸດລະຫວ່າງ runtimes (ສະ​ພາບ​ແວດ​ລ້ອມ runtime​) ຂະບວນການກໍ່ສ້າງດຽວກັນຖືກນໍາໃຊ້ໃນລະຫວ່າງການພັດທະນາແລະການທົດສອບ. ພວກເຮົາປະເຊີນກັບສິ່ງທ້າທາຍທີ່ຫນ້າສົນໃຈຫຼາຍ: ພວກເຮົາຕ້ອງພັດທະນາວິທີການເພື່ອຮັບປະກັນຄວາມສອດຄ່ອງຂອງສະພາບແວດລ້ອມການກໍ່ສ້າງໃນທົ່ວເວທີທັງຫມົດ. ເພື່ອເຮັດສິ່ງນີ້, ຂະບວນການປະກອບທັງຫມົດແມ່ນດໍາເນີນຢູ່ໃນຖັງພິເສດ. Builder.

ການປະຕິບັດພາຊະນະຂອງລາວຕ້ອງການເຕັກນິກ Docker ຂັ້ນສູງ. Builder ສືບທອດ ID ຜູ້ໃຊ້ທ້ອງຖິ່ນ ແລະຄວາມລັບ (ເຊັ່ນ: ກະແຈ SSH, ຂໍ້ມູນປະຈໍາຕົວຂອງ AWS, ແລະອື່ນໆ) ທີ່ຈໍາເປັນເພື່ອເຂົ້າເຖິງບ່ອນເກັບຂໍ້ມູນ Tinder ສ່ວນຕົວ. ມັນຕິດຕັ້ງໄດເລກະທໍລີທ້ອງຖິ່ນທີ່ມີແຫຼ່ງຕ່າງໆເພື່ອເກັບຮັກສາສິ່ງປະດິດສ້າງຕາມທໍາມະຊາດ. ວິທີການນີ້ປັບປຸງການປະຕິບັດເນື່ອງຈາກວ່າມັນກໍາຈັດຄວາມຕ້ອງການທີ່ຈະຄັດລອກສິ່ງປະດິດລະຫວ່າງ Builder container ແລະເຈົ້າພາບ. ວັດຖຸປະດິດສ້າງທີ່ເກັບໄວ້ສາມາດນໍາມາໃຊ້ຄືນໄດ້ໂດຍບໍ່ມີການກໍາຫນົດຄ່າເພີ່ມເຕີມ.

ສໍາລັບບາງບໍລິການ, ພວກເຮົາຕ້ອງສ້າງ container ອື່ນເພື່ອສ້າງແຜນທີ່ສະພາບແວດລ້ອມການລວບລວມກັບສະພາບແວດລ້ອມ runtime (ຕົວຢ່າງເຊັ່ນ, Node.js bcrypt library ກໍ່ສ້າງ binary artifacts ສະເພາະເວທີໃນລະຫວ່າງການຕິດຕັ້ງ). ໃນລະຫວ່າງການລວບລວມຂໍ້ມູນ, ຄວາມຕ້ອງການອາດຈະແຕກຕ່າງກັນລະຫວ່າງການບໍລິການ, ແລະ Dockerfile ສຸດທ້າຍຈະຖືກລວບລວມໃນທັນທີ.

ສະຖາປັດຕະຍະກຳຂອງກຸ່ມ Kubernetes ແລະການເຄື່ອນຍ້າຍ

ການຈັດການຂະຫນາດກຸ່ມ

ພວກເຮົາຕັດສິນໃຈໃຊ້ kube-aws ສໍາລັບການຕິດຕັ້ງກຸ່ມອັດຕະໂນມັດໃນ Amazon EC2 instances. ໃນຕອນເລີ່ມຕົ້ນ, ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຢູ່ໃນສະນຸກເກີທົ່ວໄປດຽວ. ພວກ​ເຮົາ​ໄດ້​ຮັບ​ຮູ້​ຢ່າງ​ວ່ອງ​ໄວ​ເຖິງ​ຄວາມ​ຈຳ​ເປັນ​ທີ່​ຈະ​ແຍກ​ຂະ​ໜາດ​ວຽກ​ອອກ​ຕາມ​ຂະ​ໜາດ ແລະ ປະ​ເພດ​ຕົວ​ຢ່າງ ເພື່ອ​ນຳ​ໃຊ້​ຊັບ​ພະ​ຍາ​ກອນ​ຢ່າງ​ມີ​ປະ​ສິດ​ທິ​ຜົນ​ກວ່າ. ເຫດຜົນແມ່ນວ່າການແລ່ນ pods ຫຼາຍ threaded ໂຫຼດຫຼາຍໄດ້ຫັນອອກເປັນການຄາດເດົາຫຼາຍໃນແງ່ຂອງປະສິດທິພາບຫຼາຍກ່ວາການຢູ່ຮ່ວມກັນຂອງເຂົາເຈົ້າທີ່ມີຈໍານວນຫລາຍຂອງຝັກດຽວ threaded.

ໃນທີ່ສຸດພວກເຮົາໄດ້ຕົກລົງ:

• m5.4x ໃຫຍ່ — ສໍາ​ລັບ​ການ​ຕິດ​ຕາມ (Prometheus​)​;
• c5.4xlarge - ສໍາລັບ Node.js workload (single-threaded workload);
• c5.2xlarge - ສໍາ​ລັບ Java ແລະ Go (ການ​ເຮັດ​ວຽກ multithreaded​)​;
• c5.4xlarge - ສໍາລັບແຜງຄວບຄຸມ (3 nodes).

ການເຄື່ອນຍ້າຍ

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

ຈຸດສິ້ນສຸດເຫຼົ່ານີ້ຖືກສ້າງຂື້ນໂດຍໃຊ້ຊຸດບັນທຶກ DNS ທີ່ມີນ້ໍາຫນັກທີ່ມີ CNAMEs ຊີ້ໄປຫາແຕ່ລະ ELB ໃຫມ່. ເພື່ອສະຫຼັບ, ພວກເຮົາໄດ້ເພີ່ມລາຍການໃຫມ່ທີ່ຊີ້ໄປຫາ ELB ໃຫມ່ຂອງບໍລິການ Kubernetes ທີ່ມີນ້ໍາຫນັກ 0. ຫຼັງຈາກນັ້ນ, ພວກເຮົາກໍານົດເວລາທີ່ຈະດໍາລົງຊີວິດ (TTL) ຂອງການເຂົ້າທີ່ກໍານົດໄວ້ເປັນ 0. ຫຼັງຈາກນີ້, ນ້ໍາຫນັກເກົ່າແລະໃຫມ່ແມ່ນ. ປັບຕົວຊ້າໆ, ແລະໃນທີ່ສຸດ 100% ຂອງການໂຫຼດໄດ້ຖືກສົ່ງໄປຫາເຄື່ອງແມ່ຂ່າຍໃຫມ່. ຫຼັງ​ຈາກ​ການ​ສະ​ຫຼັບ​ໄດ້​ສໍາ​ເລັດ​, ຄ່າ TTL ກັບ​ຄືນ​ໄປ​ບ່ອນ​ທີ່​ພຽງ​ພໍ​ຫຼາຍ​ກວ່າ​.

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

ບົດຮຽນ

ຂອບເຂດຈໍາກັດຂອງຜ້າເຄືອຂ່າຍ

ໃນຕອນເຊົ້າຂອງວັນທີ 8 ມັງກອນ 2019, ເວທີ Tinder ເກີດອຸປະຕິເຫດຢ່າງບໍ່ຄາດຄິດ. ໃນການຕອບສະຫນອງຕໍ່ການເພີ່ມຂຶ້ນທີ່ບໍ່ກ່ຽວຂ້ອງໃນຄວາມຊັກຊ້າຂອງເວທີໃນຕອນເຊົ້ານັ້ນ, ຈໍານວນຂອງຝັກແລະຂໍ້ໃນກຸ່ມເພີ່ມຂຶ້ນ. ອັນນີ້ເຮັດໃຫ້ ARP cache ໝົດໄປໃນທຸກ nodes ຂອງພວກເຮົາ.

ມີສາມທາງເລືອກ Linux ທີ່ກ່ຽວຂ້ອງກັບ cache ARP:

(ແຫຼ່ງຂໍ້ມູນ)

gc_thresh3 - ນີ້​ແມ່ນ​ຂອບ​ເຂດ​ຈໍາ​ກັດ​ຍາກ​. ຮູບລັກສະນະຂອງລາຍການ "ການລົ້ນຕາຕະລາງເພື່ອນບ້ານ" ໃນບັນທຶກຫມາຍຄວາມວ່າເຖິງແມ່ນວ່າຫຼັງຈາກການເກັບຂີ້ເຫຍື້ອ synchronous (GC), ບໍ່ມີພື້ນທີ່ພຽງພໍໃນ cache ARP ເພື່ອເກັບຂໍ້ມູນໃກ້ຄຽງ. ໃນກໍລະນີນີ້, ແກ່ນພຽງແຕ່ຖິ້ມແພັກເກັດຫມົດ.

ພວກເຮົາໃຊ້ Flannel ເປັນຜ້າເຄືອຂ່າຍໃນ Kubernetes. ແພັກເກັດຖືກສົ່ງຜ່ານ VXLAN. VXLAN ແມ່ນອຸໂມງ L2 ທີ່ຍົກຂຶ້ນມາຢູ່ເທິງສຸດຂອງເຄືອຂ່າຍ L3. ເທກໂນໂລຍີໃຊ້ MAC-in-UDP (MAC Address-in-User Datagram Protocol) encapsulation ແລະອະນຸຍາດໃຫ້ຂະຫຍາຍພາກສ່ວນເຄືອຂ່າຍ Layer 2. ໂປໂຕຄອນການຂົນສົ່ງໃນເຄືອຂ່າຍສູນຂໍ້ມູນທາງດ້ານຮ່າງກາຍແມ່ນ IP ບວກ UDP.

ຮູບ 2–1. ແຜນວາດ Flannel (ແຫຼ່ງຂໍ້ມູນ)

ຮູບທີ 2-2. ຊຸດ VXLAN (ແຫຼ່ງຂໍ້ມູນ)

ແຕ່ລະ node ພະນັກງານ Kubernetes ຈັດສັນພື້ນທີ່ທີ່ຢູ່ virtual ກັບ /24 ຫນ້າກາກຈາກ /9 block ຂະຫນາດໃຫຍ່. ສໍາລັບແຕ່ລະ node ນີ້ແມ່ນ ຫມາຍຄວາມວ່າ ຫນຶ່ງເຂົ້າໃນຕາຕະລາງເສັ້ນທາງ, ຫນຶ່ງເຂົ້າໃນຕາຕະລາງ ARP (ໃນການໂຕ້ຕອບ flannel.1), ແລະຫນຶ່ງໃນຕາຕະລາງສະຫຼັບ (FDB). ພວກມັນຖືກເພີ່ມໃນຄັ້ງທຳອິດທີ່ໂຫມດຜູ້ເຮັດວຽກຖືກເລີ່ມຕົ້ນ ຫຼືແຕ່ລະຄັ້ງທີ່ໂນດໃໝ່ຖືກຄົ້ນພົບ.

ນອກຈາກນັ້ນ, ການສື່ສານ node-pod (ຫຼື pod-pod) ສຸດທ້າຍຜ່ານການໂຕ້ຕອບ eth0 (ດັ່ງທີ່ສະແດງຢູ່ໃນແຜນວາດ Flannel ຂ້າງເທິງ). ອັນນີ້ສົ່ງຜົນໃຫ້ມີການເຂົ້າມາເພີ່ມເຕີມໃນຕາຕະລາງ ARP ສໍາລັບແຕ່ລະແຫຼ່ງທີ່ສອດຄ້ອງກັນ ແລະເຈົ້າພາບປາຍທາງ.

ໃນສະພາບແວດລ້ອມຂອງພວກເຮົາ, ປະເພດຂອງການສື່ສານນີ້ແມ່ນທົ່ວໄປຫຼາຍ. ສໍາລັບວັດຖຸບໍລິການໃນ Kubernetes, ELB ຖືກສ້າງຂຶ້ນ ແລະ Kubernetes ລົງທະບຽນແຕ່ລະ node ກັບ ELB. ELB ບໍ່ຮູ້ຫຍັງກ່ຽວກັບຝັກ ແລະ node ທີ່ເລືອກອາດຈະບໍ່ເປັນປາຍທາງສຸດທ້າຍຂອງແພັກເກັດ. ຈຸດແມ່ນວ່າເມື່ອ node ໄດ້ຮັບແພັກເກັດຈາກ ELB, ມັນພິຈາລະນາມັນຄໍານຶງເຖິງກົດລະບຽບ. iptables ສໍາລັບການບໍລິການສະເພາະ ແລະສຸ່ມເລືອກຝັກໃນ node ອື່ນ.

ໃນເວລາທີ່ຄວາມລົ້ມເຫຼວ, ມີ 605 nodes ໃນ cluster. ສໍາລັບເຫດຜົນທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ນີ້ແມ່ນພຽງພໍທີ່ຈະເອົາຊະນະຄວາມສໍາຄັນ gc_thresh3, ຊຶ່ງເປັນຄ່າເລີ່ມຕົ້ນ. ເມື່ອສິ່ງນີ້ເກີດຂື້ນ, ບໍ່ພຽງແຕ່ແພັກເກັດເລີ່ມຖືກຫຼຸດລົງ, ແຕ່ພື້ນທີ່ທີ່ຢູ່ virtual Flannel ທັງຫມົດທີ່ມີຫນ້າກາກ / 24 ຫາຍໄປຈາກຕາຕະລາງ ARP. ການສື່ສານ Node-pod ແລະການສອບຖາມ DNS ຖືກລົບກວນ (DNS ຖືກໂຮດຢູ່ໃນ cluster; ອ່ານຕໍ່ມາໃນບົດຄວາມນີ້ສໍາລັບລາຍລະອຽດ).

ເພື່ອແກ້ໄຂບັນຫານີ້, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມມູນຄ່າ gc_thresh1, gc_thresh2 и gc_thresh3 ແລະຣີສະຕາດ Flannel ເພື່ອລົງທະບຽນເຄືອຂ່າຍທີ່ຂາດຫາຍໄປຄືນໃໝ່.

ການຂະຫຍາຍ DNS ທີ່ບໍ່ຄາດຄິດ

ໃນລະຫວ່າງຂະບວນການເຄື່ອນຍ້າຍ, ພວກເຮົາໄດ້ໃຊ້ DNS ຢ່າງຈິງຈັງເພື່ອຈັດການການຈະລາຈອນ ແລະຄ່ອຍໆໂອນການບໍລິການຈາກໂຄງສ້າງພື້ນຖານເກົ່າໄປຫາ Kubernetes. ພວກເຮົາກໍານົດຄ່າ TTL ທີ່ຂ້ອນຂ້າງຕ່ໍາສໍາລັບ RecordSets ທີ່ກ່ຽວຂ້ອງໃນ Route53. ເມື່ອໂຄງສ້າງພື້ນຖານເກົ່າເຮັດວຽກຢູ່ໃນຕົວຢ່າງ EC2, ການຕັ້ງຄ່າຕົວແກ້ໄຂຂອງພວກເຮົາຊີ້ໃຫ້ເຫັນ Amazon DNS. ພວກເຮົາໄດ້ເອົາອັນນີ້ໄວ້ເພື່ອອະນຸຍາດແລະຜົນກະທົບຂອງ TTL ຕ່ໍາຕໍ່ການບໍລິການຂອງພວກເຮົາແລະການບໍລິການ Amazon (ເຊັ່ນ: DynamoDB) ບໍ່ໄດ້ສັງເກດເຫັນສ່ວນໃຫຍ່.

ໃນຂະນະທີ່ພວກເຮົາຍ້າຍການບໍລິການໄປຫາ Kubernetes, ພວກເຮົາພົບວ່າ DNS ກໍາລັງປະມວນຜົນ 250 ພັນຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ. ດັ່ງນັ້ນ, ແອັບພລິເຄຊັນເລີ່ມປະສົບກັບການຫມົດເວລາຄົງທີ່ແລະຮ້າຍແຮງສໍາລັບການສອບຖາມ DNS. ນີ້ເກີດຂຶ້ນເຖິງວ່າຈະມີຄວາມພະຍາຍາມຢ່າງບໍ່ຫນ້າເຊື່ອທີ່ຈະເພີ່ມປະສິດທິພາບແລະປ່ຽນຜູ້ໃຫ້ບໍລິການ DNS ໄປຫາ CoreDNS (ເຊິ່ງການໂຫຼດສູງສຸດເຖິງ 1000 pods ແລ່ນຢູ່ໃນ 120 cores).

ໃນຂະນະທີ່ການຄົ້ນຄວ້າສາເຫດທີ່ເປັນໄປໄດ້ແລະວິທີແກ້ໄຂອື່ນໆ, ພວກເຮົາໄດ້ຄົ້ນພົບ ບົດຄວາມ, ອະທິບາຍເງື່ອນໄຂເຊື້ອຊາດທີ່ມີຜົນກະທົບຕໍ່ກອບການກັ່ນຕອງຊຸດ ເນັດ ໃນ Linux. ເວລາໝົດເວລາທີ່ພວກເຮົາສັງເກດເຫັນ, ບວກກັບການນັບມື້ນັບເພີ່ມຂຶ້ນ insert_failed ໃນການໂຕ້ຕອບ Flannel ແມ່ນສອດຄ່ອງກັບການຄົ້ນພົບຂອງບົດຄວາມ.

ບັນຫາເກີດຂື້ນໃນຂັ້ນຕອນຂອງການແປພາສາທີ່ຢູ່ເຄືອຂ່າຍແຫຼ່ງແລະປາຍທາງ (SNAT ແລະ DNAT) ແລະການເຂົ້າສູ່ຕາຕະລາງຕໍ່ມາ ຕິດຕາມ. ຫນຶ່ງໃນການແກ້ໄຂໄດ້ປຶກສາຫາລືພາຍໃນແລະແນະນໍາໂດຍຊຸມຊົນແມ່ນເພື່ອຍ້າຍ DNS ໄປຫາ node ພະນັກງານເອງ. ໃນ​ກໍ​ລະ​ນີ​ນີ້:

• SNAT ແມ່ນບໍ່ຈໍາເປັນເພາະວ່າການຈະລາຈອນຍັງຄົງຢູ່ໃນ node. ມັນບໍ່ຈໍາເປັນຕ້ອງຖືກນໍາໄປໂດຍຜ່ານການໂຕ້ຕອບ eth0.
• DNAT ແມ່ນບໍ່ຈໍາເປັນເພາະວ່າ IP ປາຍທາງແມ່ນທ້ອງຖິ່ນກັບ node, ແລະບໍ່ແມ່ນຝັກທີ່ເລືອກແບບສຸ່ມຕາມກົດລະບຽບ. iptables.

ພວກເຮົາຕັດສິນໃຈຍຶດຕິດກັບວິທີການນີ້. CoreDNS ຖືກໃຊ້ເປັນ DaemonSet ໃນ Kubernetes ແລະພວກເຮົາໄດ້ປະຕິບັດເຄື່ອງແມ່ຂ່າຍ DNS node ທ້ອງຖິ່ນໃນ solve.conf ແຕ່ລະຝັກໂດຍການຕັ້ງທຸງ --cluster-dns ຄຳ ສັ່ງ ກະດູກ . ການແກ້ໄຂນີ້ໄດ້ກາຍເປັນປະສິດທິພາບສໍາລັບການຫມົດເວລາ DNS.

ຢ່າງໃດກໍ່ຕາມ, ພວກເຮົາຍັງເຫັນການສູນເສຍແພັກເກັດແລະການເພີ່ມຂື້ນຂອງເຄົາເຕີ insert_failed ໃນການໂຕ້ຕອບ Flannel. ນີ້ສືບຕໍ່ຫຼັງຈາກການແກ້ໄຂໄດ້ຖືກປະຕິບັດເພາະວ່າພວກເຮົາສາມາດລົບລ້າງ SNAT ແລະ/ຫຼື DNAT ສໍາລັບການຈາລະຈອນ DNS ເທົ່ານັ້ນ. ເງື່ອນໄຂການແຂ່ງຂັນໄດ້ຖືກຮັກສາໄວ້ສໍາລັບປະເພດອື່ນໆຂອງການຈະລາຈອນ. ໂຊກດີ, ແພັກເກັດຂອງພວກເຮົາສ່ວນຫຼາຍແມ່ນ TCP, ແລະຖ້າມີບັນຫາເກີດຂຶ້ນ, ພວກມັນຈະຖືກສົ່ງຄືນພຽງແຕ່. ພວກເຮົາຍັງພະຍາຍາມຊອກຫາວິທີແກ້ໄຂທີ່ເຫມາະສົມສໍາລັບທຸກປະເພດຂອງການຈະລາຈອນ.

ການນໍາໃຊ້ Envoy ສໍາລັບການດຸ່ນດ່ຽງການໂຫຼດທີ່ດີກວ່າ

ໃນຂະນະທີ່ພວກເຮົາຍ້າຍການບໍລິການ backend ໄປ Kubernetes, ພວກເຮົາເລີ່ມທົນທຸກຈາກການໂຫຼດທີ່ບໍ່ສົມດຸນລະຫວ່າງ pods. ພວກເຮົາພົບເຫັນວ່າ HTTP Keepalive ເຮັດໃຫ້ການເຊື່ອມຕໍ່ ELB ວາງສາຍໃສ່ພອດທີ່ກຽມພ້ອມທໍາອິດຂອງແຕ່ລະການຕິດຕັ້ງ. ດັ່ງນັ້ນ, ສ່ວນໃຫຍ່ຂອງການຈະລາຈອນໄດ້ຜ່ານອັດຕາສ່ວນຂະຫນາດນ້ອຍຂອງຝັກທີ່ມີຢູ່. ການແກ້ໄຂທໍາອິດທີ່ພວກເຮົາໄດ້ທົດສອບແມ່ນກໍານົດ MaxSurge ເປັນ 100% ໃນການຕິດຕັ້ງໃຫມ່ສໍາລັບກໍລະນີທີ່ຮ້າຍແຮງທີ່ສຸດ. ຜົນກະທົບໄດ້ກາຍມາເປັນບໍ່ສໍາຄັນ ແລະບໍ່ມີທ່າອ່ຽງໃນແງ່ຂອງການນຳໃຊ້ຂະໜາດໃຫຍ່.

ການແກ້ໄຂອີກອັນຫນຶ່ງທີ່ພວກເຮົາໃຊ້ແມ່ນການເພີ່ມການຮ້ອງຂໍຊັບພະຍາກອນສໍາລັບການບໍລິການທີ່ສໍາຄັນ. ໃນ​ກໍ​ລະ​ນີ​ນີ້, ຝັກ​ທີ່​ວາງ​ໄວ້​ໃກ້​ຄຽງ​ຈະ​ມີ​ຊ່ອງ​ຫວ່າງ​ຫຼາຍ​ກວ່າ​ທີ່​ຈະ maneuver ເມື່ອ​ທຽບ​ໃສ່​ກັບ​ຝັກ​ຫນັກ​ອື່ນໆ. ມັນຈະບໍ່ເຮັດວຽກໃນໄລຍະຍາວບໍ່ວ່າຈະເປັນຍ້ອນວ່າມັນຈະເສຍຊັບພະຍາກອນ. ນອກຈາກນັ້ນ, ຄໍາຮ້ອງສະຫມັກ Node ຂອງພວກເຮົາແມ່ນ single-threaded ແລະ, ຕາມຄວາມເຫມາະສົມ, ສາມາດນໍາໃຊ້ພຽງແຕ່ຫນຶ່ງຫຼັກ. ການແກ້ໄຂທີ່ແທ້ຈິງພຽງແຕ່ແມ່ນການນໍາໃຊ້ການດຸ່ນດ່ຽງການໂຫຼດທີ່ດີກວ່າ.

ພວກ​ເຮົາ​ຢາກ​ຮູ້​ບຸນ​ຄຸນ​ຢ່າງ​ເຕັມ​ສ່ວນ ທູດພິເສດ. ສະຖານະການໃນປັດຈຸບັນອະນຸຍາດໃຫ້ພວກເຮົານໍາໃຊ້ມັນໃນວິທີການຈໍາກັດຫຼາຍແລະໄດ້ຮັບຜົນທັນທີ. Envoy ເປັນພຣັອກຊີຊັ້ນສູງ, ເປີດແຫຼ່ງ, ປະສິດທິພາບສູງທີ່ອອກແບບມາສໍາລັບແອັບພລິເຄຊັນ SOA ຂະໜາດໃຫຍ່. ມັນ​ສາ​ມາດ​ປະ​ຕິ​ບັດ​ເຕັກ​ນິກ​ການ​ດຸ່ນ​ດ່ຽງ​ການ​ໂຫຼດ​ຂັ້ນ​ສູງ​, ລວມ​ທັງ​ການ retry ອັດ​ຕະ​ໂນ​ມັດ​, breakers ວົງ​ຈອນ​, ແລະ​ການ​ຈໍາ​ກັດ​ອັດ​ຕາ​ການ​ທົ່ວ​ໂລກ​. (ຫມາຍ​ເຫດ​. ແປ.: ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນ ບົດຂຽນນີ້ ກ່ຽວກັບ Istio, ເຊິ່ງອີງໃສ່ Envoy.)

ພວກ​ເຮົາ​ໄດ້​ຮັບ​ການ​ຕັ້ງ​ຄ່າ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້: ມີ sidecar Envoy ສໍາ​ລັບ​ແຕ່​ລະ​ຝັກ​ແລະ​ເສັ້ນ​ທາງ​ດຽວ, ແລະ​ການ​ເຊື່ອມ​ຕໍ່​ກຸ່ມ​ກັບ​ພາ​ຊະ​ນະ​ໃນ​ທ້ອງ​ຖິ່ນ​ໂດຍ​ຜ່ານ​ທ່າ​ເຮືອ. ເພື່ອຫຼຸດຜ່ອນການຕົກເປັນເຫຍື່ອທີ່ອາດຈະເກີດຂຶ້ນ ແລະ ຮັກສາລັດສະໝີນ້ອຍໆ, ພວກເຮົາໄດ້ໃຊ້ເຮືອຂອງ Envoy front-proxy pods, ຫນຶ່ງຕໍ່ເຂດ Availability Zone (AZ) ສໍາລັບແຕ່ລະບໍລິການ. ພວກເຂົາເຈົ້າອີງໃສ່ເຄື່ອງຈັກການຄົ້ນພົບການບໍລິການທີ່ງ່າຍດາຍທີ່ຂຽນໂດຍວິສະວະກອນຂອງພວກເຮົາທີ່ພຽງແຕ່ສົ່ງຄືນບັນຊີລາຍຊື່ຂອງຝັກໃນແຕ່ລະ AZ ສໍາລັບການບໍລິການທີ່ໃຫ້.

ຫຼັງຈາກນັ້ນ, ທູດບໍລິການດ້ານຫນ້າໄດ້ນໍາໃຊ້ກົນໄກການຄົ້ນພົບການບໍລິການນີ້ກັບກຸ່ມຕົ້ນນ້ໍາແລະເສັ້ນທາງ. ພວກເຮົາກໍານົດເວລາຫມົດເວລາພຽງພໍ, ເພີ່ມການຕັ້ງຄ່າຕົວຕັດວົງຈອນທັງຫມົດ, ແລະເພີ່ມການຕັ້ງຄ່າການພະຍາຍາມໃຫມ່ຫນ້ອຍທີ່ສຸດເພື່ອຊ່ວຍໃຫ້ມີຄວາມຜິດພາດພຽງຄັ້ງດຽວແລະຮັບປະກັນການໃຊ້ງານທີ່ລຽບງ່າຍ. ພວກເຮົາໄດ້ວາງ TCP ELB ຢູ່ທາງຫນ້າຂອງແຕ່ລະຫນ້າການບໍລິການເຫຼົ່ານີ້. ເຖິງແມ່ນວ່າ Keepalive ຈາກຊັ້ນຕົວແທນຫຼັກຂອງພວກເຮົາຖືກຕິດຢູ່ໃນບາງ Envoy pods, ພວກເຂົາຍັງສາມາດຈັດການກັບການໂຫຼດໄດ້ດີຂຶ້ນຫຼາຍແລະຖືກຕັ້ງຄ່າໃຫ້ສົມດຸນຜ່ານຢ່າງຫນ້ອຍ_request ໃນ backend.

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

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

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

ຮູບ 3–1. CPU convergence ຂອງການບໍລິການຫນຶ່ງໃນລະຫວ່າງການປ່ຽນໄປ Envoy

ຜົນສຸດທ້າຍ

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

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

ການເຄື່ອນຍ້າຍໃຊ້ເວລາເກືອບ 2019 ປີ, ແຕ່ພວກເຮົາໄດ້ສໍາເລັດໃນເດືອນມີນາ 200. ໃນປັດຈຸບັນ, ແພລະຕະຟອມ Tinder ດໍາເນີນການສະເພາະຢູ່ໃນກຸ່ມ Kubernetes ທີ່ປະກອບດ້ວຍບໍລິການ 1000, 15 nodes, 000 ຝັກ ແລະ 48 ກ່ອງບັນຈຸ. ໂຄງສ້າງພື້ນຖານບໍ່ແມ່ນໂດເມນດຽວຂອງທີມງານປະຕິບັດງານອີກຕໍ່ໄປ. ວິສະວະກອນຂອງພວກເຮົາທັງຫມົດແບ່ງປັນຄວາມຮັບຜິດຊອບນີ້ແລະຄວບຄຸມຂະບວນການສ້າງແລະນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກຂອງພວກເຂົາໂດຍໃຊ້ລະຫັດເທົ່ານັ້ນ.

PS ຈາກນັກແປ

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

• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 1: 4200 hearth ແລະ TessMaster ຈາກ eBay".
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 2: Concur ແລະ SAP".
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 3: GitHub".
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 4: SoundCloud (ໂດຍ Prometheus)".
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 5: ທະນາຄານດິຈິຕອນ Monzo".
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 6: BlaBlaCar".
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 7: BlackRock".
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 8: Huawei".
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 9: ກຸ່ມ CERN ແລະ 210 K8s".
• «Kubernetes ເລື່ອງຄວາມສໍາເລັດໃນການຜະລິດ. ສ່ວນທີ 10: ເຫດ".

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