เชื้อจุดไฟย้ายไป Kubernetes

เขียนโดย: Chris O'Brien, ผู้จัดการฝ่ายวิศวกรรม | Chris Thomas, ผู้จัดการฝ่ายวิศวกรรม | Jinyong Lee วิศวกรซอฟต์แวร์อาวุโส แก้ไขโดย: Cooper Jackson, วิศวกรซอฟต์แวร์

ทำไม

เกือบสองปีที่แล้ว Tinder ตัดสินใจย้ายแพลตฟอร์มไปที่ Kubernetes Kubernetes ให้โอกาสแก่เราในการผลักดัน Tinder Engineering ไปสู่การบรรจุหีบห่อและการทำงานแบบสัมผัสต่ำผ่านการปรับใช้ที่ไม่เปลี่ยนรูป การสร้างแอปพลิเคชันการปรับใช้และโครงสร้างพื้นฐานจะถูกกำหนดเป็นรหัส

เรากำลังมองหาที่จะรับมือกับความท้าทายของขนาดและความมั่นคง เมื่อการไต่สวนมีความสำคัญเรามักจะต้องทนทุกข์ทรมานเมื่อผ่านไปหลายนาทีเพื่อรอให้อินสแตนซ์ EC2 ใหม่ออนไลน์ แนวคิดของการกำหนดเวลาของตู้คอนเทนเนอร์และการรับส่งข้อมูลการจราจรภายในไม่กี่วินาทีซึ่งแตกต่างจากนาทีที่เราสนใจ

มันไม่ง่ายเลย ในระหว่างการโยกย้ายของเราในต้นปี 2562 เราได้ไปถึงมวลวิกฤตภายในคลัสเตอร์ Kubernetes ของเราและเริ่มเผชิญกับความท้าทายต่างๆเนื่องจากปริมาณการจราจรขนาดของคลัสเตอร์และ DNS เราแก้ไขความท้าทายที่น่าสนใจในการโยกย้าย 200 บริการและเรียกใช้คลัสเตอร์ Kubernetes ในระดับรวม 1,000 โหนด 15,000 ฝักและ 48,000 ตู้คอนเทนเนอร์ที่ใช้งาน

อย่างไร

เริ่มตั้งแต่เดือนมกราคม 2561 เราทำงานผ่านขั้นตอนต่าง ๆ ของการย้ายถิ่น เราเริ่มจากการบรรจุบริการทั้งหมดของเราและปรับใช้กับชุดของ Kubernetes ที่โฮสต์สภาพแวดล้อมการจัดเตรียม ต้นเดือนตุลาคมเราเริ่มให้บริการแบบดั้งเดิมทั้งหมดของเราไปยัง Kubernetes อย่างเป็นระบบ ภายในเดือนมีนาคมของปีถัดไปเราได้สรุปการโยกย้ายของเราและแพลตฟอร์ม Tinder ตอนนี้ทำงานเฉพาะใน Kubernetes

สร้างภาพสำหรับ Kubernetes

มีที่เก็บซอร์สโค้ดมากกว่า 30 รายการสำหรับไมโครไซต์ที่ทำงานในคลัสเตอร์ Kubernetes รหัสในที่เก็บเหล่านี้เขียนขึ้นในภาษาต่าง ๆ (เช่น Node.js, Java, Scala, Go) ที่มีสภาพแวดล้อมรันไทม์จำนวนมากสำหรับภาษาเดียวกัน

ระบบบิลด์ได้รับการออกแบบให้ทำงานบน“ บริบทการสร้าง” ที่ปรับแต่งได้อย่างสมบูรณ์สำหรับแต่ละไมโครไซต์ซึ่งโดยทั่วไปจะประกอบด้วย Dockerfile และชุดคำสั่งเชลล์ ในขณะที่เนื้อหาของพวกเขาจะปรับแต่งอย่างเต็มที่บริบทสร้างเหล่านี้ทั้งหมดเขียนโดยทำตามรูปแบบมาตรฐาน มาตรฐานของบริบทการสร้างช่วยให้ระบบการสร้างเดียวในการจัดการ microservices ทั้งหมด

