“อันตรายคือชื่อกลางของฉัน” Austin Powers ชายผู้ลึกลับระดับนานาชาติเคยกล่าวไว้ แต่สิ่งที่ได้รับการยกย่องอย่างสูงจากเจ้าหน้าที่ระดับสูงและบริการข่าวกรองนั้นไม่เหมาะกับบริการคอมพิวเตอร์เลย ซึ่งความเบื่อหน่ายดีกว่าอันตรายมาก
และ Istio ร่วมกับ OpenShift และ Kubernetes ทำให้การปรับใช้ไมโครเซอร์วิสนั้นน่าเบื่อและคาดเดาได้อย่างแท้จริง และนั่นก็เยี่ยมมาก เราจะพูดถึงเรื่องนี้และอื่นๆ อีกมากมายในโพสต์ที่สี่และโพสต์สุดท้ายของซีรีส์ Istio
เมื่อความเบื่อเป็นสิ่งที่ถูกต้อง
ในกรณีของเรา ความเบื่อจะเกิดขึ้นเฉพาะในระยะสุดท้ายเท่านั้น เมื่อสิ่งที่เหลืออยู่คือการนั่งดูกระบวนการ แต่สำหรับสิ่งนี้ คุณต้องกำหนดค่าทุกอย่างก่อน และสิ่งที่น่าสนใจมากมายรอคุณอยู่ที่นี่
เมื่อปรับใช้ซอฟต์แวร์เวอร์ชันใหม่ คุณควรพิจารณาตัวเลือกทั้งหมดเพื่อลดความเสี่ยงให้เหลือน้อยที่สุด การเรียกใช้แบบขนานเป็นวิธีการทดสอบที่ทรงพลังและผ่านการพิสูจน์แล้ว และ Istio ช่วยให้คุณใช้ "บริการลับ" (ไมโครเซอร์วิสเวอร์ชันที่ซ่อนอยู่) เพื่อทำสิ่งนี้โดยไม่รบกวนระบบที่ใช้งานจริง มีคำศัพท์พิเศษสำหรับสิ่งนี้ด้วย - "Dark Launch" ซึ่งจะเปิดใช้งานโดยฟังก์ชันที่มีชื่อสายลับว่า "traffic mirroring"
โปรดทราบว่าประโยคแรกของย่อหน้าก่อนหน้านี้ใช้คำว่า "ปรับใช้" มากกว่า "ปล่อย" คุณควรจะปรับใช้และแน่นอนว่าสามารถใช้งานไมโครเซอร์วิสของคุณได้บ่อยเท่าที่คุณต้องการ บริการนี้จะต้องสามารถรับและประมวลผลการรับส่งข้อมูล สร้างผลลัพธ์ และยังเขียนลงในบันทึกและตรวจสอบได้ แต่ในขณะเดียวกัน บริการนี้ก็ไม่จำเป็นต้องเปิดตัวสู่การใช้งานจริง การปรับใช้และการปล่อยซอฟต์แวร์ไม่ใช่เรื่องเดียวกันเสมอไป คุณสามารถปรับใช้ได้ทุกเมื่อที่ต้องการ แต่จะเผยแพร่เมื่อคุณพร้อมเท่านั้น
การจัดระเบียบความเบื่อเป็นเรื่องที่น่าสนใจ
ดูกฎการกำหนดเส้นทาง Istio ต่อไปนี้ ซึ่งกำหนดเส้นทางคำขอ HTTP ทั้งหมดไปยังคำแนะนำไมโครเซอร์วิส v1 (ตัวอย่างทั้งหมดที่นำมาจาก ) ในขณะเดียวกันก็สะท้อนไปยังไมโครเซอร์วิส v2 ที่แนะนำไปพร้อมๆ กัน:
ให้ความสนใจกับฉลาก mirror: ที่ด้านล่างของหน้าจอ - นี่คือการตั้งค่าการมิเรอร์การจราจร ใช่แล้ว มันง่ายมาก!
ผลลัพธ์ของกฎนี้ก็คือระบบที่ใช้งานจริงของคุณ (v1) จะดำเนินการประมวลผลคำขอที่เข้ามาต่อไป แต่คำขอเหล่านั้นจะถูกมิเรอร์แบบอะซิงโครนัสไปยังเวอร์ชัน 2 กล่าวคือ คำขอที่ซ้ำกันทั้งหมดจะไปอยู่ที่นั่น ด้วยวิธีนี้ คุณสามารถทดสอบ v2 ในสภาวะจริง - บนข้อมูลจริงและการรับส่งข้อมูล - โดยไม่รบกวนการทำงานของระบบที่ใช้งานจริงในทางใดทางหนึ่ง สิ่งนี้ทำให้การจัดการทดสอบน่าเบื่อหรือไม่? ใช่อย่างแน่นอน. แต่ก็ทำในลักษณะที่น่าสนใจ
มาเพิ่มดราม่ากัน
โปรดทราบว่าในโค้ด v2 จำเป็นต้องจัดเตรียมไว้สำหรับสถานการณ์ที่คำขอที่เข้ามาอาจนำไปสู่การเปลี่ยนแปลงข้อมูล คำขอนั้นจะถูกสะท้อนกลับได้อย่างง่ายดายและโปร่งใส แต่การเลือกวิธีการประมวลผลในการทดสอบนั้นขึ้นอยู่กับคุณ และนี่เป็นเรื่องที่น่ากังวลเล็กน้อย
เรามาทำซ้ำจุดสำคัญกัน
การเปิดใช้งานแบบลับด้วย Traffic Mirroring (Dark Launch/Request Mirroring) สามารถทำได้โดยไม่กระทบต่อโค้ดแต่อย่างใด
อาหารสมอง
จะเกิดอะไรขึ้นถ้าสถานที่ที่คำขอถูกมิเรอร์ส่งคำขอบางส่วนไม่ใช่ไปที่ v1 แต่ไปที่ v2? ตัวอย่างเช่น หนึ่งเปอร์เซ็นต์ของคำขอทั้งหมดหรือคำขอจากผู้ใช้บางกลุ่มเท่านั้น จากนั้นเมื่อดูวิธีการทำงานของ v2 แล้ว ให้ค่อยๆ โอนคำขอทั้งหมดไปยังเวอร์ชันใหม่ หรือในทางกลับกัน ให้คืนค่าทุกอย่างกลับเป็น v1 หากมีสิ่งผิดปกติเกิดขึ้นกับ v2 ฉันคิดว่ามันเรียกว่า Canary Deployment และหากเป็นแหล่งกำเนิดของรัสเซีย ก็อาจมีการอ้างอิงถึง ) และตอนนี้เราจะดูรายละเอียดเพิ่มเติมนี้
Canary Deployment ใน Istio: ทำให้การว่าจ้างง่ายขึ้น
อย่างระมัดระวังและค่อยๆ
สาระสำคัญของโมเดลการปรับใช้ Canary Deployment นั้นง่ายมาก: เมื่อคุณเปิดตัวซอฟต์แวร์เวอร์ชันใหม่ (ในกรณีของเราคือไมโครเซอร์วิส) คุณจะต้องให้สิทธิ์การเข้าถึงแก่ผู้ใช้กลุ่มเล็กๆ ก่อน หากทุกอย่างเป็นไปด้วยดี คุณจะค่อยๆ เพิ่มกลุ่มนี้จนกว่าเวอร์ชันใหม่จะเริ่มทำงาน หรือหากไม่เป็นเช่นนั้น ให้ย้ายผู้ใช้ทั้งหมดไปยังกลุ่มนั้นในที่สุด ด้วยการเปิดตัวเวอร์ชันใหม่อย่างรอบคอบและค่อยๆ และการเปลี่ยนผู้ใช้ไปใช้ในลักษณะที่มีการควบคุม คุณสามารถลดความเสี่ยงและเพิ่มผลตอบรับได้สูงสุด
แน่นอนว่า Istio ทำให้ Canary Deployment ง่ายขึ้นโดยเสนอตัวเลือกดีๆ มากมายสำหรับการกำหนดเส้นทางคำขออัจฉริยะ ใช่แล้ว ทั้งหมดนี้สามารถทำได้โดยไม่ต้องแตะต้องซอร์สโค้ดของคุณแต่อย่างใด
การกรองเบราว์เซอร์
เกณฑ์การกำหนดเส้นทางที่ง่ายที่สุดประการหนึ่งคือการเปลี่ยนเส้นทางโดยใช้เบราว์เซอร์ สมมติว่าคุณต้องการเฉพาะคำขอจากเบราว์เซอร์ Safari ไปที่เวอร์ชัน 2 ต่อไปนี้เป็นวิธีดำเนินการ:
ลองใช้กฎการกำหนดเส้นทางนี้แล้วใช้คำสั่ง curl เราจะจำลองคำขอจริงไปยังไมโครเซอร์วิสแบบวนซ้ำ อย่างที่คุณเห็นในภาพหน้าจอ ทั้งหมดไปที่ v1:
การจราจรบน v2 อยู่ที่ไหน? เนื่องจากในตัวอย่างของเรา คำขอทั้งหมดมาจากบรรทัดคำสั่งของเราเองเท่านั้น จึงไม่มีอยู่จริง แต่ให้ใส่ใจกับประเด็นสำคัญในหน้าจอด้านบน: นี่เป็นการตอบสนองต่อความจริงที่ว่าเราได้ดำเนินการตามคำขอจากเบราว์เซอร์ Safari ซึ่งทำให้เกิดสิ่งนี้:
พลังไม่จำกัด
เราได้เขียนไปแล้วว่านิพจน์ทั่วไปมีความสามารถที่มีประสิทธิภาพมากสำหรับคำขอการกำหนดเส้นทาง ดูตัวอย่างต่อไปนี้ (เราคิดว่าคุณจะเข้าใจว่ามันทำอะไร):
ถึงตอนนี้คุณคงพอทราบแล้วว่านิพจน์ทั่วไปสามารถทำอะไรได้บ้าง
ทำหน้าที่อย่างชาญฉลาด
การกำหนดเส้นทางอัจฉริยะ โดยเฉพาะอย่างยิ่งการประมวลผลส่วนหัวของแพ็กเก็ตโดยใช้นิพจน์ทั่วไป ช่วยให้คุณสามารถกำหนดทิศทางการรับส่งข้อมูลได้ตามที่คุณต้องการ และสิ่งนี้ทำให้การติดตั้งโค้ดใหม่ง่ายขึ้นอย่างมาก - ง่าย ไม่จำเป็นต้องเปลี่ยนโค้ดเอง และหากจำเป็น ทุกอย่างสามารถส่งคืนได้อย่างรวดเร็วเหมือนเดิม
สนใจ?
คุณอยากทดลองใช้ Istio, Kubernetes และ OpenShift บนคอมพิวเตอร์ของคุณหรือไม่? ทีม เตรียมไว้อย่างดีเยี่ยม ในหัวข้อนี้และเปิดเผยไฟล์ที่แนบมาทั้งหมดต่อสาธารณะ ดังนั้นไปข้างหน้าและอย่าปฏิเสธตัวเองอะไรเลย
Istio Egress: ออกจากร้านขายของที่ระลึก
การใช้ Istio ร่วมกับ Red Hat OpenShift และ Kubernetes จะทำให้ชีวิตของคุณด้วยไมโครเซอร์วิสง่ายขึ้นมาก Service Mesh ของ Istio ถูกซ่อนอยู่ในพ็อด Kubernetes และโค้ดของคุณทำงาน (ส่วนใหญ่) แบบแยกส่วน ประสิทธิภาพ ความง่ายในการเปลี่ยนแปลง การติดตาม ฯลฯ – ทั้งหมดนี้ใช้งานง่ายด้วยการใช้ที่เก็บของในรถเทียมข้างรถจักรยานยนต์ แต่จะเกิดอะไรขึ้นหากไมโครเซอร์วิสของคุณจำเป็นต้องสื่อสารกับบริการอื่นๆ ที่อยู่นอกระบบ OpenShift-Kubernetes ของคุณ?
นี่คือจุดที่ Istio Egress มาช่วยเหลือ โดยสรุป ช่วยให้คุณเข้าถึงทรัพยากร (อ่าน: “บริการ”) ที่ไม่ได้เป็นส่วนหนึ่งของระบบพ็อด Kubernetes ของคุณ หากคุณไม่ได้กำหนดค่าเพิ่มเติม การรับส่งข้อมูลในสภาพแวดล้อม Istio Egress จะถูกกำหนดเส้นทางภายในคลัสเตอร์ของพ็อดและระหว่างคลัสเตอร์ดังกล่าวตามตาราง IP ภายในเท่านั้น และดักแด้นั้นใช้งานได้ดีตราบใดที่คุณไม่จำเป็นต้องเข้าถึงบริการจากภายนอก
Egress ช่วยให้คุณสามารถข้ามตาราง IP ข้างต้นได้ ขึ้นอยู่กับกฎ Egress หรือตามช่วงของที่อยู่ IP
สมมติว่าเรามีโปรแกรม Java ที่สร้างคำขอ GET ไปยัง httpbin.org/headers
(httpbin.org เป็นเพียงแหล่งข้อมูลที่สะดวกสำหรับการทดสอบคำขอบริการขาออก)
หากคุณเข้าสู่บรรทัดคำสั่ง curl http://httpbin.org/headersเราจะเห็นสิ่งต่อไปนี้:
หรือคุณสามารถเปิดที่อยู่เดียวกันในเบราว์เซอร์:
อย่างที่คุณเห็น บริการที่ตั้งอยู่ที่นั่นเพียงส่งคืนส่วนหัวที่ส่งผ่านไป
เรากำลังทดแทนการนำเข้าโดยตรง
ตอนนี้ ลองใช้โค้ด Java ของบริการนี้ที่อยู่ภายนอกระบบของเรา และรันด้วยตัวเราเอง โดยมีการติดตั้ง Istio ไว้ที่ไหน (สามารถติดต่อด้วยตนเองได้ที่ .) เมื่อสร้างอิมเมจที่เหมาะสมและเปิดใช้งานบนแพลตฟอร์ม OpenShift แล้ว เราจะเรียกบริการนี้ด้วยคำสั่ง curl egresshttpbin-istioegress.$(minishift ip).nip.ioหลังจากนั้นเราจะเห็นสิ่งนี้บนหน้าจอ:
อ๊ะ เกิดอะไรขึ้น? ทุกอย่างทำงานได้ ไม่พบหมายถึงอะไร? เราแค่ทำเพื่อเขา curl.
การขยายตาราง IP ไปยังอินเทอร์เน็ตทั้งหมด
Istio ควรถูกตำหนิ (หรือขอบคุณ) สำหรับสิ่งนี้ ท้ายที่สุดแล้ว Istio เป็นเพียงคอนเทนเนอร์พ่วงข้างที่รับผิดชอบในการตรวจจับและกำหนดเส้นทาง (และอีกหลายอย่างที่เราพูดถึงก่อนหน้านี้) ด้วยเหตุนี้ ตาราง IP จึงรู้เฉพาะสิ่งที่อยู่ภายในระบบคลัสเตอร์ของคุณเท่านั้น และ httpbin.org ตั้งอยู่ภายนอกจึงไม่สามารถเข้าถึงได้ และนี่คือจุดที่ Istio Egress เข้ามาช่วยเหลือ โดยไม่ต้องเปลี่ยนแปลงซอร์สโค้ดของคุณแม้แต่น้อย
กฎ Egress ด้านล่างบังคับให้ Istio ค้นหา (หากจำเป็น จากนั้นทั่วทั้งอินเทอร์เน็ต) สำหรับบริการที่จำเป็น ในกรณีนี้คือ httpbin.org ดังที่คุณเห็นจากไฟล์นี้ (egress_httpbin.yml) ฟังก์ชั่นที่นี่ค่อนข้างง่าย:
สิ่งที่เหลืออยู่คือการใช้กฎนี้:
istioctl create -f egress_httpbin.yml -n istioegress
คุณสามารถดูกฎ Egress ได้ด้วยคำสั่ง istioctl get egressrules:
และสุดท้ายเราก็รันคำสั่งอีกครั้ง โค้ง – และเราเห็นว่าทุกอย่างได้ผล:
เราคิดอย่างเปิดเผย
อย่างที่คุณเห็น Istio ช่วยให้คุณสามารถจัดการปฏิสัมพันธ์กับโลกภายนอกได้ กล่าวอีกนัยหนึ่ง คุณยังคงสามารถสร้างบริการ OpenShift และจัดการผ่าน Kubernetes ได้ โดยเก็บทุกอย่างไว้ในพ็อดที่ขยายขนาดขึ้นและลงได้ตามต้องการ และในเวลาเดียวกัน คุณสามารถเข้าถึงบริการภายนอกสภาพแวดล้อมของคุณได้อย่างปลอดภัย ใช่แล้ว เราขอย้ำอีกครั้งว่าทั้งหมดนี้สามารถทำได้โดยไม่ต้องแตะโค้ดของคุณแต่อย่างใด
นี่เป็นโพสต์สุดท้ายของซีรีส์ใน Istio คอยติดตาม - มีสิ่งที่น่าสนใจมากมายรออยู่ข้างหน้า!
ที่มา: will.com