เรากำลังเริ่มชุดโพสต์ที่จัดแสดงความสามารถบางอย่างของ Istio Service Mesh เมื่อรวมกับ Red Hat OpenShift และ Kubernetes
ส่วนที่หนึ่ง วันนี้:
- มาอธิบายแนวคิดของคอนเทนเนอร์พ่วงข้าง Kubernetes และกำหนดสาระสำคัญของโพสต์ชุดนี้: "คุณไม่จำเป็นต้องเปลี่ยนแปลงอะไรในรหัสของคุณ".
- ขอแนะนำสิ่งพื้นฐานของ Istio - กฎการกำหนดเส้นทาง คุณสมบัติ Istio อื่นๆ ทั้งหมดสร้างขึ้นจากคุณสมบัติเหล่านี้ เนื่องจากเป็นกฎที่อนุญาตให้คุณกำหนดเส้นทางการรับส่งข้อมูลไปยังไมโครเซอร์วิส โดยใช้ไฟล์ YAML ที่อยู่ภายนอกรหัสบริการ เรากำลังพิจารณาแผนการปรับใช้ Canary Deployment ด้วย โบนัสปีใหม่ – บทเรียนเชิงโต้ตอบ 10 บทเกี่ยวกับ Istio
ส่วนที่สองจะมาเร็ว ๆ นี้ จะบอกคุณ:
- วิธีที่ Istio ใช้งาน Pool Ejection ร่วมกับ Circuit Breaker และจะสาธิตวิธีที่ Istio ช่วยให้คุณสามารถลบพ็อดที่ทำงานไม่ดีหรือมีประสิทธิภาพต่ำออกจากวงจรปรับสมดุลได้อย่างไร
- นอกจากนี้เรายังจะดูหัวข้อ Circuit Breaker จากโพสต์แรกเพื่อดูว่า Istio สามารถใช้ได้อย่างไรที่นี่ เราจะแสดงวิธีกำหนดเส้นทางการรับส่งข้อมูลและจัดการข้อผิดพลาดของเครือข่ายโดยใช้ไฟล์การกำหนดค่า YAML และคำสั่งเทอร์มินัลโดยไม่มีการเปลี่ยนแปลงรหัสบริการแม้แต่น้อย
ส่วนที่สาม:
- เรื่องราวเกี่ยวกับการติดตามและการเฝ้าสังเกตซึ่งมีอยู่แล้วในเครื่องหรือเพิ่มลงใน Istio ได้อย่างง่ายดาย เราจะแสดงวิธีใช้เครื่องมือเช่น Prometheus, Jaeger และ Grafana ร่วมกับการปรับขนาด OpenShift เพื่อจัดการสถาปัตยกรรมไมโครเซอร์วิสอย่างง่ายดาย
- เราเปลี่ยนจากการตรวจสอบและจัดการข้อผิดพลาดไปสู่การนำข้อผิดพลาดเหล่านี้เข้าสู่ระบบโดยเจตนา กล่าวอีกนัยหนึ่ง เราได้เรียนรู้วิธีการฉีดข้อผิดพลาดโดยไม่ต้องเปลี่ยนซอร์สโค้ด ซึ่งมีความสำคัญมากจากมุมมองของการทดสอบ เนื่องจากหากคุณเปลี่ยนโค้ดเองเพื่อการนี้ ก็มีความเสี่ยงที่จะเกิดข้อผิดพลาดเพิ่มเติม
สุดท้ายนี้ในโพสต์สุดท้ายบน Istio Service Mesh:
- ไปที่ด้านมืดกันเถอะ แม่นยำยิ่งขึ้นเราจะเรียนรู้การใช้รูปแบบ Dark Launch เมื่อมีการปรับใช้และทดสอบโค้ดโดยตรงกับข้อมูลการผลิต แต่ไม่ส่งผลกระทบต่อการทำงานของระบบ แต่อย่างใด นี่คือจุดที่ความสามารถของ Istio ในการแบ่งการรับส่งข้อมูลมีประโยชน์ และความสามารถในการทดสอบข้อมูลการผลิตจริงโดยไม่ส่งผลกระทบต่อการทำงานของระบบการต่อสู้ แต่อย่างใดเป็นวิธีการตรวจสอบที่น่าเชื่อถือที่สุด
- จากการเปิดตัวแบบ Dark Launch เราจะแสดงวิธีใช้โมเดล Canary Deployment เพื่อลดความเสี่ยงและทำให้รับโค้ดใหม่เข้าสู่การใช้งานจริงได้ง่ายขึ้น Canary Deployment นั้นยังห่างไกลจากสิ่งใหม่ แต่ Istio อนุญาตให้คุณนำโครงร่างนี้ไปใช้ด้วยไฟล์ YAML ธรรมดา ๆ
- สุดท้ายนี้ เราจะแสดงวิธีใช้ Istio Egress เพื่อให้สิทธิ์เข้าถึงบริการแก่ผู้ที่อยู่นอกคลัสเตอร์ของคุณ เพื่อใช้ความสามารถของ Istio เมื่อทำงานกับอินเทอร์เน็ต
เอาล่ะเราไป...
เครื่องมือตรวจสอบและการจัดการ Istio - ทุกสิ่งที่คุณต้องการเพื่อประสานไมโครเซอร์วิสใน Service Mesh
Istio Service Mesh คืออะไร
เครือข่ายบริการใช้ฟังก์ชันต่างๆ เช่น การตรวจสอบการรับส่งข้อมูล การควบคุมการเข้าถึง การค้นพบ การรักษาความปลอดภัย ความทนทานต่อข้อผิดพลาด และสิ่งที่เป็นประโยชน์อื่นๆ สำหรับกลุ่มบริการ Istio ช่วยให้คุณทำทั้งหมดนี้ได้โดยไม่ต้องเปลี่ยนแปลงโค้ดของบริการแม้แต่น้อย ความลับของเวทมนตร์คืออะไร? Istio แนบพร็อกซีของตัวเองกับแต่ละบริการในรูปแบบของคอนเทนเนอร์รถเทียมข้างรถจักรยานยนต์ (รถเทียมข้างรถจักรยานยนต์คือรถเทียมข้างรถจักรยานยนต์) หลังจากนั้นการรับส่งข้อมูลทั้งหมดไปยังบริการนี้จะผ่านพร็อกซี ซึ่งตามแนวทางของนโยบายที่ระบุ จะตัดสินใจว่าการรับส่งข้อมูลนี้อย่างไร เมื่อใด และหรือไม่ ควรเข้าถึงบริการเลย นอกจากนี้ Istio ยังทำให้สามารถนำเทคนิค DevOps ขั้นสูงไปใช้ เช่น การใช้งานแบบคานารี เซอร์กิตเบรกเกอร์ การฉีดข้อผิดพลาด และอื่นๆ อีกมากมาย
Istio ทำงานอย่างไรกับคอนเทนเนอร์และ Kubernetes
Service Mesh ของ Istio คือการนำทุกสิ่งที่จำเป็นในการสร้างและจัดการไมโครเซอร์วิสมาใช้ ไม่ว่าจะเป็นการตรวจสอบ การติดตาม เซอร์กิตเบรกเกอร์ การกำหนดเส้นทาง โหลดบาลานซ์ การฉีดข้อผิดพลาด การลองใหม่ การหมดเวลา การมิเรอร์ การควบคุมการเข้าถึง การจำกัดอัตรา และอื่นๆ อีกมากมาย อื่นๆ แม้ว่าในปัจจุบันนี้จะมีไลบรารี่มากมายที่นำฟังก์ชันเหล่านี้ไปใช้โดยตรงในโค้ด แต่ด้วย Istio คุณสามารถรับสิ่งเดียวกันทั้งหมดได้โดยไม่ต้องเปลี่ยนแปลงอะไรในโค้ดของคุณ
ตามโมเดลรถเทียมข้างรถจักรยานยนต์ Istio ทำงานในคอนเทนเนอร์ Linux ซึ่งอยู่ในคอนเทนเนอร์เดียว
สิ่งที่สำคัญก็คือองค์ประกอบการปฏิบัติงานของไมโครเซอร์วิสนั้นไม่ได้เชื่อมโยงกับโค้ดเลย ซึ่งหมายความว่าการดำเนินการของไมโครเซอร์วิสสามารถถ่ายโอนไปยังผู้เชี่ยวชาญด้านไอทีได้อย่างปลอดภัย เหตุใดนักพัฒนาจึงต้องรับผิดชอบต่อเซอร์กิตเบรกเกอร์และการฉีดข้อผิดพลาด? ตอบสนองใช่ แต่ประมวลผลและสร้างมันขึ้นมาเหรอ? หากคุณลบทั้งหมดนี้ออกจากโค้ด โปรแกรมเมอร์จะสามารถมุ่งเน้นไปที่ฟังก์ชันการทำงานของแอปพลิเคชันได้อย่างเต็มที่ และโค้ดก็จะสั้นลงและง่ายขึ้น
ตาข่ายบริการ
Istio ซึ่งใช้ฟังก์ชันสำหรับจัดการไมโครเซอร์วิสนอกโค้ด คือแนวคิดของ Service Mesh กล่าวอีกนัยหนึ่ง มันเป็นกลุ่มที่มีการประสานงานของไบนารีตั้งแต่หนึ่งตัวขึ้นไปที่ก่อตัวเป็นตาข่ายของฟังก์ชันเครือข่าย
Istio ทำงานอย่างไรกับไมโครเซอร์วิส
นี่คือลักษณะการทำงานของตู้คอนเทนเนอร์เทียมข้างรถจักรยานยนต์
ตอนนี้คุณสามารถเปลี่ยนการตั้งค่า Istio ตามลำดับ เช่น เพื่อจัดระเบียบการฉีดข้อผิดพลาด การสนับสนุน
และคุณจะต้องจ่ายเงินแพงเพื่อมันไหม?
ไม่เลย. Istio ค่อนข้างเร็วและเขียนไว้
เชี่ยวชาญด้วยตัวคุณเอง
ทีมนักพัฒนาประสบการณ์ Red Hat ได้พัฒนาการปฏิบัติเชิงลึก
บทเรียนเชิงโต้ตอบ 10 บทเรียนเกี่ยวกับ Istio
บล็อก 1 - สำหรับผู้เริ่มต้น
ข้อมูลเบื้องต้นเกี่ยวกับอิสติโอ
นาที 30
มาทำความรู้จักกับ Service Mesh เรียนรู้วิธีติดตั้ง Istio ในคลัสเตอร์ OpenShift Kubernetes กันดีกว่า
การปรับใช้ไมโครเซอร์วิสใน Istio
นาที 30
เราใช้ Istio เพื่อปรับใช้ไมโครเซอร์วิสสามรายการด้วย Spring Boot และ Vert.x
บล็อก 2 – ระดับกลาง
การตรวจสอบและติดตามใน Istio
นาที 60
เราจะสำรวจเครื่องมือตรวจสอบในตัวของ Istio ตัวชี้วัดที่กำหนดเอง และ OpenTracing ผ่าน Prometheus และ Grafana
การกำหนดเส้นทางอย่างง่ายใน Istio
นาที 60
ดูวิธีจัดการการกำหนดเส้นทางใน Istio โดยใช้กฎง่ายๆ
กฎการกำหนดเส้นทางขั้นสูง
นาที 60
มาดูการกำหนดเส้นทางอัจฉริยะ การควบคุมการเข้าถึง การปรับสมดุลโหลด และการจำกัดอัตราของ Istio กัน
บล็อก 3 – ผู้ใช้ขั้นสูง
การฉีดข้อผิดพลาดใน Istio
นาที 60
เราศึกษาสถานการณ์การจัดการความล้มเหลวในแอปพลิเคชันแบบกระจาย การสร้างข้อผิดพลาด HTTP และความล่าช้าของเครือข่าย และเรียนรู้การใช้วิศวกรรมวุ่นวายเพื่อฟื้นฟูสภาพแวดล้อม
เบรกเกอร์ใน Istio
นาที 30
เราติดตั้ง Siege สำหรับไซต์ทดสอบความเครียด และเรียนรู้วิธีตรวจสอบความทนทานต่อข้อผิดพลาดของแบ็กเอนด์โดยใช้การเล่นซ้ำ เซอร์กิตเบรกเกอร์ และการดีดพูลออก
ทางออกและอิสติโอ
นาที 10
เราใช้เส้นทาง Egress เพื่อสร้างกฎสำหรับการโต้ตอบของบริการภายในกับ API และบริการภายนอก
อิสติโอ และคิอาลี
นาที 15
เรียนรู้การใช้ Kiali เพื่อดูภาพรวมของ Service Mesh และสำรวจคำขอและโฟลว์ข้อมูล
TLS ร่วมกันใน Istio
นาที 15
เราสร้าง Istio Gateway และ VirtualService จากนั้นเราจะศึกษา TLS (mTLS) ร่วมกันและการตั้งค่าโดยละเอียด
บล็อก 3.1 - เจาะลึก: Istio Service Mesh สำหรับไมโครเซอร์วิส
หนังสือเล่มนี้เกี่ยวกับอะไร:
- เซอร์วิสเมชคืออะไร?
- ระบบ Istio และบทบาทในสถาปัตยกรรมไมโครเซอร์วิส
- การใช้ Istio เพื่อแก้ไขปัญหาต่อไปนี้:
- ความทนทานต่อความผิดพลาด
- เส้นทาง;
- การทดสอบความโกลาหล
- การรักษาความปลอดภัย
- การรวบรวมการวัดและส่งข้อมูลทางไกลโดยใช้การติดตาม ตัวชี้วัด และ Grafana
ชุดบทความเกี่ยวกับ Service Mesh และ Istio
กฎการกำหนดเส้นทาง Istio: กำหนดทิศทางคำขอบริการในที่ที่ต้องไป เซอร์กิตเบรกเกอร์ใน Isio: การจัดการการดีดตัวของพูล Circuit Breaker ใน Istio: เมื่อความล้มเหลวเป็นทางเลือก การติดตามและติดตามใน Istio: ทุกอย่างเคลื่อนไหวที่ไหนและเร็วแค่ไหน วิศวกรรมความโกลาหลใน Istio: นั่นคือสิ่งที่ตั้งใจไว้ เปิดตัว Dark ใน Istio: หน่วยสืบราชการลับ Canary Deployment ใน Istio: ทำให้การว่าจ้างง่ายขึ้น Istio Egress: ออกจากร้านขายของที่ระลึก
ลองด้วยตัวคุณเอง
โพสต์ชุดนี้ไม่ได้มีจุดมุ่งหมายเพื่อให้เจาะลึกโลกของ Istio เราแค่อยากแนะนำให้คุณรู้จักกับแนวคิดนี้ และอาจสร้างแรงบันดาลใจให้คุณลองใช้ Istio ด้วยตัวเอง สามารถทำได้ฟรีโดยสมบูรณ์ และ Red Hat ก็มีเครื่องมือทั้งหมดที่คุณต้องการเพื่อเริ่มต้นใช้งาน OpenShift, Kubernetes, Linux Containers และ Istio ซึ่งรวมถึง:
กฎการกำหนดเส้นทาง Istio: กำหนดทิศทางคำขอบริการในที่ที่ต้องไป
กฎการกำหนดเส้นทางคือกฎที่กำหนดทางเลือกของเส้นทางอย่างแท้จริง ไม่ว่าระบบจะมีความซับซ้อนระดับใดก็ตาม หลักการทำงานทั่วไปของกฎเหล่านี้ยังคงเรียบง่าย: คำขอจะถูกส่งไปตามพารามิเตอร์บางตัวและค่าส่วนหัว HTTP
ลองดูตัวอย่าง:
ค่าเริ่มต้นของ Kubernetes: เล็กน้อย "50/50"
ในตัวอย่างของเรา เราจะแสดงวิธีใช้ไมโครเซอร์วิสสองเวอร์ชันพร้อมกันใน OpenShift เรียกว่า v1 และ v2 แต่ละเวอร์ชันทำงานในพ็อด Kubernetes ของตัวเอง และตามค่าเริ่มต้นแล้วจะรันการกำหนดเส้นทาง Round Robin ที่สมดุลเท่ากัน แต่ละพ็อดจะได้รับส่วนแบ่งคำขอตามจำนวนอินสแตนซ์ไมโครเซอร์วิส หรืออีกนัยหนึ่งคือการจำลอง Istio ให้คุณเปลี่ยนยอดคงเหลือนี้ด้วยตนเอง
สมมติว่าเราใช้บริการคำแนะนำของเราสองเวอร์ชันบน OpenShift, Recommend-v1 และ Recommend-v2
ในรูป รูปที่ 1 แสดงให้เห็นว่าเมื่อแต่ละบริการแสดงในอินสแตนซ์เดียว คำขอจะสลับกันเท่าๆ กัน: 1-2-1-2-... นี่คือวิธีการทำงานของการกำหนดเส้นทาง Kubernetes ตามค่าเริ่มต้น:
การกระจายน้ำหนักระหว่างเวอร์ชัน
ในรูป รูปที่ 2 แสดงให้เห็นว่าจะเกิดอะไรขึ้นหากคุณเพิ่มจำนวนการจำลองบริการ v2 จากหนึ่งเป็นสอง (ซึ่งทำได้ด้วยคำสั่ง oc scale —replicas=2 การปรับใช้/คำแนะนำ-v2) อย่างที่คุณเห็น คำขอระหว่าง v1 และ v2 จะถูกแบ่งออกเป็นอัตราส่วนหนึ่งต่อสาม: 1-2-2-1-2-2-...:
ละเว้นเวอร์ชันโดยใช้ Istio
Istio ทำให้การเปลี่ยนแปลงการกระจายคำขอในแบบที่เราต้องการเป็นเรื่องง่าย ตัวอย่างเช่น ส่งการรับส่งข้อมูลทั้งหมดไปยังคำแนะนำ-v1 เท่านั้นโดยใช้ไฟล์ Istio yaml ต่อไปนี้
ที่นี่คุณต้องใส่ใจกับสิ่งนี้: เลือกพ็อดตามป้ายกำกับ ตัวอย่างของเราใช้ป้ายกำกับ v1 พารามิเตอร์ “น้ำหนัก: 100” หมายความว่าการรับส่งข้อมูล 100% จะถูกส่งไปยังพ็อดบริการทั้งหมดที่มีป้ายกำกับ v1
การกระจายคำสั่งระหว่างเวอร์ชัน (Canary Deployment)
จากนั้น เมื่อใช้พารามิเตอร์ Weight คุณสามารถกำหนดทิศทางการรับส่งข้อมูลไปยังพ็อดทั้งสองได้ โดยไม่สนใจจำนวนอินสแตนซ์ไมโครเซอร์วิสที่ทำงานในแต่ละพ็อด ตัวอย่างเช่น ที่นี่เรากำหนดทิศทาง 90% ของการเข้าชมไปที่ v1 และ 10% ไปยัง v2:
แยกเส้นทางสำหรับผู้ใช้มือถือ
โดยสรุป เราจะแสดงวิธีบังคับให้การรับส่งข้อมูลของผู้ใช้อุปกรณ์เคลื่อนที่ไปยังบริการ v2 และวิธีอื่นๆ ไปยัง v1 ในการดำเนินการนี้ เราใช้นิพจน์ทั่วไปเพื่อวิเคราะห์ค่า user-agent ในส่วนหัวของคำขอ:
ตอนนี้ถึงตาคุณแล้ว
ตัวอย่างที่มีนิพจน์ทั่วไปสำหรับการแยกวิเคราะห์ส่วนหัวควรกระตุ้นให้คุณค้นหาการใช้กฎการกำหนดเส้นทาง Istio ของคุณเอง นอกจากนี้ความเป็นไปได้ที่นี่ยังค่อนข้างกว้างขวางเนื่องจากค่าส่วนหัวสามารถสร้างขึ้นในซอร์สโค้ดของแอปพลิเคชัน
และจำไว้ว่า Ops ไม่ใช่ Dev
ทุกสิ่งที่เราแสดงในตัวอย่างข้างต้นเสร็จสิ้นโดยไม่มีการเปลี่ยนแปลงซอร์สโค้ดแม้แต่น้อย ยกเว้นในกรณีที่จำเป็นต้องสร้างส่วนหัวคำขอพิเศษ Istio จะมีประโยชน์ทั้งสำหรับนักพัฒนาซึ่งจะสามารถใช้งานได้ในขั้นตอนการทดสอบและสำหรับผู้เชี่ยวชาญในการทำงานระบบไอทีซึ่งจะช่วยอย่างมากในการผลิต
เรามาทบทวนประโยคของโพสต์ชุดนี้กันอีกครั้ง: คุณไม่จำเป็นต้องเปลี่ยนแปลงอะไรในรหัสของคุณ. ไม่จำเป็นต้องสร้างอิมเมจใหม่หรือเปิดตัวคอนเทนเนอร์ใหม่ ทั้งหมดนี้ถูกนำมาใช้นอกโค้ด
ใช้จินตนาการของคุณ
ลองจินตนาการถึงความเป็นไปได้ของการวิเคราะห์ส่วนหัวโดยใช้นิพจน์ทั่วไป ต้องการเปลี่ยนเส้นทางลูกค้ารายใหญ่ที่สุดของคุณไปยังเวอร์ชันพิเศษของคุณ
ลองด้วยตัวคุณเอง
การอ่านเกี่ยวกับ Istio, Kubernetes และ OpenShift ก็เรื่องหนึ่ง แต่ทำไมไม่ลองสัมผัสทุกอย่างด้วยตัวเองล่ะ ทีม
ในโพสต์ถัดไป: เราแก้ไขปัญหาได้อย่างสวยงาม
วันนี้คุณได้เห็นแล้วว่ากฎการกำหนดเส้นทางของ Istio ทำอะไรได้บ้าง ทีนี้ลองนึกภาพสิ่งเดียวกัน แต่เกี่ยวข้องกับการจัดการข้อผิดพลาดเท่านั้น นี่คือสิ่งที่เราจะพูดถึงในโพสต์ถัดไป
ที่มา: will.com