เมื่อเปิดใช้คลัสเตอร์ Kubernetes สำหรับแอปพลิเคชันใดแอปพลิเคชันหนึ่ง คุณต้องเข้าใจว่าตัวแอปพลิเคชันเอง ธุรกิจ และนักพัฒนาเกี่ยวข้องกับทรัพยากรนี้อย่างไร ด้วยข้อมูลนี้ คุณสามารถเริ่มตัดสินใจเกี่ยวกับสถาปัตยกรรม และโดยเฉพาะอย่างยิ่ง การเลือกตัวควบคุม Ingress เฉพาะ ซึ่งในปัจจุบันมีจำนวนมากอยู่แล้ว เพื่อให้ได้แนวคิดพื้นฐานเกี่ยวกับตัวเลือกที่มีอยู่โดยไม่ต้องอ่านบทความ/เอกสารจำนวนมาก ฯลฯ เราได้เตรียมภาพรวมนี้ รวมถึงตัวควบคุม Ingress หลัก (พร้อมสำหรับการผลิต)
เราหวังว่ามันจะช่วยเพื่อนร่วมงานในการเลือกโซลูชันทางสถาปัตยกรรม - อย่างน้อยก็จะกลายเป็นจุดเริ่มต้นสำหรับการรับข้อมูลที่ละเอียดยิ่งขึ้นและการทดลองเชิงปฏิบัติ ก่อนหน้านี้เราศึกษาเนื้อหาที่คล้ายกันอื่น ๆ บนอินเทอร์เน็ตและไม่พบเนื้อหาที่สมบูรณ์มากหรือน้อยเลยและที่สำคัญที่สุดคือการทบทวนโครงสร้าง ดังนั้นเรามาเติมเต็มช่องว่างนั้นกันเถอะ!
เกณฑ์
โดยหลักการแล้ว เพื่อทำการเปรียบเทียบและรับผลลัพธ์ที่เป็นประโยชน์ คุณต้องเข้าใจไม่เพียงแต่สาขาวิชาเท่านั้น แต่ยังมีรายการเกณฑ์เฉพาะที่จะกำหนดเวกเตอร์การวิจัยด้วย โดยไม่แสร้งทำเป็นวิเคราะห์กรณีที่เป็นไปได้ทั้งหมดของการใช้ Ingress / Kubernetes เราพยายามเน้นย้ำถึงข้อกำหนดทั่วไปที่สุดสำหรับคอนโทรลเลอร์ - เตรียมพร้อมว่าในกรณีใด ๆ คุณจะต้องศึกษาข้อมูลเฉพาะและรายละเอียดทั้งหมดของคุณแยกกัน
แต่ฉันจะเริ่มต้นด้วยลักษณะที่คุ้นเคยจนนำไปใช้ในโซลูชันทั้งหมดและไม่ได้รับการพิจารณา:
- การค้นพบบริการแบบไดนามิก (การค้นพบบริการ);
- การยกเลิก SSL;
- ทำงานกับเว็บซ็อกเก็ต
ตอนนี้สำหรับจุดเปรียบเทียบ:
โปรโตคอลที่รองรับ
หนึ่งในเกณฑ์การคัดเลือกขั้นพื้นฐาน ซอฟต์แวร์ของคุณอาจไม่ทำงานบน HTTP มาตรฐาน หรืออาจต้องทำงานกับหลายโปรโตคอลพร้อมกัน หากกรณีของคุณไม่ได้มาตรฐาน โปรดคำนึงถึงปัจจัยนี้ด้วย เพื่อที่คุณจะได้ไม่ต้องกำหนดค่าคลัสเตอร์ใหม่ในภายหลัง สำหรับคอนโทรลเลอร์ทั้งหมด รายการโปรโตคอลที่รองรับจะแตกต่างกันไป
ซอฟต์แวร์ที่เป็นแกนหลัก
มีแอปพลิเคชันหลายรูปแบบที่ใช้ตัวควบคุม ที่นิยมได้แก่ nginx, traefik, haproxy, envoy ในกรณีทั่วไป การรับและส่งข้อมูลอาจไม่มีผลมากนัก แต่การทราบความแตกต่างและคุณลักษณะที่เป็นไปได้ของสิ่งที่ "ซ่อนอยู่" นั้นมีประโยชน์เสมอ
เส้นทางจราจร
บนพื้นฐานของความเป็นไปได้ในการตัดสินใจเกี่ยวกับทิศทางการรับส่งข้อมูลไปยังบริการใดบริการหนึ่งโดยเฉพาะ? โดยปกติจะเป็นโฮสต์และเส้นทาง แต่มีความเป็นไปได้เพิ่มเติม
เนมสเปซภายในคลัสเตอร์
เนมสเปซ (เนมสเปซ) - ความสามารถในการแยกทรัพยากรอย่างมีเหตุผลใน Kubernetes (เช่น บนสเตจ การผลิต ฯลฯ) มีตัวควบคุม Ingress ที่ต้องติดตั้งแยกกันในแต่ละเนมสเปซ (จากนั้นจึงกำหนดเส้นทางการรับส่งข้อมูลได้ เท่านั้น สู่ฝักของช่องว่างนี้) และมีบางส่วน (และส่วนใหญ่ที่ชัดเจน) ที่ทำงานทั่วโลกสำหรับคลัสเตอร์ทั้งหมด - ในนั้นทราฟฟิกจะถูกส่งตรงไปยังพ็อดของคลัสเตอร์ โดยไม่คำนึงถึงเนมสเปซ
ตัวอย่างต้นน้ำ
ทราฟฟิกถูกส่งตรงไปยังอินสแตนซ์ที่ดีของแอปพลิเคชันหรือบริการอย่างไร มีตัวเลือกสำหรับการตรวจสอบแบบแอกทีฟและพาสซีฟ การลองใหม่ เซอร์กิตเบรกเกอร์ (ดูรายละเอียดเพิ่มเติม เช่น )การตรวจสุขภาพที่กำหนดเอง ฯลฯ พารามิเตอร์ที่สำคัญมากหากคุณมีความต้องการสูงสำหรับความพร้อมใช้งานและการลบบริการที่ล้มเหลวออกจากการปรับสมดุลในเวลาที่เหมาะสม
อัลกอริธึมการปรับสมดุล
มีตัวเลือกมากมาย: จากแบบดั้งเดิม สู่ความแปลกใหม่ เช่นเดียวกับคุณสมบัติส่วนบุคคลเช่น .
การรับรอง
คอนโทรลเลอร์รองรับรูปแบบการให้สิทธิ์แบบใด Basic,digest,oauth,external-auth - ฉันคิดว่าตัวเลือกเหล่านี้น่าจะคุ้นเคยกันดี นี่เป็นเกณฑ์ที่สำคัญหากมีลูปสำหรับนักพัฒนา (และ/หรือเฉพาะส่วนตัว) จำนวนมากที่เข้าถึงได้ผ่าน Ingress
การกระจายการจราจร
คอนโทรลเลอร์รองรับกลไกการกระจายทราฟฟิกที่ใช้กันทั่วไป เช่น การเปิดตัวคานารี (คานารี), การทดสอบ A / B, มิเรอร์ทราฟฟิก (การมิเรอร์ / การแชโดว์) หรือไม่ นี่เป็นเรื่องที่น่าปวดหัวอย่างยิ่งสำหรับแอปพลิเคชันที่ต้องการการจัดการทราฟฟิกที่ถูกต้องและแม่นยำสำหรับการทดสอบที่มีประสิทธิผล การแก้ไขจุดบกพร่องของผลิตภัณฑ์แบบออฟไลน์ (หรือมีการสูญเสียน้อยที่สุด) การวิเคราะห์ทราฟฟิก และอื่นๆ
สมัครสมาชิกแบบชำระเงิน
มีตัวเลือกการชำระเงินสำหรับคอนโทรลเลอร์พร้อมฟังก์ชันเพิ่มเติมและ / หรือการสนับสนุนทางเทคนิคหรือไม่?
ส่วนติดต่อผู้ใช้แบบกราฟิก (Web UI)
มี GUI สำหรับจัดการการกำหนดค่าคอนโทรลเลอร์หรือไม่? ส่วนใหญ่สำหรับ "ความสะดวก" และ / หรือสำหรับผู้ที่ต้องการเปลี่ยนแปลงการกำหนดค่า Ingress'a แต่การทำงานกับเทมเพลต "ดิบ" นั้นไม่สะดวก อาจมีประโยชน์หากนักพัฒนาซอฟต์แวร์ต้องการทำการทดลองกับทราฟฟิกในทันที
การตรวจสอบ JWT
การมีอยู่ของการตรวจสอบความถูกต้องในตัวของโทเค็นเว็บ JSON สำหรับการอนุญาตและการตรวจสอบความถูกต้องของผู้ใช้ไปยังแอปพลิเคชันปลายทาง
ความเป็นไปได้ในการปรับแต่งคอนฟิก
ความสามารถในการขยายเทมเพลตในแง่ของการมีกลไกที่ช่วยให้คุณเพิ่มคำสั่ง แฟล็ก ฯลฯ ของคุณเองไปยังเทมเพลตการกำหนดค่ามาตรฐาน
กลไกการป้องกัน DDOS พื้นฐาน
อัลกอริทึมการจำกัดอัตราอย่างง่ายหรือตัวเลือกการกรองทราฟฟิกที่ซับซ้อนมากขึ้นตามที่อยู่ รายการที่อนุญาต ประเทศ ฯลฯ
ขอติดตาม
ความสามารถในการตรวจสอบ ติดตาม และดีบักคำขอจาก Ingresses ไปยังบริการ / พ็อดเฉพาะ และระหว่างบริการ / พ็อดด้วยเช่นกัน
WAF
สนับสนุน .
ตัวควบคุม
รายการตัวควบคุมถูกสร้างขึ้นตาม и . เราแยกบางส่วนออกจากการตรวจสอบเนื่องจากความเฉพาะเจาะจงหรือความชุกต่ำ (ช่วงเริ่มต้นของการพัฒนา) ส่วนที่เหลือจะกล่าวถึงด้านล่าง เริ่มจากคำอธิบายทั่วไปของโซลูชันและดำเนินการต่อด้วยตารางสรุป
ขาเข้าจาก Kubernetes
เว็บไซต์:
ใบอนุญาต: Apache 2.0
นี่คือตัวควบคุมอย่างเป็นทางการสำหรับ Kubernetes และกำลังพัฒนาโดยชุมชน เห็นได้ชัดว่าจากชื่อ มันขึ้นอยู่กับ nginx และเสริมด้วยชุดปลั๊กอิน Lua ที่แตกต่างกันซึ่งใช้เพื่อใช้งานคุณสมบัติเพิ่มเติม เนื่องจากความนิยมของ nginx เองและการดัดแปลงเพียงเล็กน้อยเมื่อใช้เป็นตัวควบคุม ตัวเลือกนี้อาจเป็นวิธีที่ง่ายที่สุดและง่ายที่สุดในการกำหนดค่าสำหรับวิศวกรทั่วไป (ที่มีประสบการณ์บนเว็บ)
ทางเข้าโดย NGINX Inc.
เว็บไซต์:
ใบอนุญาต: Apache 2.0
ผลิตภัณฑ์อย่างเป็นทางการของผู้พัฒนา nginx มีเวอร์ชันที่ต้องชำระเงินตาม . แนวคิดหลักคือความเสถียรในระดับสูง ความเข้ากันได้แบบย้อนกลับคงที่ การไม่มีโมดูลภายนอกใดๆ และความเร็วที่เพิ่มขึ้นที่ประกาศไว้ (เมื่อเทียบกับตัวควบคุมอย่างเป็นทางการ) ซึ่งทำได้เนื่องจากการปฏิเสธของ Lua
รุ่นฟรีจะลดลงอย่างมากรวมถึงแม้ว่าจะเปรียบเทียบกับตัวควบคุมอย่างเป็นทางการ (เนื่องจากไม่มีโมดูล Lua เดียวกัน) ในขณะเดียวกัน แบบชำระเงินมีฟังก์ชันเพิ่มเติมที่ค่อนข้างกว้าง: ตัววัดตามเวลาจริง การตรวจสอบความถูกต้องของ JWT การตรวจสุขภาพที่ใช้งาน และอื่นๆ ข้อได้เปรียบที่สำคัญเหนือ NGINX Ingress คือการสนับสนุนการรับส่งข้อมูล TCP / UDP อย่างเต็มรูปแบบ (และในเวอร์ชันชุมชนด้วย!) ลบ - คุณลักษณะการกระจายการรับส่งข้อมูล ซึ่ง "มีความสำคัญสูงสุดสำหรับนักพัฒนา" แต่ต้องใช้เวลาในการดำเนินการ
ก้อง อินเกรส
เว็บไซต์:
ใบอนุญาต: Apache 2.0
ผลิตภัณฑ์ที่พัฒนาโดย Kong Inc. ในสองเวอร์ชัน: เชิงพาณิชย์และฟรี ขึ้นอยู่กับ nginx ซึ่งได้รับการขยายด้วยโมดูล Lua จำนวนมาก
ในขั้นต้น มุ่งเน้นไปที่การประมวลผลและกำหนดเส้นทางคำขอ API เช่น เป็นเกตเวย์ API แต่ในขณะนี้ได้กลายเป็นตัวควบคุม Ingress เต็มเปี่ยม ข้อได้เปรียบหลัก: โมดูลเพิ่มเติมจำนวนมาก (รวมถึงโมดูลจากนักพัฒนาบุคคลที่สาม) ที่ติดตั้งและกำหนดค่าได้ง่าย และด้วยความช่วยเหลือของคุณสมบัติเพิ่มเติมที่หลากหลาย อย่างไรก็ตาม ฟังก์ชันในตัวมีความเป็นไปได้มากมายอยู่แล้ว การกำหนดค่างานเสร็จสิ้นโดยใช้ทรัพยากร CRD
คุณสมบัติที่สำคัญของผลิตภัณฑ์ - การทำงานภายในรูปร่างเดียวกัน (แทนที่จะข้ามเนมสเปซ) เป็นหัวข้อที่ถกเถียงกัน: สำหรับบางคนดูเหมือนว่าจะเป็นข้อเสีย (คุณต้องสร้างเอนทิตีสำหรับแต่ละรูปร่าง) และสำหรับบางคน มันเป็นคุณสมบัติ ( ขоระดับความโดดเดี่ยวที่มากขึ้น เช่น ถ้าคอนโทรลเลอร์เสีย ปัญหาก็จำกัดเฉพาะวงจรเท่านั้น)
เทรฟิค
เว็บไซต์:
ใบอนุญาต: MIT
พร็อกซีที่สร้างขึ้นเพื่อทำงานร่วมกับคำขอกำหนดเส้นทางสำหรับไมโครเซอร์วิสและสภาพแวดล้อมแบบไดนามิก ดังนั้น คุณสมบัติที่มีประโยชน์มากมาย: การอัปเดตการกำหนดค่าโดยไม่ต้องรีบูตเครื่องเลย, รองรับวิธีการปรับสมดุลจำนวนมาก, เว็บอินเตอร์เฟส, การส่งต่อเมตริก, รองรับโปรโตคอลต่างๆ, REST API, canary releases และอื่นๆ อีกมากมาย คุณสมบัติที่ดีอีกอย่างคือรองรับ Let's Encrypt ใบรับรองได้ทันที ข้อเสียคือเพื่อจัดระเบียบความพร้อมใช้งานสูง (HA) คอนโทรลเลอร์จะต้องติดตั้งและเชื่อมต่อที่เก็บข้อมูล KV ของตัวเอง
HAProxy
เว็บไซต์:
ใบอนุญาต: Apache 2.0
HAProxy เป็นที่รู้จักกันมานานแล้วว่าเป็นพร็อกซีและทราฟฟิกบาลานเซอร์ ในฐานะที่เป็นส่วนหนึ่งของคลัสเตอร์ Kubernetes จึงมีการอัปเดตการกำหนดค่า "แบบนุ่มนวล" (โดยไม่สูญเสียการรับส่งข้อมูล) การค้นหาบริการตาม DNS การกำหนดค่าแบบไดนามิกโดยใช้ API การปรับแต่งเทมเพลตการกำหนดค่าอย่างสมบูรณ์โดยการแทนที่ CM รวมถึงความสามารถในการใช้ฟังก์ชันไลบรารี Sprig นั้นน่าสนใจ โดยทั่วไป ความสำคัญหลักของโซลูชันอยู่ที่ความเร็วสูง การเพิ่มประสิทธิภาพและประสิทธิภาพของทรัพยากรที่ใช้ไป ข้อได้เปรียบของคอนโทรลเลอร์คือการรองรับหมายเลขบันทึกของวิธีการปรับสมดุลที่แตกต่างกัน
ผู้เดินทาง
เว็บไซต์:
ใบอนุญาต: Apache 2.0
อิงตามตัวควบคุม HAproxy ซึ่งวางตำแหน่งเป็นโซลูชันสากลที่รองรับคุณสมบัติที่หลากหลายจากผู้ให้บริการจำนวนมาก มีการเสนอโอกาสในการสร้างสมดุลทราฟฟิกบน L7 และ L4 และการปรับสมดุลทราฟฟิก TCP L4 โดยรวมสามารถเรียกได้ว่าเป็นหนึ่งในคุณสมบัติหลักของโซลูชัน
เส้นแสดงรูปร่าง
เว็บไซต์:
ใบอนุญาต: Apache 2.0
โซลูชันนี้ไม่ได้ขึ้นอยู่กับ Envoy เท่านั้น แต่ยังได้รับการพัฒนาโดย ร่วมกัน กับผู้เขียนหนังสือมอบฉันทะยอดนิยมนี้ คุณสมบัติที่สำคัญคือความสามารถในการแยกการควบคุมทรัพยากร Ingress โดยใช้ทรัพยากร IngressRoute CRD สำหรับองค์กรที่มีทีมพัฒนาจำนวนมากที่ใช้คลัสเตอร์เดียวกัน สิ่งนี้จะช่วยเพิ่มความปลอดภัยสูงสุดในการทำงานกับการรับส่งข้อมูลในลูปข้างเคียง และป้องกันข้อผิดพลาดเมื่อเปลี่ยนทรัพยากร Ingress
นอกจากนี้ยังมีชุดวิธีการสร้างสมดุลเพิ่มเติม (มีการทำมิเรอร์คำขอ การทำซ้ำอัตโนมัติ การจำกัดอัตราคำขอ และอื่นๆ อีกมากมาย) การตรวจสอบโดยละเอียดของโฟลว์การรับส่งข้อมูลและความล้มเหลว บางทีสำหรับบางคน การขาดการสนับสนุนสำหรับเซสชันที่เหนียวแน่นอาจเป็นข้อเสียเปรียบอย่างมาก (แม้ว่าจะเป็นงาน ).
ทางเข้า Istio
เว็บไซต์:
ใบอนุญาต: Apache 2.0
โซลูชันตาข่ายบริการที่ครอบคลุมซึ่งไม่เพียงแต่เป็นตัวควบคุม Ingress ที่จัดการทราฟฟิกขาเข้าจากภายนอกเท่านั้น แต่ยังควบคุมทราฟฟิกทั้งหมดภายในคลัสเตอร์ด้วย ภายใต้ประทุน Envoy ใช้เป็นพร็อกซีรถช่วยเหลือสำหรับแต่ละบริการ โดยพื้นฐานแล้ว นี่คือการรวมกันขนาดใหญ่ที่ "สามารถทำได้ทุกอย่าง" และแนวคิดหลักคือความสามารถในการจัดการสูงสุด ความสามารถในการขยาย ความปลอดภัย และความโปร่งใส ด้วยเครื่องมือนี้ คุณสามารถปรับแต่งการกำหนดเส้นทางการรับส่งข้อมูล การเข้าถึงการอนุญาตระหว่างบริการ ปรับสมดุล ตรวจสอบ เผยแพร่ Canary และอื่นๆ อีกมากมาย อ่านเพิ่มเติมเกี่ยวกับ Istio ในบทความชุด "'
เอกอัครราชทูต
เว็บไซต์:
ใบอนุญาต: Apache 2.0
อีกวิธีหนึ่งขึ้นอยู่กับทูต มีเวอร์ชันฟรีและเชิงพาณิชย์ ซึ่งอยู่ในตำแหน่ง "โดยสมบูรณ์สำหรับ Kubernetes" ซึ่งนำมาซึ่งข้อได้เปรียบที่สอดคล้องกัน (การรวมอย่างแน่นแฟ้นกับเมธอดและเอนทิตีของคลัสเตอร์ K8s)
ตารางเปรียบเทียบ
ดังนั้นจุดสุดยอดของบทความนี้คือตารางขนาดใหญ่นี้:
สามารถคลิกได้เพื่อดูใกล้ขึ้น และยังมีในรูปแบบ .
เพื่อสรุป
จุดประสงค์ของบทความนี้คือเพื่อให้ความเข้าใจที่สมบูรณ์ยิ่งขึ้น (แต่ไม่ได้ครอบคลุมทั้งหมด!) ของทางเลือกใดในกรณีเฉพาะของคุณ ตามปกติแล้ว คอนโทรลเลอร์แต่ละตัวมีข้อดีและข้อเสียในตัวเอง...
Ingress แบบคลาสสิกจาก Kubernetes นั้นดีสำหรับความพร้อมใช้งานและการพิสูจน์ มีฟีเจอร์มากมายเพียงพอ - ในกรณีทั่วไป มันควรจะ "เพียงพอสำหรับสายตา" อย่างไรก็ตาม หากมีข้อกำหนดที่เพิ่มขึ้นสำหรับความเสถียร ระดับของคุณสมบัติและการพัฒนา คุณควรให้ความสนใจกับ Ingress with NGINX Plus และการสมัครสมาชิกแบบชำระเงิน Kong มีชุดปลั๊กอินที่สมบูรณ์ที่สุด (และตามโอกาสที่พวกเขามีให้) และในเวอร์ชันที่ต้องชำระเงินมีปลั๊กอินมากกว่านั้น มีโอกาสมากมายในการทำงานเป็นเกตเวย์ API การกำหนดค่าแบบไดนามิกตามทรัพยากร CRD ตลอดจนบริการ Kubernetes พื้นฐาน
ด้วยข้อกำหนดที่เพิ่มขึ้นสำหรับวิธีการสร้างสมดุลและการอนุญาต โปรดดูที่ Traefik และ HAProxy โครงการเหล่านี้เป็นโครงการโอเพ่นซอร์สที่ได้รับการพิสูจน์แล้วในช่วงหลายปีที่ผ่านมา มีความเสถียรและพัฒนาอย่างแข็งขัน Contour ออกมาสองสามปีแล้ว แต่ก็ยังดูเด็กเกินไปและมีเพียงคุณสมบัติพื้นฐานที่เพิ่มเข้ามานอกเหนือจาก Envoy หากมีข้อกำหนดสำหรับการมี / การฝัง WAF ไว้ด้านหน้าแอปพลิเคชัน คุณควรให้ความสนใจกับ Ingress เดียวกันจาก Kubernetes หรือ HAProxy
และคุณสมบัติที่สมบูรณ์ที่สุดก็คือผลิตภัณฑ์ที่สร้างขึ้นจาก Envoy โดยเฉพาะ Istio ดูเหมือนว่าจะเป็นโซลูชันที่ครอบคลุมซึ่ง "สามารถทำได้ทุกอย่าง" ซึ่งหมายถึงเกณฑ์รายการที่สูงกว่าอย่างมากสำหรับการกำหนดค่า / การเปิดใช้ / การดูแลระบบมากกว่าโซลูชันอื่นๆ
เราเลือกและยังคงใช้ Ingress จาก Kubernetes เป็นตัวควบคุมมาตรฐาน ซึ่งครอบคลุม 80-90% ของความต้องการ มีความน่าเชื่อถือ กำหนดค่าและขยายได้ง่าย โดยทั่วไป หากไม่มีข้อกำหนดเฉพาะ ควรเหมาะกับคลัสเตอร์/แอปพลิเคชันส่วนใหญ่ จากผลิตภัณฑ์ที่เป็นสากลและค่อนข้างเรียบง่ายเหมือนกัน เราขอแนะนำ Traefik และ HAProxy
PS
อ่านเพิ่มเติมในบล็อกของเรา:
- "กลับสู่ไมโครเซอร์วิสด้วย Istio": , , ;
- «";
- «'
ที่มา: will.com