รูปที่ 1–1 กระบวนการสร้างที่ได้มาตรฐานผ่านตัวสร้างคอนเทนเนอร์

เพื่อให้บรรลุความสอดคล้องสูงสุดระหว่างสภาพแวดล้อมรันไทม์กระบวนการสร้างเดียวกันจะถูกใช้ในระหว่างการพัฒนาและขั้นตอนการทดสอบ สิ่งนี้เป็นการท้าทายที่ไม่เหมือนใครเมื่อเราต้องการกำหนดวิธีการรับประกันสภาพแวดล้อมการสร้างที่สอดคล้องกันทั่วทั้งแพลตฟอร์ม ดังนั้นกระบวนการบิลด์ทั้งหมดจะดำเนินการภายในคอนเทนเนอร์“ บิลเดอร์” พิเศษ

การใช้งานตัวสร้างคอนเทนเนอร์ต้องการเทคนิคขั้นสูงของนักเทียบท่า คอนเทนเนอร์ Builder นี้สืบทอด ID ผู้ใช้และความลับโลคัล (เช่นคีย์ SSH, หนังสือรับรอง AWS, ฯลฯ ) ตามที่จำเป็นในการเข้าถึงที่เก็บส่วนตัวของ Tinder มัน mounts ไดเรกทอรีท้องถิ่นที่มีรหัสแหล่งที่มาจะมีวิธีธรรมชาติในการจัดเก็บการสร้างสิ่งประดิษฐ์ วิธีนี้ช่วยเพิ่มประสิทธิภาพเนื่องจากจะกำจัดการคัดลอกสิ่งประดิษฐ์ที่สร้างขึ้นระหว่างตัวสร้างคอนเทนเนอร์และเครื่องโฮสต์ บิวด์บิลด์ที่เก็บไว้จะถูกนำมาใช้ซ้ำในครั้งต่อไปโดยไม่มีการกำหนดค่าเพิ่มเติม

สำหรับบริการบางอย่างเราจำเป็นต้องสร้างคอนเทนเนอร์อื่นภายในตัวสร้างเพื่อให้ตรงกับสภาพแวดล้อมเวลาคอมไพล์กับสภาพแวดล้อมแบบรันไทม์ (เช่นการติดตั้งไลบรารี bode ของ Node.js สร้างโหนดไบนารีเฉพาะแพลตฟอร์ม) ความต้องการเวลาคอมไพล์อาจแตกต่างกันระหว่างการให้บริการและไฟล์ Dockerfile สุดท้ายนั้นประกอบไปด้วย

สถาปัตยกรรมกลุ่ม Kubernetes และการย้ายถิ่น

การปรับขนาดคลัสเตอร์

เราตัดสินใจใช้ kube-aws สำหรับการจัดสรรคลัสเตอร์อัตโนมัติในอินสแตนซ์ Amazon EC2 ก่อนหน้านี้เรารันทุกอย่างในพูลโหนดทั่วไป เราระบุความต้องการอย่างรวดเร็วเพื่อแยกปริมาณงานออกเป็นขนาดและประเภทของอินสแตนซ์ที่แตกต่างกันเพื่อใช้ประโยชน์จากทรัพยากรได้ดีขึ้น เหตุผลก็คือการใช้พ็อดเธรดที่มีเกลียวมากน้อยกว่าเข้าด้วยกันทำให้ได้ผลการดำเนินงานที่คาดการณ์ได้มากขึ้นสำหรับเรามากกว่าการปล่อยให้พวกมันอยู่ร่วมกันกับพ็อดเธรดเดี่ยวจำนวนมากขึ้น

เราตัดสินเมื่อ:

  • m5.4x ใหญ่สำหรับการตรวจสอบ (โพร)
  • c5.4x ใหญ่สำหรับ Node.js ปริมาณงาน (เวิร์กโหลดแบบเธรดเดียว)
  • c5.2x ใหญ่สำหรับ Java และ Go (ปริมาณงานแบบมัลติเธรด)
  • c5.4x ใหญ่สำหรับระนาบการควบคุม (3 โหนด)

