บันทึก. แปล: พนักงานของบริการ Tinder ที่มีชื่อเสียงระดับโลกได้แชร์รายละเอียดทางเทคนิคบางประการเกี่ยวกับการโยกย้ายโครงสร้างพื้นฐานไปยัง Kubernetes กระบวนการนี้ใช้เวลาเกือบสองปีและส่งผลให้เกิดการเปิดตัวแพลตฟอร์มขนาดใหญ่มากบน K8 ซึ่งประกอบด้วยบริการ 200 บริการที่โฮสต์บนคอนเทนเนอร์ 48 ตู้ วิศวกรของ Tinder ประสบปัญหาที่น่าสนใจอะไรบ้างและผลลัพธ์ที่ได้เป็นอย่างไร อ่านคำแปลนี้
ทำไม?
เกือบสองปีที่แล้ว Tinder ตัดสินใจย้ายแพลตฟอร์มไปยัง Kubernetes Kubernetes อนุญาตให้ทีมงาน Tinder จัดเก็บและย้ายไปสู่การใช้งานจริงโดยใช้ความพยายามเพียงเล็กน้อยผ่านการปรับใช้ที่ไม่เปลี่ยนรูปแบบ (การใช้งานที่ไม่เปลี่ยนรูป). ในกรณีนี้ แอสเซมบลีของแอปพลิเคชัน การปรับใช้ และโครงสร้างพื้นฐานจะถูกกำหนดโดยไม่ซ้ำกันด้วยโค้ด
เรายังมองหาวิธีแก้ไขปัญหาเรื่องความสามารถในการขยายขนาดและความเสถียรอีกด้วย เมื่อการปรับขนาดกลายเป็นเรื่องสำคัญ เรามักจะต้องรอหลายนาทีเพื่อให้ EC2 instance ใหม่เริ่มทำงาน แนวคิดในการเปิดตัวคอนเทนเนอร์และเริ่มให้บริการปริมาณข้อมูลในไม่กี่วินาทีแทนที่จะเป็นนาทีกลายเป็นสิ่งที่น่าสนใจสำหรับเรามาก
กระบวนการนี้กลายเป็นเรื่องยาก ในระหว่างการย้ายข้อมูลของเราในต้นปี 2019 คลัสเตอร์ Kubernetes มีจำนวนถึงจุดวิกฤติ และเราเริ่มประสบปัญหาต่างๆ เนื่องจากปริมาณการรับส่งข้อมูล ขนาดคลัสเตอร์ และ DNS ในระหว่างนี้ เราได้แก้ไขปัญหาที่น่าสนใจมากมายที่เกี่ยวข้องกับการย้ายบริการ 200 รายการและการบำรุงรักษาคลัสเตอร์ Kubernetes ที่ประกอบด้วยโหนด 1000 โหนด 15000 พ็อด และคอนเทนเนอร์ที่ทำงานอยู่ 48000 รายการ
อย่างไร
ตั้งแต่เดือนมกราคม 2018 เราได้ผ่านขั้นตอนต่างๆ ของการย้ายข้อมูล เราเริ่มต้นด้วยการบรรจุบริการทั้งหมดของเราและปรับใช้กับสภาพแวดล้อมคลาวด์ทดสอบของ Kubernetes ตั้งแต่เดือนตุลาคมเป็นต้นไป เราได้เริ่มย้ายบริการที่มีอยู่ทั้งหมดไปยัง Kubernetes อย่างเป็นระบบ ภายในเดือนมีนาคมของปีถัดไป เราได้ย้ายข้อมูลเสร็จสิ้นแล้ว และตอนนี้แพลตฟอร์ม Tinder ทำงานบน Kubernetes เท่านั้น
การสร้างอิมเมจสำหรับ Kubernetes
เรามีที่เก็บซอร์สโค้ดมากกว่า 30 แห่งสำหรับไมโครเซอร์วิสที่ทำงานบนคลัสเตอร์ Kubernetes โค้ดในที่เก็บเหล่านี้เขียนด้วยภาษาต่างๆ (เช่น Node.js, Java, Scala, Go) โดยมีสภาพแวดล้อมรันไทม์หลายรายการสำหรับภาษาเดียวกัน
ระบบการสร้างได้รับการออกแบบมาเพื่อให้ "บริบทการสร้าง" ที่ปรับแต่งได้อย่างเต็มที่สำหรับไมโครเซอร์วิสแต่ละรายการ โดยปกติจะประกอบด้วย Dockerfile และรายการคำสั่งเชลล์ เนื้อหาของพวกเขาสามารถปรับแต่งได้อย่างสมบูรณ์ และในขณะเดียวกัน บริบทบิวด์ทั้งหมดนี้เขียนตามรูปแบบมาตรฐาน การกำหนดบริบทการสร้างมาตรฐานช่วยให้ระบบบิลด์เดียวสามารถจัดการไมโครเซอร์วิสทั้งหมดได้
รูปที่ 1-1. กระบวนการสร้างที่ได้มาตรฐานผ่านคอนเทนเนอร์ของ Builder
เพื่อให้เกิดความสอดคล้องสูงสุดระหว่างรันไทม์ (สภาพแวดล้อมรันไทม์) กระบวนการสร้างเดียวกันนี้ใช้ในระหว่างการพัฒนาและการทดสอบ เราเผชิญกับความท้าทายที่น่าสนใจมาก: เราต้องพัฒนาวิธีการเพื่อให้แน่ใจว่าสภาพแวดล้อมในการสร้างทั่วทั้งแพลตฟอร์มมีความสอดคล้องกัน เพื่อให้บรรลุเป้าหมายนี้ กระบวนการประกอบทั้งหมดจะดำเนินการภายในภาชนะพิเศษ ผู้ก่อสร้าง.
การใช้งานคอนเทนเนอร์ของเขาต้องใช้เทคนิคนักเทียบท่าขั้นสูง Builder สืบทอด ID ผู้ใช้ภายในและความลับ (เช่น คีย์ SSH, ข้อมูลรับรอง AWS ฯลฯ) ที่จำเป็นในการเข้าถึงพื้นที่เก็บข้อมูล Tinder ส่วนตัว ติดตั้งไดเร็กทอรีในเครื่องที่มีแหล่งที่มาเพื่อจัดเก็บสิ่งประดิษฐ์ตามธรรมชาติ แนวทางนี้ช่วยปรับปรุงประสิทธิภาพ เนื่องจากไม่จำเป็นต้องคัดลอกส่วนการสร้างระหว่างคอนเทนเนอร์ Builder และโฮสต์ อาร์ติแฟกต์บิลด์ที่เก็บไว้สามารถนำมาใช้ซ้ำได้โดยไม่ต้องมีการกำหนดค่าเพิ่มเติม
สำหรับบริการบางอย่าง เราต้องสร้างคอนเทนเนอร์อื่นเพื่อแมปสภาพแวดล้อมการคอมไพล์กับสภาพแวดล้อมรันไทม์ (เช่น ไลบรารี bcrypt ของ Node.js จะสร้างไบนารี่เฉพาะแพลตฟอร์มระหว่างการติดตั้ง) ในระหว่างกระบวนการคอมไพล์ ข้อกำหนดอาจแตกต่างกันระหว่างบริการ และ Dockerfile สุดท้ายจะถูกคอมไพล์ทันที
สถาปัตยกรรมคลัสเตอร์ Kubernetes และการย้ายข้อมูล
การจัดการขนาดคลัสเตอร์
เราตัดสินใจใช้ kube-aws สำหรับการปรับใช้คลัสเตอร์อัตโนมัติบนอินสแตนซ์ Amazon EC2 ในช่วงเริ่มต้น ทุกอย่างทำงานได้ในกลุ่มโหนดทั่วไปกลุ่มเดียว เราตระหนักได้อย่างรวดเร็วถึงความจำเป็นในการแยกปริมาณงานตามขนาดและประเภทอินสแตนซ์เพื่อให้การใช้ทรัพยากรมีประสิทธิภาพมากขึ้น ตรรกะก็คือการเรียกใช้พ็อดแบบมัลติเธรดที่โหลดหลายตัวนั้นสามารถคาดเดาได้ง่ายกว่าในแง่ของประสิทธิภาพมากกว่าการอยู่ร่วมกันกับพ็อดแบบเธรดเดี่ยวจำนวนมาก
ในที่สุดเราก็ตกลงกันได้ที่:
- m5.4xlarge — สำหรับการตรวจสอบ (โพร)
- c5.4xlarge - สำหรับปริมาณงาน Node.js (ปริมาณงานแบบเธรดเดียว)
- c5.2xlarge - สำหรับ Java และ Go (ปริมาณงานแบบมัลติเธรด)
- c5.4xlarge — สำหรับแผงควบคุม (3 โหนด)
การย้ายถิ่น
ขั้นตอนการเตรียมการอย่างหนึ่งสำหรับการย้ายจากโครงสร้างพื้นฐานเก่าไปยัง Kubernetes คือการเปลี่ยนเส้นทางการสื่อสารโดยตรงที่มีอยู่ระหว่างบริการไปยังโหลดบาลานเซอร์ใหม่ (Elastic Load Balancers (ELB)) สร้างขึ้นบนซับเน็ตเฉพาะของคลาวด์ส่วนตัวเสมือน (VPC) ซับเน็ตนี้เชื่อมต่อกับ Kubernetes VPC สิ่งนี้ทำให้เราสามารถโยกย้ายโมดูลต่างๆ ได้อย่างค่อยเป็นค่อยไป โดยไม่คำนึงถึงลำดับการพึ่งพาบริการที่เฉพาะเจาะจง
ตำแหน่งข้อมูลเหล่านี้สร้างขึ้นโดยใช้ชุดระเบียน DNS แบบถ่วงน้ำหนักซึ่งมี CNAME ชี้ไปที่ ELB ใหม่แต่ละรายการ ในการสลับเปลี่ยน เราได้เพิ่มรายการใหม่ที่ชี้ไปที่ ELB ใหม่ของบริการ Kubernetes ที่มีน้ำหนัก 0 จากนั้นเราตั้งค่า Time To Live (TTL) ของรายการที่ตั้งไว้ที่ 0 หลังจากนี้ น้ำหนักเก่าและใหม่จะถูก ปรับอย่างช้าๆ และในที่สุดโหลด 100% ก็ถูกส่งไปยังเซิร์ฟเวอร์ใหม่ หลังจากการสลับเสร็จสมบูรณ์ ค่า TTL จะกลับสู่ระดับที่เพียงพอมากขึ้น
โมดูล Java ที่เรามีสามารถรับมือกับ TTL DNS ต่ำได้ แต่แอปพลิเคชัน Node ไม่สามารถทำได้ วิศวกรคนหนึ่งเขียนส่วนหนึ่งของรหัสพูลการเชื่อมต่อใหม่และรวมไว้ในตัวจัดการที่อัปเดตพูลทุก ๆ 60 วินาที แนวทางที่เลือกใช้ได้ผลดีมากและไม่มีการลดประสิทธิภาพลงอย่างเห็นได้ชัด
บทเรียน
ขีดจำกัดของโครงสร้างเครือข่าย
ในช่วงเช้าของวันที่ 8 มกราคม 2019 แพลตฟอร์ม Tinder ขัดข้องโดยไม่คาดคิด เพื่อตอบสนองต่อเวลาแฝงของแพลตฟอร์มที่เพิ่มขึ้นอย่างไม่เกี่ยวข้องเมื่อเช้าวันนั้น จำนวนพ็อดและโหนดในคลัสเตอร์จึงเพิ่มขึ้น สิ่งนี้ทำให้แคช ARP หมดไปบนโหนดทั้งหมดของเรา
มีตัวเลือก Linux สามตัวเลือกที่เกี่ยวข้องกับแคช ARP:
()
gc_thresh3 - นี่เป็นขีดจำกัดที่ยาก การปรากฏตัวของรายการ "neighbor table overflow" ในบันทึกหมายความว่าแม้หลังจากการรวบรวมขยะแบบซิงโครนัส (GC) แล้ว ก็ยังมีเนื้อที่ไม่เพียงพอในแคช ARP เพื่อจัดเก็บรายการใกล้เคียง ในกรณีนี้เคอร์เนลจะทิ้งแพ็กเก็ตไปโดยสิ้นเชิง
เราใช้ เป็นแฟบริคเครือข่ายใน Kubernetes แพ็กเก็ตจะถูกส่งผ่าน VXLAN VXLAN เป็นอุโมงค์ L2 ที่ถูกยกขึ้นบนเครือข่าย L3 เทคโนโลยีนี้ใช้การห่อหุ้ม MAC-in-UDP (MAC Address-in-User Datagram Protocol) และช่วยให้สามารถขยายส่วนเครือข่ายเลเยอร์ 2 ได้ โปรโตคอลการขนส่งบนเครือข่ายศูนย์ข้อมูลทางกายภาพคือ IP บวก UDP
รูปที่ 2–1. แผนภาพผ้าสักหลาด ()
รูปที่ 2–2 แพ็คเกจ VXLAN ()
โหนดผู้ปฏิบัติงาน Kubernetes แต่ละโหนดจะจัดสรรพื้นที่ที่อยู่เสมือนด้วยมาสก์ /24 จากบล็อก /9 ที่ใหญ่กว่า สำหรับแต่ละโหนดนี่คือ หนึ่งรายการในตารางเส้นทาง หนึ่งรายการในตาราง ARP (บนอินเทอร์เฟซ flannel.1) และหนึ่งรายการในตารางการสลับ (FDB) จะถูกเพิ่มในครั้งแรกที่โหนดผู้ปฏิบัติงานเริ่มต้นหรือทุกครั้งที่ค้นพบโหนดใหม่
นอกจากนี้การสื่อสารแบบ node-pod (หรือ pod-pod) จะต้องผ่านอินเทอร์เฟซในที่สุด eth0 (ดังแสดงในแผนภาพผ้าสักหลาดด้านบน) ซึ่งส่งผลให้มีรายการเพิ่มเติมในตาราง ARP สำหรับโฮสต์ต้นทางและปลายทางที่เกี่ยวข้องกัน
ในสภาพแวดล้อมของเรา การสื่อสารประเภทนี้เป็นเรื่องปกติมาก สำหรับออบเจ็กต์บริการใน Kubernetes จะมีการสร้าง ELB และ Kubernetes จะลงทะเบียนแต่ละโหนดด้วย ELB ELB ไม่รู้อะไรเลยเกี่ยวกับพ็อดและโหนดที่เลือกอาจไม่ใช่ปลายทางสุดท้ายของแพ็กเก็ต ประเด็นก็คือเมื่อโหนดได้รับแพ็กเก็ตจาก ELB จะถือว่าโหนดนั้นคำนึงถึงกฎเกณฑ์ด้วย iptables สำหรับบริการเฉพาะและสุ่มเลือกพ็อดบนโหนดอื่น
ในขณะที่เกิดความล้มเหลว มี 605 โหนดในคลัสเตอร์ ด้วยเหตุผลดังที่กล่าวมาข้างต้น ก็เพียงพอแล้วที่จะเอาชนะความสำคัญได้ gc_thresh3ซึ่งเป็นค่าเริ่มต้น เมื่อสิ่งนี้เกิดขึ้น ไม่เพียงแต่แพ็กเก็ตจะเริ่มถูกทิ้ง แต่พื้นที่ที่อยู่เสมือน Flannel ทั้งหมดที่มีมาสก์ /24 จะหายไปจากตาราง ARP การสื่อสารแบบ Node-pod และการสืบค้น DNS ถูกขัดจังหวะ (โฮสต์ DNS ในคลัสเตอร์ อ่านรายละเอียดภายหลังในบทความนี้)
เพื่อแก้ไขปัญหานี้ คุณต้องเพิ่มค่า gc_thresh1, gc_thresh2 и gc_thresh3 และรีสตาร์ท Flannel เพื่อลงทะเบียนเครือข่ายที่ขาดหายไปอีกครั้ง
การปรับขนาด DNS ที่ไม่คาดคิด
ในระหว่างกระบวนการย้าย เราใช้ DNS อย่างจริงจังเพื่อจัดการการรับส่งข้อมูลและค่อยๆ ถ่ายโอนบริการจากโครงสร้างพื้นฐานเก่าไปยัง Kubernetes เราตั้งค่า TTL ค่อนข้างต่ำสำหรับชุดระเบียนที่เกี่ยวข้องใน Route53 เมื่อโครงสร้างพื้นฐานเก่าทำงานบนอินสแตนซ์ EC2 การกำหนดค่าตัวแก้ไขของเราชี้ไปที่ Amazon DNS เราคำนึงถึงเรื่องนี้เป็นหลัก และผลกระทบของ TTL ที่ต่ำต่อบริการของเราและบริการของ Amazon (เช่น DynamoDB) ก็ไม่มีใครสังเกตเห็นมากนัก
ขณะที่เราย้ายบริการไปยัง Kubernetes เราพบว่า DNS กำลังประมวลผลคำขอ 250 รายการต่อวินาที เป็นผลให้แอปพลิเคชันเริ่มประสบปัญหาการหมดเวลาอย่างต่อเนื่องและร้ายแรงสำหรับการสืบค้น DNS สิ่งนี้เกิดขึ้นแม้จะมีความพยายามอย่างไม่น่าเชื่อในการเพิ่มประสิทธิภาพและเปลี่ยนผู้ให้บริการ DNS เป็น CoreDNS (ซึ่งเมื่อโหลดสูงสุดถึง 1000 พ็อดที่ทำงานบน 120 คอร์)
ขณะค้นคว้าสาเหตุและแนวทางแก้ไขอื่นๆ ที่เป็นไปได้ เราก็ค้นพบ อธิบายสภาพการแข่งขันที่ส่งผลต่อกรอบการกรองแพ็กเก็ต netfilter ในลินุกซ์ การหมดเวลาที่เราสังเกตควบคู่ไปกับการนับที่เพิ่มขึ้น insert_failed ในส่วนต่อประสานผ้าสักหลาดนั้นสอดคล้องกับข้อค้นพบของบทความ
ปัญหาเกิดขึ้นในขั้นตอนของการแปลที่อยู่เครือข่ายต้นทางและปลายทาง (SNAT และ DNAT) และรายการต่อมาในตาราง คอนแทรค. วิธีแก้ไขปัญหาชั่วคราวประการหนึ่งที่พูดคุยกันเป็นการภายในและแนะนำโดยชุมชนคือการย้าย DNS ไปยังโหนดของผู้ปฏิบัติงานเอง ในกรณีนี้:
- ไม่จำเป็นต้องใช้ SNAT เนื่องจากการรับส่งข้อมูลจะอยู่ภายในโหนด ไม่จำเป็นต้องกำหนดเส้นทางผ่านอินเทอร์เฟซ eth0.
- ไม่จำเป็นต้องใช้ DNAT เนื่องจาก IP ปลายทางอยู่ภายในโหนด และไม่ใช่พ็อดที่เลือกแบบสุ่มตามกฎ iptables.
เราตัดสินใจที่จะยึดติดกับแนวทางนี้ CoreDNS ได้รับการปรับใช้เป็น DaemonSet ใน Kubernetes และเราได้ติดตั้งเซิร์ฟเวอร์ DNS โหนดในเครื่อง แก้ไข.conf แต่ละฝักโดยการตั้งธง --cluster-dns คำสั่ง คูเบเลต . โซลูชันนี้ปรากฏว่ามีประสิทธิภาพสำหรับการหมดเวลา DNS
อย่างไรก็ตาม เรายังคงเห็นการสูญหายของแพ็กเก็ตและการเพิ่มขึ้นในตัวนับ insert_failed ในอินเทอร์เฟซผ้าสักหลาด สิ่งนี้ดำเนินต่อไปหลังจากดำเนินการแก้ไขปัญหาชั่วคราว เนื่องจากเราสามารถกำจัด SNAT และ/หรือ DNAT สำหรับการรับส่งข้อมูล DNS เท่านั้น สภาพการแข่งขันได้รับการเก็บรักษาไว้สำหรับการจราจรประเภทอื่น โชคดีที่แพ็กเก็ตส่วนใหญ่ของเราเป็น TCP และหากเกิดปัญหาก็จะถูกส่งอีกครั้ง เรายังคงพยายามค้นหาโซลูชันที่เหมาะสมสำหรับการรับส่งข้อมูลทุกประเภท
การใช้ Envoy เพื่อการปรับสมดุลโหลดที่ดีขึ้น
ขณะที่เราย้ายบริการแบ็กเอนด์ไปยัง Kubernetes เราเริ่มประสบปัญหาโหลดที่ไม่สมดุลระหว่างพ็อด เราพบว่า HTTP Keepalive ทำให้การเชื่อมต่อ ELB หยุดทำงานบนพ็อดที่พร้อมใช้งานชุดแรกของการปรับใช้งานแต่ละครั้ง ดังนั้นการรับส่งข้อมูลจำนวนมากจึงผ่านพ็อดที่มีอยู่เพียงไม่กี่เปอร์เซ็นต์ โซลูชันแรกที่เราทดสอบคือการตั้งค่า MaxSurge เป็น 100% ในการใช้งานใหม่สำหรับสถานการณ์กรณีที่เลวร้ายที่สุด ผลลัพธ์ที่ได้กลับไม่มีนัยสำคัญและไม่มีท่าว่าจะดีในแง่ของการปรับใช้ขนาดใหญ่
โซลูชันอื่นที่เราใช้คือการเพิ่มคำขอทรัพยากรสำหรับบริการที่สำคัญโดยไม่ตั้งใจ ในกรณีนี้ พ็อดที่วางอยู่ใกล้ๆ จะมีพื้นที่ในการเคลื่อนย้ายมากกว่าเมื่อเทียบกับพ็อดที่หนักอื่นๆ มันจะไม่ทำงานในระยะยาวเช่นกันเพราะจะทำให้สิ้นเปลืองทรัพยากร นอกจากนี้ แอปพลิเคชัน Node ของเราเป็นแบบเธรดเดียว ดังนั้นจึงสามารถใช้ได้เพียงคอร์เดียวเท่านั้น วิธีแก้ปัญหาที่แท้จริงเพียงอย่างเดียวคือใช้การปรับสมดุลโหลดให้ดีขึ้น
เราอยากจะชื่นชมอย่างเต็มที่มานานแล้ว . สถานการณ์ปัจจุบันทำให้เราสามารถปรับใช้ในลักษณะที่จำกัดมากและได้ผลลัพธ์ทันที Envoy เป็นพร็อกซีเลเยอร์ XNUMX แบบโอเพ่นซอร์สประสิทธิภาพสูง ออกแบบมาสำหรับแอปพลิเคชัน SOA ขนาดใหญ่ สามารถใช้เทคนิคการปรับสมดุลโหลดขั้นสูง รวมถึงการลองใหม่อัตโนมัติ เซอร์กิตเบรกเกอร์ และการจำกัดอัตราทั่วโลก (บันทึก. แปล: คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ใน เกี่ยวกับ Istio ซึ่งมีพื้นฐานมาจาก Envoy)
เราได้การกำหนดค่าดังต่อไปนี้: มีรถเทียมข้างรถจักรยานยนต์ Envoy สำหรับแต่ละพ็อดและเส้นทางเดียว และเชื่อมต่อคลัสเตอร์กับคอนเทนเนอร์ภายในเครื่องผ่านทางพอร์ต เพื่อลดปัญหาการเรียงซ้อนที่อาจเกิดขึ้นและรักษารัศมีการโจมตีให้น้อยที่สุด เราใช้ฟลีตพ็อดพร็อกซีด้านหน้าของ Envoy หนึ่งตัวต่อ Availability Zone (AZ) สำหรับแต่ละบริการ พวกเขาอาศัยกลไกการค้นหาบริการแบบง่ายๆ ที่เขียนโดยวิศวกรคนหนึ่งของเรา ซึ่งเพียงส่งคืนรายการพ็อดในแต่ละ AZ สำหรับบริการที่กำหนด
จากนั้น Front-Envoy ฝ่ายบริการก็ใช้กลไกการค้นหาบริการนี้กับคลัสเตอร์ต้นน้ำและเส้นทางเดียว เราตั้งค่าการหมดเวลาที่เหมาะสม เพิ่มการตั้งค่าเซอร์กิตเบรกเกอร์ทั้งหมด และเพิ่มการกำหนดค่าการลองใหม่ขั้นต่ำเพื่อช่วยในกรณีที่เกิดความล้มเหลวเพียงครั้งเดียวและรับประกันการใช้งานที่ราบรื่น เราวาง TCP ELB ไว้ที่ด้านหน้าของ Front-Envoy ของบริการเหล่านี้ แม้ว่า Keepalive จากเลเยอร์พร็อกซีหลักของเราจะติดอยู่ในพ็อด Envoy บางตัว แต่ก็ยังสามารถจัดการโหลดได้ดีขึ้นมาก และได้รับการกำหนดค่าให้สมดุลผ่านคำขอน้อยที่สุดในแบ็กเอนด์
สำหรับการปรับใช้ เราใช้ตะขอ preStop บนทั้งพ็อดแอปพลิเคชันและพ็อดไซด์คาร์ ฮุคทำให้เกิดข้อผิดพลาดในการตรวจสอบสถานะของตำแหน่งข้อมูลผู้ดูแลระบบที่อยู่บนคอนเทนเนอร์ไซด์คาร์ และเข้าสู่โหมดสลีปชั่วขณะหนึ่งเพื่อให้การเชื่อมต่อที่ใช้งานอยู่ยุติลง
สาเหตุหนึ่งที่เราดำเนินการได้รวดเร็วมากก็เนื่องมาจากตัววัดโดยละเอียดที่เราสามารถรวมเข้ากับการติดตั้ง Prometheus ทั่วไปได้อย่างง่ายดาย สิ่งนี้ช่วยให้เราเห็นได้อย่างชัดเจนว่าเกิดอะไรขึ้นในขณะที่เราปรับพารามิเตอร์การกำหนดค่าและกระจายการรับส่งข้อมูลอีกครั้ง
ผลลัพธ์ก็ทันทีและชัดเจน เราเริ่มต้นด้วยบริการที่ไม่สมดุลที่สุด และในขณะนี้ก็ดำเนินการต่อหน้าบริการที่สำคัญที่สุด 12 รายการในคลัสเตอร์ ในปีนี้ เรากำลังวางแผนการเปลี่ยนไปใช้บริการแบบเต็มรูปแบบพร้อมการค้นพบบริการขั้นสูง การทำลายวงจร การตรวจจับค่าผิดปกติ การจำกัดอัตรา และการติดตาม
รูปที่ 3–1. การบรรจบกันของ CPU ของบริการเดียวระหว่างการเปลี่ยนไปใช้ Envoy
ผลลัพธ์สุดท้าย
ด้วยประสบการณ์และการวิจัยเพิ่มเติมนี้ เราได้สร้างทีมโครงสร้างพื้นฐานที่แข็งแกร่งพร้อมทักษะที่แข็งแกร่งในการออกแบบ ปรับใช้ และปฏิบัติการคลัสเตอร์ Kubernetes ขนาดใหญ่ ตอนนี้วิศวกร Tinder ทุกคนมีความรู้และประสบการณ์ในการทำแพ็กเกจคอนเทนเนอร์และปรับใช้แอปพลิเคชันกับ Kubernetes
เมื่อความต้องการความจุเพิ่มเติมเกิดขึ้นบนโครงสร้างพื้นฐานเก่า เราต้องรอหลายนาทีก่อนที่อินสแตนซ์ EC2 ใหม่จะเปิดตัว ขณะนี้คอนเทนเนอร์เริ่มทำงานและเริ่มประมวลผลการรับส่งข้อมูลภายในไม่กี่วินาทีแทนที่จะเป็นนาที การจัดกำหนดการคอนเทนเนอร์หลายรายการบนอินสแตนซ์ EC2 เดียวยังช่วยเพิ่มความเข้มข้นในแนวนอนอีกด้วย ด้วยเหตุนี้ เราจึงคาดการณ์ว่าต้นทุน EC2019 จะลดลงอย่างมากในปี 2 เมื่อเทียบกับปีที่แล้ว
การย้ายข้อมูลใช้เวลาเกือบสองปี แต่เราดำเนินการเสร็จสิ้นในเดือนมีนาคม 2019 ปัจจุบัน แพลตฟอร์ม Tinder ทำงานเฉพาะบนคลัสเตอร์ Kubernetes ซึ่งประกอบด้วยบริการ 200 รายการ โหนด 1000 รายการ พ็อด 15 รายการ และคอนเทนเนอร์ที่ทำงานอยู่ 000 รายการ โครงสร้างพื้นฐานไม่ใช่โดเมนเดียวของทีมปฏิบัติการอีกต่อไป วิศวกรของเราทุกคนแบ่งปันความรับผิดชอบนี้และควบคุมกระบวนการสร้างและปรับใช้แอปพลิเคชันของตนโดยใช้โค้ดเท่านั้น
ปล.จากผู้แปล
อ่านบทความในบล็อกของเราด้วย:
- «'
- «'
- «'
- «'
- «'
- «'
- «'
- «'
- «'
- «'
ที่มา: will.com