เฮ้ ฮับ!
เราขอเตือนคุณว่าเราได้เปิดตัวอีกรายการที่น่าสนใจและมีประโยชน์อย่างยิ่ง เกี่ยวกับรูปแบบ Kubernetes ทุกอย่างเริ่มต้นจาก "" Brendan Burns และอีกอย่าง เรามีงานในส่วนนี้ . วันนี้เราขอเชิญคุณอ่านบทความจากบล็อก MiniIO ที่จะสรุปแนวโน้มและข้อมูลเฉพาะของรูปแบบการจัดเก็บข้อมูลใน Kubernetes โดยย่อ
Kubernetes ได้เปลี่ยนแปลงพื้นฐานการพัฒนาแอปพลิเคชันแบบดั้งเดิมและรูปแบบการใช้งาน ขณะนี้ทีมสามารถพัฒนา ทดสอบ และปรับใช้แอปพลิเคชันได้ในเวลาไม่กี่วัน ข้ามสภาพแวดล้อมที่หลากหลาย ทั้งหมดนี้อยู่ภายในคลัสเตอร์ Kubernetes การทำงานร่วมกับเทคโนโลยีรุ่นก่อนๆ ดังกล่าวมักใช้เวลาหลายสัปดาห์หรือหลายเดือน
การเร่งความเร็วนี้เกิดขึ้นได้จากนามธรรมที่ Kubernetes มอบให้ กล่าวคือ เนื่องจาก Kubernetes เองโต้ตอบกับรายละเอียดระดับต่ำของเครื่องจริงหรือเสมือน ทำให้ผู้ใช้สามารถประกาศโปรเซสเซอร์ที่ต้องการ จำนวนหน่วยความจำที่ต้องการ และจำนวนคอนเทนเนอร์ อินสแตนซ์ รวมถึงพารามิเตอร์อื่นๆ ด้วยชุมชนขนาดใหญ่ที่สนับสนุน Kubernetes และการใช้งานที่ขยายตัวอย่างต่อเนื่อง Kubernetes จึงเป็นผู้นำในบรรดาแพลตฟอร์มการจัดการคอนเทนเนอร์ทั้งหมดด้วยอัตรากำไรที่กว้าง
เมื่อการใช้งาน Kubernetes เพิ่มมากขึ้น ความสับสนเกี่ยวกับรูปแบบการจัดเก็บข้อมูลก็เพิ่มขึ้นเช่นกัน.
เมื่อทุกคนแข่งขันกันเพื่อแย่งชิงชิ้นส่วนของพาย Kubernetes (เช่น การจัดเก็บข้อมูล) เมื่อพูดถึงเรื่องการจัดเก็บข้อมูล สัญญาณจะจมอยู่ในเสียงรบกวนจำนวนมาก
Kubernetes รวบรวมโมเดลสมัยใหม่สำหรับการพัฒนา การใช้งาน และการจัดการแอปพลิเคชัน โมเดลที่ทันสมัยนี้จะแยกการจัดเก็บข้อมูลออกจากการคำนวณ เพื่อให้เข้าใจการแยกส่วนในบริบทของ Kubernetes อย่างถ่องแท้ คุณยังต้องเข้าใจด้วยว่าแอปพลิเคชันแบบมีสถานะและไร้สถานะคืออะไร และที่จัดเก็บข้อมูลเหมาะสมกับสิ่งนั้นอย่างไร นี่คือจุดที่แนวทาง REST API ที่ใช้โดย S3 มีข้อได้เปรียบเหนือแนวทาง POSIX/CSI ของโซลูชันอื่นๆ อย่างชัดเจน
ในบทความนี้ เราจะพูดถึงรูปแบบการจัดเก็บข้อมูลใน Kubernetes และกล่าวถึงข้อถกเถียงระหว่างแอปพลิเคชันแบบเก็บสถานะและไร้สถานะโดยเฉพาะ เพื่อให้เข้าใจได้ดีขึ้นว่าแอปพลิเคชันเหล่านี้คืออะไร และเหตุใดจึงมีความสำคัญ ข้อความที่เหลือจะพิจารณาแอปพลิเคชันและรูปแบบการจัดเก็บข้อมูลโดยคำนึงถึงแนวทางปฏิบัติที่ดีที่สุดสำหรับการทำงานกับคอนเทนเนอร์และ Kubernetes
คอนเทนเนอร์ไร้สัญชาติ
โดยธรรมชาติแล้วตู้คอนเทนเนอร์มีน้ำหนักเบาและอยู่เพียงชั่วคราว สามารถหยุด ลบ หรือปรับใช้กับโหนดอื่นได้อย่างง่ายดาย ทั้งหมดนี้ทำได้ภายในไม่กี่วินาที ในระบบการจัดการคอนเทนเนอร์ขนาดใหญ่ การดำเนินการดังกล่าวเกิดขึ้นตลอดเวลา และผู้ใช้ไม่สังเกตเห็นการเปลี่ยนแปลงดังกล่าวด้วยซ้ำ อย่างไรก็ตาม การย้ายจะเป็นไปได้ก็ต่อเมื่อคอนเทนเนอร์ไม่มีการขึ้นต่อกันใดๆ บนโหนดที่คอนเทนเนอร์นั้นตั้งอยู่ ว่ากันว่าภาชนะดังกล่าวใช้งานได้ ไร้สัญชาติ.
คอนเทนเนอร์แบบมีสถานะ
หากคอนเทนเนอร์จัดเก็บข้อมูลบนอุปกรณ์ที่เชื่อมต่อภายในเครื่อง (หรือบนอุปกรณ์บล็อก) ที่เก็บข้อมูลที่เก็บข้อมูลนั้นจะต้องถูกย้ายไปยังโหนดใหม่พร้อมกับตัวคอนเทนเนอร์เอง ในกรณีที่เกิดความล้มเหลว นี่เป็นสิ่งสำคัญเนื่องจากไม่เช่นนั้นแอปพลิเคชันที่ทำงานในคอนเทนเนอร์จะไม่สามารถทำงานได้อย่างถูกต้องเนื่องจากจำเป็นต้องเข้าถึงข้อมูลที่จัดเก็บไว้ในสื่อท้องถิ่น ว่ากันว่าภาชนะดังกล่าวใช้งานได้ มีสถานะ.
จากมุมมองทางเทคนิคล้วนๆ คอนเทนเนอร์ stateful สามารถย้ายไปยังโหนดอื่นได้ โดยทั่วไปจะทำได้โดยใช้ระบบไฟล์แบบกระจายหรือบล็อกที่เก็บข้อมูลเครือข่ายที่แนบกับโหนดทั้งหมดที่ใช้งานคอนเทนเนอร์ ด้วยวิธีนี้ คอนเทนเนอร์จะเข้าถึงไดรฟ์ข้อมูลสำหรับการจัดเก็บข้อมูลถาวร และข้อมูลจะถูกจัดเก็บไว้ในดิสก์ที่อยู่ทั่วทั้งเครือข่าย ฉันจะเรียกวิธีนี้ว่า”วิธีคอนเทนเนอร์แบบ stateful"และในบทความที่เหลือฉันจะเรียกมันว่าเพื่อความสม่ำเสมอ
ในแนวทางคอนเทนเนอร์เก็บสถานะโดยทั่วไป พ็อดแอปพลิเคชันทั้งหมดจะแนบไปกับระบบไฟล์แบบกระจายเดียว ซึ่งเป็นพื้นที่จัดเก็บข้อมูลที่ใช้ร่วมกันซึ่งมีข้อมูลแอปพลิเคชันทั้งหมดอยู่ แม้ว่าการเปลี่ยนแปลงบางอย่างจะเป็นไปได้ แต่นี่เป็นแนวทางระดับสูง
ตอนนี้เรามาดูกันว่าเหตุใดแนวทางคอนเทนเนอร์แบบมีสถานะจึงเป็นรูปแบบที่ต่อต้านในโลกที่มีระบบคลาวด์เป็นศูนย์กลาง
การออกแบบแอปพลิเคชันแบบคลาวด์เนทีฟ
ตามเนื้อผ้า แอปพลิเคชันใช้ฐานข้อมูลสำหรับการจัดเก็บข้อมูลที่มีโครงสร้างและดิสก์ในเครื่องหรือระบบไฟล์แบบกระจาย โดยที่ข้อมูลที่ไม่มีโครงสร้างหรือกึ่งโครงสร้างทั้งหมดถูกทิ้ง เมื่อปริมาณข้อมูลที่ไม่มีโครงสร้างเพิ่มขึ้น นักพัฒนาก็ตระหนักว่า POSIX พูดมากเกินไป มีค่าใช้จ่ายจำนวนมาก และขัดขวางประสิทธิภาพของแอปพลิเคชันในท้ายที่สุดเมื่อเปลี่ยนไปใช้สเกลขนาดใหญ่อย่างแท้จริง
สิ่งนี้มีส่วนทำให้เกิดการเกิดขึ้นของมาตรฐานใหม่สำหรับการจัดเก็บข้อมูล กล่าวคือ การจัดเก็บข้อมูลบนคลาวด์ ซึ่งทำงานบน REST API เป็นหลัก และทำให้แอปพลิเคชันไม่ต้องมีภาระในการบำรุงรักษาที่จัดเก็บข้อมูลในตัวเครื่อง ในกรณีนี้ แอปพลิเคชันจะเข้าสู่โหมดไร้สถานะอย่างมีประสิทธิภาพ (เนื่องจากสถานะอยู่ในที่เก็บข้อมูลระยะไกล) แอปพลิเคชันสมัยใหม่ถูกสร้างขึ้นตั้งแต่ต้นโดยคำนึงถึงปัจจัยนี้ ตามกฎแล้ว แอปพลิเคชันสมัยใหม่ใดๆ ที่ประมวลผลข้อมูลประเภทใดประเภทหนึ่ง (บันทึก ข้อมูลเมตา blobs ฯลฯ) จะถูกสร้างขึ้นตามกระบวนทัศน์ที่เน้นระบบคลาวด์ โดยที่สถานะจะถูกถ่ายโอนไปยังระบบซอฟต์แวร์ที่ออกแบบมาเพื่อการจัดเก็บข้อมูลโดยเฉพาะ
วิธี stateful คอนเทนเนอร์บังคับให้กระบวนทัศน์ทั้งหมดนี้กลับมาตรงจุดเริ่มต้น!
ด้วยการใช้อินเทอร์เฟซ POSIX เพื่อจัดเก็บข้อมูล แอปพลิเคชันจะทำงานเสมือนมีสถานะ และด้วยเหตุนี้ แอปพลิเคชันจึงออกจากหลักการที่สำคัญที่สุดของการออกแบบที่เน้นระบบคลาวด์เป็นหลัก นั่นคือความสามารถในการเปลี่ยนขนาดของเธรดตัวทำงานของแอปพลิเคชันโดยขึ้นอยู่กับขาเข้า อินพุต โหลด ย้ายไปยังโหนดใหม่ทันทีที่โหนดปัจจุบันล้มเหลว และอื่นๆ
เมื่อพิจารณาสถานการณ์นี้โดยละเอียดยิ่งขึ้น เราพบว่าเมื่อเลือกที่เก็บข้อมูล เราต้องเผชิญกับปัญหา POSIX และ REST API ครั้งแล้วครั้งเล่า แต่ด้วยปัญหา POSIX ที่ทำให้รุนแรงขึ้นเพิ่มเติมเนื่องจากลักษณะการกระจายของสภาพแวดล้อม Kubernetes โดยเฉพาะอย่างยิ่ง,
- POSIX กำลังช่างพูด: ซีแมนทิกส์ POSIX กำหนดให้แต่ละการดำเนินการเชื่อมโยงกับข้อมูลเมตาและตัวอธิบายไฟล์ที่ช่วยรักษาสถานะของการดำเนินการ ส่งผลให้เกิดต้นทุนที่สำคัญซึ่งไม่มีมูลค่าที่แท้จริง API พื้นที่จัดเก็บออบเจ็กต์ โดยเฉพาะ S3 API จะกำจัดข้อกำหนดเหล่านี้ ส่งผลให้แอปพลิเคชันเริ่มทำงานแล้ว “ลืม” เกี่ยวกับการโทร การตอบสนองของระบบจัดเก็บข้อมูลจะระบุว่าการดำเนินการสำเร็จหรือไม่ หากล้มเหลว แอปพลิเคชันสามารถลองอีกครั้งได้
- ข้อ จำกัด ของเครือข่าย: ในระบบแบบกระจาย แสดงเป็นนัยว่าอาจมีแอปพลิเคชันจำนวนมากพยายามเขียนข้อมูลลงในสื่อที่แนบเดียวกัน ดังนั้น ไม่เพียงแต่แอปพลิเคชันจะแข่งขันกันเพื่อแบนด์วิธการถ่ายโอนข้อมูล (เพื่อส่งข้อมูลไปยังสื่อ) แต่ระบบจัดเก็บข้อมูลจะแข่งขันกันเพื่อแบนด์วิดท์นี้โดยการส่งข้อมูลผ่านฟิสิคัลดิสก์ เนื่องจากความคล่องแคล่วของ POSIX จำนวนการโทรผ่านเครือข่ายจึงเพิ่มขึ้นหลายครั้ง ในทางกลับกัน S3 API ให้ความแตกต่างที่ชัดเจนระหว่างการโทรผ่านเครือข่ายระหว่างการโทรที่มาจากไคลเอนต์ไปยังเซิร์ฟเวอร์และการโทรที่เกิดขึ้นภายในเซิร์ฟเวอร์
- ความปลอดภัย: โมเดลความปลอดภัย POSIX ได้รับการออกแบบมาเพื่อการมีส่วนร่วมของมนุษย์: ผู้ดูแลระบบกำหนดค่าระดับการเข้าถึงเฉพาะสำหรับผู้ใช้แต่ละรายหรือกลุ่ม กระบวนทัศน์นี้เป็นเรื่องยากที่จะปรับให้เข้ากับโลกที่มีระบบคลาวด์เป็นศูนย์กลาง แอปพลิเคชันสมัยใหม่ขึ้นอยู่กับโมเดลความปลอดภัยที่ใช้ API โดยที่สิทธิ์การเข้าถึงถูกกำหนดเป็นชุดของนโยบาย บัญชีบริการ ข้อมูลรับรองชั่วคราว ฯลฯ ที่ได้รับการจัดสรร
- ควบคุม: stateful คอนเทนเนอร์มีค่าใช้จ่ายในการจัดการบางส่วน เรากำลังพูดถึงการซิงโครไนซ์การเข้าถึงข้อมูลแบบขนาน เพื่อให้มั่นใจว่าข้อมูลมีความสอดคล้องกัน ทั้งหมดนี้ต้องมีการพิจารณาอย่างรอบคอบว่าจะใช้รูปแบบการเข้าถึงข้อมูลแบบใด ต้องติดตั้ง ตรวจสอบ และกำหนดค่าซอฟต์แวร์เพิ่มเติม ไม่ต้องพูดถึงความพยายามในการพัฒนาเพิ่มเติม
อินเทอร์เฟซการจัดเก็บข้อมูลคอนเทนเนอร์
แม้ว่า Container Storage Interface (CSI) จะช่วยได้มากในการเพิ่มจำนวนชั้นวอลุ่มของ Kubernetes โดยจ้างบางส่วนจากผู้จำหน่ายพื้นที่จัดเก็บข้อมูลบุคคลที่สาม แต่ก็ยังมีส่วนทำให้เชื่อว่าแนวทางคอนเทนเนอร์แบบเก็บสถานะเป็นวิธีที่แนะนำโดยไม่ได้ตั้งใจสำหรับ การจัดเก็บข้อมูลใน Kubernetes
CSI ได้รับการพัฒนาให้เป็นมาตรฐานสำหรับการจัดหาระบบบล็อกและการจัดเก็บไฟล์ตามอำเภอใจให้กับแอปพลิเคชันรุ่นเก่าเมื่อทำงานบน Kubernetes และดังที่บทความนี้ได้แสดงให้เห็นแล้ว สถานการณ์เดียวที่แนวทาง stateful คอนเทนเนอร์ (และ CSI ในรูปแบบปัจจุบัน) เหมาะสมคือเมื่อตัวแอปพลิเคชันเองเป็นระบบเดิมซึ่งไม่สามารถเพิ่มการรองรับสำหรับ API ที่เก็บอ็อบเจ็กต์ได้ .
สิ่งสำคัญคือต้องเข้าใจว่าการใช้ CSI ในรูปแบบปัจจุบันนั่นคือการเพิ่มปริมาณเมื่อทำงานกับแอปพลิเคชันสมัยใหม่ เราจะพบปัญหาเดียวกันโดยประมาณที่เกิดขึ้นในระบบที่จัดเก็บข้อมูลถูกจัดระเบียบในรูปแบบ POSIX
แนวทางที่ดีกว่า
ในกรณีนี้ สิ่งสำคัญคือต้องเข้าใจว่าแอปพลิเคชันส่วนใหญ่ไม่ได้ได้รับการออกแบบมาโดยเฉพาะสำหรับงานที่มีสถานะหรือไร้สัญชาติ ลักษณะการทำงานนี้ขึ้นอยู่กับสถาปัตยกรรมระบบโดยรวมและตัวเลือกการออกแบบเฉพาะที่ทำขึ้น มาพูดถึงแอปพลิเคชัน stateful กันสักหน่อย
โดยหลักการแล้ว ข้อมูลการใช้งานทั้งหมดสามารถแบ่งออกเป็นประเภทกว้างๆ ได้หลายประเภท:
- บันทึกข้อมูล
- ข้อมูลการประทับเวลา
- ข้อมูลธุรกรรม
- ข้อมูลเมตา
- รูปภาพคอนเทนเนอร์
- ข้อมูล Blob (วัตถุไบนารีขนาดใหญ่)
ประเภทข้อมูลทั้งหมดนี้ได้รับการสนับสนุนเป็นอย่างดีบนแพลตฟอร์มการจัดเก็บข้อมูลที่ทันสมัย และมีแพลตฟอร์มแบบคลาวด์เนทีฟหลายแพลตฟอร์มที่ได้รับการปรับแต่งเพื่อส่งข้อมูลในแต่ละรูปแบบเฉพาะเหล่านี้ ตัวอย่างเช่น ข้อมูลธุรกรรมและข้อมูลเมตาอาจอยู่ในฐานข้อมูลบนคลาวด์สมัยใหม่ เช่น CockroachDB, YugaByte เป็นต้น อิมเมจคอนเทนเนอร์หรือข้อมูลหยดสามารถจัดเก็บไว้ในรีจิสทรีนักเทียบท่าตาม MiniIO ข้อมูลการประทับเวลาสามารถจัดเก็บไว้ในฐานข้อมูลอนุกรมเวลา เช่น InfluxDB เป็นต้น เราจะไม่ลงรายละเอียดเกี่ยวกับข้อมูลแต่ละประเภทและแอปพลิเคชันในที่นี้ แต่แนวคิดทั่วไปคือการหลีกเลี่ยงการจัดเก็บข้อมูลถาวรที่ต้องอาศัยการติดตั้งดิสก์ในเครื่อง
นอกจากนี้ มักจะมีประสิทธิภาพในการจัดหาเลเยอร์แคชชั่วคราวที่ทำหน้าที่เป็นที่เก็บไฟล์ชั่วคราวสำหรับแอปพลิเคชัน แต่แอปพลิเคชันไม่ควรขึ้นอยู่กับเลเยอร์นี้เป็นแหล่งที่มาของความจริง
ที่เก็บข้อมูลแอปพลิเคชันแบบมีสถานะ
แม้ว่าในกรณีส่วนใหญ่จะมีประโยชน์ในการทำให้แอปพลิเคชันไร้สถานะ แต่แอปพลิเคชันเหล่านั้นที่ออกแบบมาเพื่อจัดเก็บข้อมูล เช่น ฐานข้อมูล ที่เก็บอ็อบเจ็กต์ ที่เก็บคีย์-ค่า จะต้องอยู่ในสถานะ มาดูกันว่าเหตุใดจึงปรับใช้แอปพลิเคชันเหล่านี้บน Kubernetes ลองใช้ MiniIO เป็นตัวอย่าง แต่หลักการที่คล้ายกันนี้ใช้กับระบบจัดเก็บข้อมูลบนคลาวด์ขนาดใหญ่อื่นๆ
แอปพลิเคชันแบบเนทีฟบนคลาวด์ได้รับการออกแบบมาเพื่อใช้ประโยชน์จากความยืดหยุ่นที่มีอยู่ในคอนเทนเนอร์อย่างเต็มที่ ซึ่งหมายความว่าพวกเขาไม่ได้ตั้งสมมติฐานเกี่ยวกับสภาพแวดล้อมที่จะนำไปใช้งาน ตัวอย่างเช่น MiniIO ใช้กลไกการเข้ารหัสการลบข้อมูลภายในเพื่อให้ระบบมีความยืดหยุ่นเพียงพอที่จะยังคงทำงานได้แม้ว่าดิสก์ครึ่งหนึ่งจะล้มเหลวก็ตาม MiniIO ยังจัดการความสมบูรณ์ของข้อมูลและความปลอดภัยโดยใช้การแฮชและการเข้ารหัสฝั่งเซิร์ฟเวอร์ที่เป็นกรรมสิทธิ์
สำหรับแอปพลิเคชันที่เน้นคลาวด์เป็นหลัก Local Persistent Volume (PV) จะสะดวกที่สุดในการเป็นที่จัดเก็บข้อมูลสำรอง PV ภายในให้ความสามารถในการจัดเก็บข้อมูลดิบ ในขณะที่แอปพลิเคชันที่ทำงานบน PV เหล่านี้รวบรวมข้อมูลอย่างอิสระเพื่อปรับขนาดข้อมูลและจัดการความต้องการข้อมูลที่เพิ่มขึ้น
แนวทางนี้ง่ายกว่ามากและปรับขนาดได้ดีกว่า PV ที่ใช้ CSI อย่างมาก ซึ่งแนะนำการจัดการข้อมูลหลายชั้นและความซ้ำซ้อนในระบบ ประเด็นก็คือเลเยอร์เหล่านี้มักจะขัดแย้งกับแอปพลิเคชันที่ออกแบบมาให้มีสถานะ
การเคลื่อนไหวที่แข็งแกร่งไปสู่การแยกข้อมูลจากการคำนวณ
ในบทความนี้ เราได้พูดคุยเกี่ยวกับวิธีที่แอปพลิเคชันได้รับการปรับให้ทำงานโดยไม่บันทึกสถานะ หรือกล่าวอีกนัยหนึ่ง การจัดเก็บข้อมูลจะถูกแยกออกจากการประมวลผล โดยสรุป เรามาดูตัวอย่างที่แท้จริงของแนวโน้มนี้กัน
ซึ่งเป็นแพลตฟอร์มการวิเคราะห์ข้อมูลที่โดดเด่น ซึ่งแต่เดิมมีสถานะและใช้งานบน HDFS อย่างไรก็ตาม ในขณะที่ Spark ก้าวเข้าสู่โลกที่มีระบบคลาวด์เป็นศูนย์กลาง แพลตฟอร์มดังกล่าวก็กำลังถูกใช้งานแบบไร้สัญชาติมากขึ้นโดยใช้ `s3a` Spark ใช้ s3a เพื่อถ่ายโอนสถานะไปยังระบบอื่น ในขณะที่คอนเทนเนอร์ Spark เองก็ทำงานแบบไร้สถานะโดยสิ้นเชิง ผู้เล่นระดับองค์กรรายใหญ่อื่นๆ ในด้านการวิเคราะห์ข้อมูลขนาดใหญ่ โดยเฉพาะ , , พวกเขายังย้ายไปทำงานโดยมีการแยกการจัดเก็บข้อมูลและการคำนวณไว้ด้วย
รูปแบบที่คล้ายกันนี้ยังสามารถเห็นได้บนแพลตฟอร์มการวิเคราะห์ขนาดใหญ่อื่นๆ เช่น Presto, Tensorflow ถึง R, Jupyter การโอนย้ายสถานะไปยังระบบจัดเก็บข้อมูลบนคลาวด์ระยะไกล จะทำให้การจัดการและปรับขนาดแอปพลิเคชันของคุณง่ายขึ้นมาก นอกจากนี้ยังอำนวยความสะดวกในการพกพาแอปพลิเคชันไปยังสภาพแวดล้อมที่หลากหลาย
ที่มา: will.com