ชุดโพสต์บน Istio Service Mesh

เรากำลังเริ่มชุดโพสต์ที่จัดแสดงความสามารถบางอย่างของ Istio Service Mesh เมื่อรวมกับ Red Hat OpenShift และ Kubernetes

ชุดโพสต์บน Istio Service Mesh

ส่วนที่หนึ่ง วันนี้:

  • มาอธิบายแนวคิดของคอนเทนเนอร์พ่วงข้าง 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 ซึ่งอยู่ในคอนเทนเนอร์เดียว Kubernetes-pod พร้อมบริการที่ได้รับการควบคุมและแทรกและแยกฟังก์ชันการทำงานและข้อมูลตามการกำหนดค่าที่กำหนด เราเน้นย้ำว่านี่คือการกำหนดค่าของคุณเอง และอยู่นอกโค้ดของคุณ ดังนั้นโค้ดจึงง่ายขึ้นและสั้นลงมาก

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

ตาข่ายบริการ

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

Istio ทำงานอย่างไรกับไมโครเซอร์วิส

นี่คือลักษณะการทำงานของตู้คอนเทนเนอร์เทียมข้างรถจักรยานยนต์ Kubernetes и มินิชิฟต์ มุมมองจากมุมสูง: เปิดอินสแตนซ์ของ Minishift สร้างโปรเจ็กต์สำหรับ Istio (หรือเรียกว่า "istio-system") ติดตั้งและรันส่วนประกอบที่เกี่ยวข้องกับ Istio ทั้งหมด จากนั้น เมื่อคุณสร้างโปรเจ็กต์และพ็อด คุณจะต้องเพิ่มข้อมูลการกำหนดค่าในการปรับใช้ และพ็อดของคุณจะเริ่มใช้ Istio แผนภาพแบบง่ายมีลักษณะดังนี้:

ชุดโพสต์บน Istio Service Mesh

ตอนนี้คุณสามารถเปลี่ยนการตั้งค่า Istio ตามลำดับ เช่น เพื่อจัดระเบียบการฉีดข้อผิดพลาด การสนับสนุน การปรับใช้นกขมิ้น หรือคุณสมบัติอื่น ๆ ของ Istio - และทั้งหมดนี้โดยไม่ต้องแตะโค้ดของแอปพลิเคชันเอง สมมติว่าคุณต้องการเปลี่ยนเส้นทางการเข้าชมเว็บทั้งหมดจากผู้ใช้ของลูกค้ารายใหญ่ที่สุดของคุณ (Foo Corporation) ไปยังเวอร์ชันใหม่ของไซต์ ในการดำเนินการนี้ เพียงสร้างกฎการกำหนดเส้นทาง Istio ที่จะค้นหา @foocorporation.com ใน ID ผู้ใช้ และเปลี่ยนเส้นทางตามนั้น สำหรับผู้ใช้รายอื่นจะไม่มีอะไรเปลี่ยนแปลง ในระหว่างนี้ คุณจะทดสอบเว็บไซต์เวอร์ชันใหม่อย่างใจเย็น และโปรดทราบว่าคุณไม่จำเป็นต้องให้นักพัฒนามีส่วนร่วมในเรื่องนี้เลย

และคุณจะต้องจ่ายเงินแพงเพื่อมันไหม?

ไม่เลย. Istio ค่อนข้างเร็วและเขียนไว้ Go และสร้างค่าใช้จ่ายได้น้อยมาก นอกจากนี้ การสูญเสียประสิทธิภาพการทำงานออนไลน์ที่อาจเกิดขึ้นยังถูกชดเชยด้วยการเพิ่มผลผลิตของนักพัฒนาอีกด้วย อย่างน้อยก็ในทางทฤษฎี อย่าลืมว่าเวลาของนักพัฒนามีค่า สำหรับต้นทุนซอฟต์แวร์ Istio เป็นซอฟต์แวร์โอเพ่นซอร์ส ดังนั้นคุณจึงสามารถรับและใช้งานได้ฟรี

เชี่ยวชาญด้วยตัวคุณเอง

ทีมนักพัฒนาประสบการณ์ Red Hat ได้พัฒนาการปฏิบัติเชิงลึก ความเป็นผู้นำ โดย Istio (เป็นภาษาอังกฤษ) มันทำงานบน Linux, MacOS และ Windows และโค้ดมีอยู่ใน Java และ Node.js

