บันทึก การแปล: นี่คือคำแปลของการชันสูตรพลิกศพต่อสาธารณะจากบล็อกวิศวกรรมของบริษัท . โดยอธิบายปัญหาเกี่ยวกับ conntrack ในคลัสเตอร์ Kubernetes ซึ่งทำให้บริการการผลิตบางอย่างหยุดทำงานบางส่วน
บทความนี้อาจเป็นประโยชน์สำหรับผู้ที่ต้องการเรียนรู้เพิ่มเติมอีกเล็กน้อยเกี่ยวกับการชันสูตรพลิกศพหรือป้องกันปัญหา DNS ที่อาจเกิดขึ้นในอนาคต
นี่ไม่ใช่ DNS
ไม่สามารถเป็น DNS ได้
มันคือ DNS
เล็กน้อยเกี่ยวกับการชันสูตรพลิกศพและกระบวนการใน Preply
การชันสูตรศพอธิบายถึงความผิดปกติหรือเหตุการณ์บางอย่างในการผลิต การชันสูตรพลิกศพประกอบด้วยลำดับเวลาของเหตุการณ์ ผลกระทบต่อผู้ใช้ สาเหตุที่แท้จริง การดำเนินการ และบทเรียนที่ได้รับ
ในการประชุมรายสัปดาห์กับพิซซ่า เราจะแบ่งปันข้อมูลต่างๆ ร่วมกับทีมงานด้านเทคนิค ส่วนที่สำคัญที่สุดประการหนึ่งของการประชุมดังกล่าวคือการชันสูตรพลิกศพ ซึ่งส่วนใหญ่มักจะมาพร้อมกับการนำเสนอพร้อมสไลด์และการวิเคราะห์เหตุการณ์เชิงลึกมากขึ้น แม้ว่าเราจะไม่ปรบมือหลังการชันสูตรพลิกศพ แต่เราพยายามพัฒนาวัฒนธรรม "ไม่ตำหนิ" (). เราเชื่อว่าการเขียนและการนำเสนอการชันสูตรพลิกศพสามารถช่วยให้เรา (และคนอื่นๆ) ป้องกันเหตุการณ์ที่คล้ายกันในอนาคตได้ ซึ่งเป็นเหตุผลที่เราแบ่งปันเรื่องราวเหล่านี้
บุคคลที่เกี่ยวข้องกับเหตุการณ์ควรรู้สึกว่าตนสามารถพูดออกมาได้อย่างละเอียดโดยไม่ต้องกลัวว่าจะถูกลงโทษหรือถูกลงโทษ ไม่มีตำหนิ! การเขียนชันสูตรพลิกศพไม่ใช่การลงโทษ แต่เป็นโอกาสในการเรียนรู้สำหรับทั้งบริษัท
ปัญหาเกี่ยวกับ DNS ใน Kubernetes การชันสูตรพลิกศพ
วันที่: 28.02.2020
ผู้เขียน: อาเม็ต ยู., อันเดรย์ เอส., อิกอร์ เค., อเล็กซ์ พี.
สถานะ: ที่เสร็จเรียบร้อย
สั้น ๆ : 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 ลดจำนวนพ็อดในการปรับใช้จากสามเหลือสอง
การแก้ปัญหา: การใช้งานแอปพลิเคชันครั้งถัดไปได้เริ่มต้นการสร้างโหนดใหม่ CoreDNS-autoscaler ได้เพิ่มพ็อดเพิ่มเติมเพื่อรองรับคลัสเตอร์ ซึ่งกระตุ้นให้เกิดการเขียนตาราง conntrack ใหม่
การตรวจจับ: การตรวจสอบของ Prometheus ตรวจพบข้อผิดพลาด 5xx จำนวนมากสำหรับบริการ A, B และ C และเริ่มการโทรไปยังวิศวกรที่ปฏิบัติหน้าที่
ข้อผิดพลาด 5xx ใน Kibana
กิจกรรม
การกระทำ
ชนิด
มีความรับผิดชอบ
งาน
ปิดใช้งานตัวปรับขนาดอัตโนมัติสำหรับ CoreDNS
ป้องกัน
อาเม็ต ยู.
เดโวปส์-695
ตั้งค่าเซิร์ฟเวอร์ DNS สำหรับแคช
ลด
แม็กซ์ วี.
เดโวปส์-665
ตั้งค่าการตรวจสอบ Conntrack
ป้องกัน
อาเม็ต ยู.
เดโวปส์-674
บทเรียนที่ได้รับ
อะไรผ่านไปด้วยดี:
- การตรวจสอบทำงานได้ดี การตอบสนองรวดเร็วและเป็นระเบียบ
- เราไม่ได้ถึงขีดจำกัดใดๆ บนโหนด
เกิดอะไรขึ้น:
- ยังไม่ทราบสาเหตุที่แท้จริงคล้ายคลึงกับ ในความขัดแย้ง
- การกระทำทั้งหมดจะแก้ไขเฉพาะผลที่ตามมา ไม่ใช่สาเหตุที่แท้จริง (ข้อบกพร่อง)
- เรารู้ว่าไม่ช้าก็เร็วเราอาจประสบปัญหากับ DNS แต่เราไม่ได้จัดลำดับความสำคัญของงาน
ที่เราโชคดี:
- การปรับใช้ครั้งต่อไปถูกทริกเกอร์โดย CoreDNS-autoscaler ซึ่งเขียนทับตาราง conntrack
- จุดบกพร่องนี้ส่งผลต่อบริการบางอย่างเท่านั้น
ไทม์ไลน์ (EET)
เวลา
การกระทำ
22:13
CoreDNS-autoscaler ลดจำนวนพ็อดจากสามเหลือสอง
22:18
วิศวกรที่ปฏิบัติหน้าที่เริ่มรับสายจากระบบติดตาม
22:21
วิศวกรที่ปฏิบัติหน้าที่เริ่มค้นหาสาเหตุของข้อผิดพลาด
22:39
วิศวกรที่ปฏิบัติหน้าที่ได้เริ่มเปลี่ยนบริการล่าสุดรายการใดรายการหนึ่งไปเป็นเวอร์ชันก่อนหน้า
22:40
ข้อผิดพลาด 5xx หยุดปรากฏ สถานการณ์มีเสถียรภาพแล้ว
- เวลาในการตรวจจับ: 4 นาที
- เวลาก่อนดำเนินการ: 21 นาที
- เวลาในการแก้ไข: 1 นาที
ข้อมูลเพิ่มเติม
- บันทึก 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 (ตัด)
เพื่อลดการใช้งาน CPU ให้เหลือน้อยที่สุด เคอร์เนล Linux จะใช้สิ่งที่เรียกว่า conntrack กล่าวโดยสรุป นี่คือยูทิลิตี้ที่ประกอบด้วยรายการบันทึก NAT ที่จัดเก็บไว้ในตารางพิเศษ เมื่อแพ็คเก็ตถัดไปมาถึงจากพ็อดเดียวกันไปยังพ็อดเดียวกันเช่นเดิม ที่อยู่ IP สุดท้ายจะไม่ถูกคำนวณใหม่ แต่จะถูกนำมาจากตาราง conntrack
คอนแทรคทำงานอย่างไร
ผลของการ
นี่เป็นตัวอย่างของการชันสูตรพลิกศพครั้งหนึ่งของเราซึ่งมีลิงก์ที่มีประโยชน์บางส่วน โดยเฉพาะในบทความนี้ เราแบ่งปันข้อมูลที่อาจเป็นประโยชน์กับบริษัทอื่นๆ นั่นคือเหตุผลที่เราไม่กลัวที่จะทำผิดพลาด และนั่นคือสาเหตุที่เราเปิดเผยการชันสูตรพลิกศพต่อสาธารณะ ต่อไปนี้เป็นการชันสูตรพลิกศพในที่สาธารณะที่น่าสนใจเพิ่มเติม:
- GitLab:
- Dropbox:
- Spotify:
- อื่นๆอีกมากมายจาก และที่เก็บข้อมูล
- ด้วย การชันสูตรพลิกศพในที่สาธารณะด้วย SRE Book
ที่มา: will.com