การโยกย้าย

หนึ่งในขั้นตอนการเตรียมการสำหรับการโยกย้ายจากโครงสร้างพื้นฐานดั้งเดิมของเราไปยัง Kubernetes คือการเปลี่ยนการสื่อสารระหว่างบริการกับบริการที่มีอยู่ให้ชี้ไปที่ Elastic Load Balancer ใหม่ (ELBs) ที่สร้างขึ้นในเครือข่ายย่อย Virtual Private Cloud (VPC) เฉพาะ ซับเน็ตนี้ถูกส่งไปที่ Kubernetes VPC สิ่งนี้ทำให้เราสามารถย้ายโมดูลอย่างละเอียดโดยไม่คำนึงถึงการสั่งซื้อเฉพาะสำหรับการพึ่งพาบริการ

ปลายทางเหล่านี้ถูกสร้างขึ้นโดยใช้ชุดระเบียน DNS แบบถ่วงน้ำหนักซึ่งมี CNAME ที่ชี้ไปยังแต่ละ ELB ใหม่ เมื่อต้องการตัดเราเพิ่มบันทึกใหม่ชี้ไปที่บริการ Kubernetes ใหม่ ELB ด้วยน้ำหนัก 0 จากนั้นเราตั้งค่า Time To Live (TTL) ในชุดระเบียนเป็น 0 น้ำหนักเก่าและใหม่ถูกปรับเป็นช้า ในที่สุดก็จบลงด้วย 100% บนเซิร์ฟเวอร์ใหม่ หลังจากที่ cutover เสร็จสมบูรณ์ TTL ก็ถูกตั้งค่าเป็นสิ่งที่เหมาะสมกว่า

โมดูล Java ของเราใช้ DNS TTL ต่ำ แต่แอปพลิเคชันโหนดของเราไม่ได้ หนึ่งในวิศวกรของเราเขียนรหัสสระว่ายน้ำเชื่อมต่อเพื่อห่อไว้ในผู้จัดการที่จะรีเฟรชพูลทุก 60 วินาที สิ่งนี้ทำงานได้ดีมากสำหรับเราโดยไม่มีการตีที่ยอดเยี่ยม

การเรียนรู้

ขีด จำกัด Fabric Network

ในช่วงเช้าตรู่ของวันที่ 8 มกราคม 2019 แพลตฟอร์มของ Tinder ได้รับความเสียหายอย่างต่อเนื่อง เพื่อตอบสนองต่อการเพิ่มขึ้นของแพลตฟอร์ม latency ที่ไม่เกี่ยวข้องก่อนหน้านี้ในเช้าวันนั้นจำนวนฝักและโหนดจะถูกลดขนาดลงในคลัสเตอร์ สิ่งนี้ส่งผลให้เกิดการหมดแคช ARP บนโหนดทั้งหมดของเรา

มีค่า Linux สามค่าที่เกี่ยวข้องกับแคช ARP:

เครดิต

gc_thresh3 เป็นหมวกแข็ง หากคุณได้รับรายการบันทึก“ เพื่อนบ้านตารางล้น” นี้บ่งชี้ว่าแม้หลังจากที่เก็บขยะซิงโครนัส (GC) ของแคช ARP มีพื้นที่ไม่เพียงพอที่จะเก็บรายการเพื่อนบ้าน ในกรณีนี้เคอร์เนลเพียงแค่หยดแพ็คเก็ตทั้งหมด

เราใช้ Flannel เป็นโครงสร้างเครือข่ายของเราใน Kubernetes แพ็คเก็ตจะถูกส่งต่อผ่าน VXLAN VXLAN เป็นโครงร่างการซ้อนทับของเลเยอร์ 2 บนเครือข่ายเลเยอร์ 3 มันใช้การห่อหุ้ม MAC Address-in-User Datagram Protocol (MAC-in-UDP) เพื่อให้วิธีการในการขยายส่วนเครือข่ายเลเยอร์ 2 โปรโตคอลการขนส่งผ่านเครือข่ายศูนย์ข้อมูลทางกายภาพคือ IP บวก UDP