บทเรียนเชิงโต้ตอบ 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 Service Mesh
หนังสือเล่มนี้เกี่ยวกับอะไร:

  • เซอร์วิสเมชคืออะไร?
  • ระบบ Istio และบทบาทในสถาปัตยกรรมไมโครเซอร์วิส
  • การใช้ Istio เพื่อแก้ไขปัญหาต่อไปนี้:
    • ความทนทานต่อความผิดพลาด
    • เส้นทาง;
    • การทดสอบความโกลาหล
    • การรักษาความปลอดภัย
    • การรวบรวมการวัดและส่งข้อมูลทางไกลโดยใช้การติดตาม ตัวชี้วัด และ Grafana

ในการดาวน์โหลดหนังสือ

ชุดบทความเกี่ยวกับ Service Mesh และ Istio

ลองด้วยตัวคุณเอง

โพสต์ชุดนี้ไม่ได้มีจุดมุ่งหมายเพื่อให้เจาะลึกโลกของ Istio เราแค่อยากแนะนำให้คุณรู้จักกับแนวคิดนี้ และอาจสร้างแรงบันดาลใจให้คุณลองใช้ Istio ด้วยตัวเอง สามารถทำได้ฟรีโดยสมบูรณ์ และ Red Hat ก็มีเครื่องมือทั้งหมดที่คุณต้องการเพื่อเริ่มต้นใช้งาน OpenShift, Kubernetes, Linux Containers และ Istio ซึ่งรวมถึง: แพลตฟอร์มคอนเทนเนอร์ OpenShift ของนักพัฒนา Red Hat, คำแนะนำของเราเกี่ยวกับ Istio และแหล่งข้อมูลอื่น ๆ ของเรา ไมโครไซต์บน Service Mesh. อย่ารอช้า เริ่มเลยวันนี้!

กฎการกำหนดเส้นทาง Istio: กำหนดทิศทางคำขอบริการในที่ที่ต้องไป

เปิดกะ и Kubernetes ทำหน้าที่จัดการเรื่องที่อยู่ได้อย่างดีเยี่ยม ไมโครเซอร์วิส ถูกส่งไปยังพ็อดที่ต้องการ นี่คือสาเหตุหนึ่งที่ทำให้ Kubernetes มีอยู่ - การกำหนดเส้นทางและการทำโหลดบาลานซ์ แต่ถ้าคุณต้องการเส้นทางที่ละเอียดอ่อนและซับซ้อนกว่านี้ล่ะ? ตัวอย่างเช่น หากต้องการใช้ไมโครเซอร์วิสสองเวอร์ชันพร้อมกัน กฎเส้นทาง Istio สามารถช่วยได้อย่างไร

กฎการกำหนดเส้นทางคือกฎที่กำหนดทางเลือกของเส้นทางอย่างแท้จริง ไม่ว่าระบบจะมีความซับซ้อนระดับใดก็ตาม หลักการทำงานทั่วไปของกฎเหล่านี้ยังคงเรียบง่าย: คำขอจะถูกส่งไปตามพารามิเตอร์บางตัวและค่าส่วนหัว HTTP
ลองดูตัวอย่าง:

ค่าเริ่มต้นของ Kubernetes: เล็กน้อย "50/50"

ในตัวอย่างของเรา เราจะแสดงวิธีใช้ไมโครเซอร์วิสสองเวอร์ชันพร้อมกันใน OpenShift เรียกว่า v1 และ v2 แต่ละเวอร์ชันทำงานในพ็อด Kubernetes ของตัวเอง และตามค่าเริ่มต้นแล้วจะรันการกำหนดเส้นทาง Round Robin ที่สมดุลเท่ากัน แต่ละพ็อดจะได้รับส่วนแบ่งคำขอตามจำนวนอินสแตนซ์ไมโครเซอร์วิส หรืออีกนัยหนึ่งคือการจำลอง Istio ให้คุณเปลี่ยนยอดคงเหลือนี้ด้วยตนเอง

สมมติว่าเราใช้บริการคำแนะนำของเราสองเวอร์ชันบน OpenShift, Recommend-v1 และ Recommend-v2
ในรูป รูปที่ 1 แสดงให้เห็นว่าเมื่อแต่ละบริการแสดงในอินสแตนซ์เดียว คำขอจะสลับกันเท่าๆ กัน: 1-2-1-2-... นี่คือวิธีการทำงานของการกำหนดเส้นทาง Kubernetes ตามค่าเริ่มต้น:

ชุดโพสต์บน Istio Service Mesh

การกระจายน้ำหนักระหว่างเวอร์ชัน