รูปที่ 2-1 แผนภาพผ้าสักหลาด (เครดิต)

รูปที่ 2–2 VXLAN แพ็คเก็ต (เครดิต)

แต่ละโหนดผู้ปฏิบัติงานของ Kubernetes จะจัดสรรพื้นที่ที่อยู่เสมือนของตนเอง / 24 จากพื้นที่บล็อกขนาดใหญ่ / 9 สำหรับแต่ละโหนดสิ่งนี้จะส่งผลให้ 1 รายการตารางเส้นทาง 1 รายการตาราง ARP (บนอินเตอร์เฟส flannel.1) และ 1 รายการฐานข้อมูลการส่งต่อ (FDB) สิ่งเหล่านี้จะถูกเพิ่มเมื่อโหนดผู้ปฏิบัติงานเปิดตัวครั้งแรกหรือเป็นแต่ละโหนดใหม่จะถูกค้นพบ

นอกจากนี้การสื่อสารแบบ node-to-pod (หรือ pod-to-pod) จะไหลผ่านอินเตอร์เฟซ eth0 (ในแผนภาพ Flannel ด้านบน) สิ่งนี้จะส่งผลให้เกิดรายการเพิ่มเติมในตาราง ARP สำหรับแต่ละโหนดต้นทางและปลายทางปลายทาง

ในสภาพแวดล้อมของเราการสื่อสารประเภทนี้เป็นเรื่องธรรมดามาก สำหรับอ็อบเจ็กต์บริการ Kubernetes ของเราจะสร้าง ELB และ Kubernetes จะลงทะเบียนทุกโหนดด้วย ELB ELB ไม่รู้จักพอดและโหนดที่เลือกอาจไม่ใช่ปลายทางสุดท้ายของแพ็กเก็ต นี่เป็นเพราะเมื่อโหนดได้รับแพ็กเก็ตจาก ELB มันจะประเมินกฎ iptables สำหรับบริการและสุ่มเลือกฝักบนโหนดอื่น

ในขณะที่ไฟดับมีโหนดทั้งหมด 605 โหนดในคลัสเตอร์ สำหรับเหตุผลที่อธิบายไว้ข้างต้นนี่ก็เพียงพอที่จะทำให้เกิดคราสค่า gc_thresh3 เริ่มต้น ครั้งนี้เกิดขึ้นไม่เพียง แต่จะถูกทิ้งแพ็กเก็ต แต่พื้นที่ที่อยู่เสมือน Flannel / 24s ทั้งหมดหายไปจากตาราง ARP การสื่อสารระหว่างโหนดกับพ็อดและการค้นหา DNS ล้มเหลว (DNS โฮสต์อยู่ภายในคลัสเตอร์ดังที่อธิบายไว้ในรายละเอียดเพิ่มเติมในบทความนี้)

ในการแก้ไขค่า gc_thresh1, gc_thresh2 และ gc_thresh3 จะได้รับการยกขึ้นและ Flannel ต้องรีสตาร์ทเพื่อลงทะเบียนเครือข่ายที่หายไปอีกครั้ง

การเรียกใช้ DNS อย่างไม่คาดคิด

เพื่อรองรับการโยกย้ายของเราเราใช้ประโยชน์จาก DNS อย่างหนักเพื่ออำนวยความสะดวกในการจัดทำทราฟฟิกและการปรับลดส่วนเพิ่มจากมรดกสู่ Kubernetes สำหรับบริการของเรา เราตั้งค่า TTL ค่อนข้างต่ำในชุดข้อมูล Route53 ที่เกี่ยวข้อง เมื่อเราใช้โครงสร้างพื้นฐานดั้งเดิมในอินสแตนซ์ EC2 การกำหนดค่าตัวแก้ไขของเราชี้ไปที่ DNS ของ Amazon เรารับสิ่งนี้เพื่อรับและค่าใช้จ่ายของ TTL ค่อนข้างต่ำสำหรับบริการของเราและบริการของ Amazon (เช่น DynamoDB) ก็ไม่มีใครสังเกตเห็นส่วนใหญ่

เมื่อเราเข้าใช้บริการ Kubernetes มากขึ้นเราพบว่าตัวเองกำลังใช้บริการ DNS ที่ตอบรับ 250,000 คำขอต่อวินาที เราพบการหมดเวลาการค้นหา DNS ที่ไม่สม่ำเสมอและมีผลกระทบภายในแอปพลิเคชันของเรา สิ่งนี้เกิดขึ้นแม้จะมีความพยายามในการจูนอย่างละเอียดและผู้ให้บริการ DNS เปลี่ยนเป็นการปรับใช้ CoreDNS ซึ่งครั้งเดียวมียอดถึง 1,000 พ็อตที่ใช้ 120 คอร์

ในขณะที่ทำการค้นหาสาเหตุและวิธีแก้ปัญหาอื่น ๆ ที่เป็นไปได้เราพบบทความที่อธิบายสภาวะการแข่งขันที่มีผลต่อเฟรมเวิร์กการกรองแพ็กเก็ต Linux netfilter หมดเวลา DNS ที่เราเห็นพร้อมกับตัวเพิ่ม insert_failed บนส่วนต่อประสาน Flannel ที่สอดคล้องกับข้อค้นพบของบทความ

ปัญหาเกิดขึ้นระหว่างการแปลที่อยู่เครือข่ายต้นทางและปลายทาง (SNAT และ DNAT) และการแทรกที่ตามมาลงในตาราง conntrack วิธีแก้ปัญหาหนึ่งที่กล่าวถึงภายในและชุมชนเสนอให้ย้าย DNS ไปยังโหนดผู้ปฏิบัติงาน ในกรณีนี้:

  • SNAT ไม่จำเป็นเนื่องจากทราฟฟิกยังคงอยู่บนโลคัลบนโหนด ไม่จำเป็นต้องส่งผ่านอินเทอร์เฟซ eth0
  • DNAT ไม่จำเป็นเนื่องจาก IP ปลายทางเป็นโลคัลกับโหนดและไม่ใช่ pod แบบสุ่มที่เลือกต่อกฎ iptables

เราตัดสินใจที่จะก้าวไปข้างหน้าด้วยวิธีนี้ CoreDNS ถูกปรับใช้เป็น DaemonSet ใน Kubernetes และเราอัดเซิร์ฟเวอร์ DNS ของโหนดลงใน resolv.conf ของแต่ละฝักโดยการกำหนดค่า kubelet - การตั้งค่าสถานะคำสั่ง cluster-dns วิธีแก้ปัญหามีประสิทธิภาพสำหรับ DNS หมดเวลา

อย่างไรก็ตามเรายังคงเห็นแพ็กเก็ตที่ถูกดร็อปและการเพิ่มตัวนับ insert_failed ของอินเตอร์เฟสของ Flannel สิ่งนี้จะยังคงอยู่แม้หลังจากวิธีแก้ปัญหาข้างต้นเพราะเราหลีกเลี่ยง SNAT และ / หรือ DNAT สำหรับการรับส่งข้อมูล DNS เท่านั้น สภาพการแข่งขันจะยังคงเกิดขึ้นสำหรับการจราจรประเภทอื่น โชคดีที่แพ็คเก็ตของเราส่วนใหญ่เป็น TCP และเมื่อเงื่อนไขเกิดขึ้นแพ็คเก็ตจะถูกส่งใหม่ได้สำเร็จ การแก้ไขปัญหาระยะยาวสำหรับการรับส่งข้อมูลทุกประเภทเป็นสิ่งที่เรายังคงคุยกันอยู่

ใช้นักการทูตเพื่อให้ได้สมดุลภาระที่ดีขึ้น