ในรูป รูปที่ 2 แสดงให้เห็นว่าจะเกิดอะไรขึ้นหากคุณเพิ่มจำนวนการจำลองบริการ v2 จากหนึ่งเป็นสอง (ซึ่งทำได้ด้วยคำสั่ง oc scale —replicas=2 การปรับใช้/คำแนะนำ-v2) อย่างที่คุณเห็น คำขอระหว่าง v1 และ v2 จะถูกแบ่งออกเป็นอัตราส่วนหนึ่งต่อสาม: 1-2-2-1-2-2-...:

ชุดโพสต์บน Istio Service Mesh

ละเว้นเวอร์ชันโดยใช้ Istio

Istio ทำให้การเปลี่ยนแปลงการกระจายคำขอในแบบที่เราต้องการเป็นเรื่องง่าย ตัวอย่างเช่น ส่งการรับส่งข้อมูลทั้งหมดไปยังคำแนะนำ-v1 เท่านั้นโดยใช้ไฟล์ Istio yaml ต่อไปนี้

ชุดโพสต์บน Istio Service Mesh

ที่นี่คุณต้องใส่ใจกับสิ่งนี้: เลือกพ็อดตามป้ายกำกับ ตัวอย่างของเราใช้ป้ายกำกับ v1 พารามิเตอร์ “น้ำหนัก: 100” หมายความว่าการรับส่งข้อมูล 100% จะถูกส่งไปยังพ็อดบริการทั้งหมดที่มีป้ายกำกับ v1

การกระจายคำสั่งระหว่างเวอร์ชัน (Canary Deployment)

จากนั้น เมื่อใช้พารามิเตอร์ Weight คุณสามารถกำหนดทิศทางการรับส่งข้อมูลไปยังพ็อดทั้งสองได้ โดยไม่สนใจจำนวนอินสแตนซ์ไมโครเซอร์วิสที่ทำงานในแต่ละพ็อด ตัวอย่างเช่น ที่นี่เรากำหนดทิศทาง 90% ของการเข้าชมไปที่ v1 และ 10% ไปยัง v2:

ชุดโพสต์บน Istio Service Mesh

แยกเส้นทางสำหรับผู้ใช้มือถือ

โดยสรุป เราจะแสดงวิธีบังคับให้การรับส่งข้อมูลของผู้ใช้อุปกรณ์เคลื่อนที่ไปยังบริการ v2 และวิธีอื่นๆ ไปยัง v1 ในการดำเนินการนี้ เราใช้นิพจน์ทั่วไปเพื่อวิเคราะห์ค่า user-agent ในส่วนหัวของคำขอ:

ชุดโพสต์บน Istio Service Mesh

ตอนนี้ถึงตาคุณแล้ว

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

และจำไว้ว่า Ops ไม่ใช่ Dev

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

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

ใช้จินตนาการของคุณ

ลองจินตนาการถึงความเป็นไปได้ของการวิเคราะห์ส่วนหัวโดยใช้นิพจน์ทั่วไป ต้องการเปลี่ยนเส้นทางลูกค้ารายใหญ่ที่สุดของคุณไปยังเวอร์ชันพิเศษของคุณ ไมโครเซอร์วิส? อย่างง่ายดาย! ต้องการเวอร์ชันแยกต่างหากสำหรับเบราว์เซอร์ Chrome หรือไม่? ไม่มีปัญหา! คุณสามารถกำหนดเส้นทางการรับส่งข้อมูลได้เกือบทุกลักษณะ

ลองด้วยตัวคุณเอง

การอ่านเกี่ยวกับ Istio, Kubernetes และ OpenShift ก็เรื่องหนึ่ง แต่ทำไมไม่ลองสัมผัสทุกอย่างด้วยตัวเองล่ะ ทีม โปรแกรมนักพัฒนา Red Hat ได้เตรียมคำแนะนำโดยละเอียด (เป็นภาษาอังกฤษ) ที่จะช่วยให้คุณเชี่ยวชาญเทคโนโลยีเหล่านี้ได้โดยเร็วที่สุด คู่มือนี้เป็นโอเพ่นซอร์ส 100% ดังนั้นจึงโพสต์ในโดเมนสาธารณะ ไฟล์ใช้งานได้บน macOS, Linux และ Windows และซอร์สโค้ดมีให้ใช้งานในเวอร์ชัน Java และ node.js (เวอร์ชันในภาษาอื่นจะตามมาในเร็วๆ นี้) เพียงเปิดพื้นที่เก็บข้อมูล git ที่เกี่ยวข้องในเบราว์เซอร์ของคุณ การสาธิตนักพัฒนา Red Hat.

ในโพสต์ถัดไป: เราแก้ไขปัญหาได้อย่างสวยงาม

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

ที่มา: will.com

เพิ่มความคิดเห็น