เมื่อเราย้ายบริการแบ็คเอนด์ของเราไปยัง Kubernetes เราเริ่มประสบกับภาระที่ไม่สมดุลในพ็อด เราค้นพบว่าเนื่องจาก HTTP Keepalive การเชื่อมต่อของ ELB นั้นติดอยู่กับฝักแรกที่พร้อมใช้งานของแต่ละการนำไปใช้ดังนั้นการรับส่งข้อมูลส่วนใหญ่จึงไหลผ่านพ็อดที่มีอยู่เล็กน้อย หนึ่งในการบรรเทาแรกที่เราพยายามคือใช้ MaxSurge 100% ในการปรับใช้ใหม่สำหรับผู้กระทำผิดที่เลวร้ายที่สุด สิ่งนี้มีประสิทธิภาพเล็กน้อยและไม่ยั่งยืนในระยะยาวเมื่อมีการปรับใช้ที่ใหญ่ขึ้น

การลดลงอีกประการหนึ่งที่เราใช้คือการขยายการร้องขอทรัพยากรของบริการที่สำคัญเพื่อให้ฝักที่มีการผสมสีนั้นมีส่วนที่ใหญ่กว่าด้านอื่น ๆ สิ่งนี้ก็จะไม่สามารถเชื่อถือได้ในระยะยาวเนื่องจากทรัพยากรเสียและแอปพลิเคชันโหนดของเรามีเธรดเดียวและต่อยอดจึงมีประสิทธิภาพที่ 1 หลัก วิธีแก้ปัญหาที่ชัดเจนเพียงอย่างเดียวคือการใช้การปรับสมดุลโหลดให้ดีขึ้น

เรามองหาการประเมินของทูต สิ่งนี้ทำให้เรามีโอกาสที่จะปรับใช้ในแบบ จำกัด มากและเก็บเกี่ยวผลประโยชน์ทันที ทูตเป็นโอเพ่นซอร์สพร็อกซีเลเยอร์ 7 ประสิทธิภาพสูงที่ออกแบบมาสำหรับสถาปัตยกรรมที่มุ่งเน้นบริการขนาดใหญ่ สามารถใช้เทคนิคการทำโหลดบาลานซ์ขั้นสูงรวมถึงการลองใหม่อัตโนมัติการแตกวงจรและการ จำกัด อัตราทั่วโลก

การกำหนดค่าที่เราเกิดขึ้นคือให้มีทูตสวรรค์ด้านข้างแต่ละฝักที่มีหนึ่งเส้นทางและคลัสเตอร์เพื่อเข้าสู่พอร์ตคอนเทนเนอร์ภายใน เพื่อลดการเกิดรอยต่อที่อาจเกิดขึ้นและเพื่อรักษารัศมีการระเบิดให้น้อยที่สุดเราได้ใช้ฝัก Envoy พร็อกซี่ด้านหน้าจำนวนหนึ่งการปรับใช้ในแต่ละโซนความพร้อมใช้งาน (AZ) สำหรับแต่ละบริการ สิ่งเหล่านี้เป็นกลไกการค้นพบบริการขนาดเล็กที่วิศวกรคนหนึ่งของเรารวบรวมไว้ซึ่งเพียงส่งคืนรายชื่อพ็อดในแต่ละ AZ เพื่อรับบริการที่กำหนด

ตัวแทนบริการด้านหน้าใช้กลไกการค้นพบบริการนี้กับคลัสเตอร์ต้นน้ำและเส้นทาง เรากำหนดค่าการหมดเวลาที่เหมาะสมเพิ่มการตั้งค่าเซอร์กิตเบรกเกอร์ทั้งหมดจากนั้นกำหนดค่าการลองใหม่อีกครั้งเพื่อช่วยในการล้มเหลวชั่วคราวและการปรับใช้ที่ราบรื่น เราได้เปิดบริการทูตด้านหน้าแต่ละคนด้วย TCP ELB แม้ว่า keepalive จากหน้าพร็อกซีเลเยอร์หลักของเราได้ถูกตรึงไว้ในพ็อดทูตบางคนพวกเขาก็สามารถจัดการโหลดได้ดีกว่ามากและได้รับการกำหนดค่าให้มีความสมดุลผ่าน

สำหรับการปรับใช้เราใช้เบ็ด preStop ทั้งในแอพพลิเคชั่นและฝักด้านข้าง เบ็ดนี้เรียกว่าการตรวจสอบสุขภาพ sidecar ล้มเหลวในจุดสิ้นสุดของผู้ดูแลระบบรวมถึงการพักเครื่องเล็กน้อยเพื่อให้เวลาในการอนุญาตให้การเชื่อมต่อบนเครื่องบินเสร็จสมบูรณ์และระบายออกไป

เหตุผลหนึ่งที่เราสามารถเคลื่อนไหวได้อย่างรวดเร็วนั้นเป็นเพราะตัวชี้วัดที่หลากหลายที่เราสามารถรวมเข้ากับการตั้งค่าโพรปกติของเราได้อย่างง่ายดาย สิ่งนี้ทำให้เราเห็นว่าเกิดอะไรขึ้นเมื่อเราทำซ้ำในการตั้งค่าการกำหนดค่าและลดทราฟฟิก

ผลลัพธ์ได้ทันทีและชัดเจน เราเริ่มต้นด้วยบริการที่ไม่สมดุลที่สุดและ ณ จุดนี้ให้บริการต่อหน้าสิบสองบริการที่สำคัญที่สุดในคลัสเตอร์ของเรา ในปีนี้เราวางแผนที่จะย้ายไปที่เครือข่ายบริการเต็มรูปแบบด้วยการค้นพบบริการขั้นสูงการทำลายวงจรการตรวจจับค่าผิดปกติการ จำกัด อัตราและการติดตาม

รูปที่ 3–1 การบรรจบกันของ CPU ของบริการเดียวระหว่าง cutover to envoy

ผลลัพธ์สุดท้าย

จากการเรียนรู้เหล่านี้และการวิจัยเพิ่มเติมเราได้พัฒนาทีมงานโครงสร้างพื้นฐานที่แข็งแกร่งพร้อมความคุ้นเคยกับวิธีการออกแบบปรับใช้และใช้งานกลุ่ม Kubernetes ขนาดใหญ่ ตอนนี้องค์กรวิศวกรรมทั้งหมดของ Tinder มีความรู้และประสบการณ์เกี่ยวกับวิธีจัดคอนเทนเนอร์และปรับใช้แอปพลิเคชันของพวกเขาใน Kubernetes

ในโครงสร้างพื้นฐานแบบดั้งเดิมของเราเมื่อต้องการขนาดเพิ่มเติมเรามักประสบผ่านหลายนาทีของการรอให้อินสแตนซ์ EC2 ใหม่ออนไลน์ ขณะนี้ตู้คอนเทนเนอร์กำหนดเวลาและให้บริการการจราจรภายในไม่กี่วินาทีเมื่อเทียบกับนาที การกำหนดเวลาคอนเทนเนอร์หลายตู้บนอินสแตนซ์ EC2 เดียวยังช่วยเพิ่มความหนาแน่นของแนวนอน เป็นผลให้เราคาดการณ์การประหยัดต้นทุนอย่างมากสำหรับ EC2 ในปี 2019 เมื่อเทียบกับปีที่แล้ว

ใช้เวลาเกือบสองปี แต่เราได้สรุปการโยกย้ายของเราในเดือนมีนาคม 2019 Tinder Platform ทำงานเฉพาะในคลัสเตอร์ Kubernetes ซึ่งประกอบด้วยบริการ 200, 1,000 โหนด, 15,000 ฝักและ 15,000 คอนเทนเนอร์ โครงสร้างพื้นฐานไม่ใช่งานที่สงวนไว้สำหรับทีมปฏิบัติการของเราอีกต่อไป แต่วิศวกรทั่วทั้งองค์กรมีส่วนร่วมในความรับผิดชอบนี้และสามารถควบคุมวิธีการสร้างและปรับใช้แอปพลิเคชันของพวกเขากับทุกสิ่งในรูปของรหัส