เป็นเวลาหลายปีแล้วที่เราเฝ้าดู Microsoft เททรัพยากรจำนวนมหาศาลลงในระบบย่อย Windows สำหรับ Linux มันถูกวางตำแหน่งให้เป็นอีควอไลเซอร์ที่ยอดเยี่ยม ซึ่งเป็นสะพานเชื่อมที่ทำให้ Windows กลายเป็นพลเมืองชั้นหนึ่งสำหรับพวกเราที่ชื่นชอบ Linux มานานแล้ว
WSL นั้นน่าประทับใจอย่างปฏิเสธไม่ได้ การมีเคอร์เนล Linux ที่ทำงานควบคู่ไปกับ Windows พร้อมด้วยการผสานรวมในระดับนี้ถือเป็นความสำเร็จทางวิศวกรรม ยังมีคุณสมบัติที่เป็นพื้นฐานของ Linux ซึ่งถักทออย่างลึกซึ้งในสถาปัตยกรรมของมัน แม้แต่เลเยอร์เวอร์ช่วลไลเซชั่นที่ซับซ้อนที่สุดก็ไม่สามารถเลียนแบบความสง่างามของมันได้
ไม่ใช่ UI ที่ฉูดฉาดหรือเฟรมเวิร์กที่ทันสมัย แต่เป็นการควบคุมทรัพยากรกระบวนการแบบเนทีฟ ละเอียด และโปร่งใสผ่าน cgroups ซึ่งเปิดเผยผ่านอินเทอร์เฟซระบบไฟล์แบบธรรมดา ความสามารถนี้เป็นรากฐานของการวางคอนเทนเนอร์สมัยใหม่ และแสดงถึงระดับความโปร่งใสของระบบที่ทำให้แนวทางการจัดการทรัพยากรของ Windows ไม่เพียงแต่ดูแตกต่าง แต่ยังน่าอับอายอย่างแท้จริงเมื่อเปรียบเทียบกัน
ระบบไฟล์ cgroup
ควบคุมทรัพยากรผ่านไฟล์ง่ายๆ
Cgroups ช่วยให้คุณสามารถจัดสรร จำกัด และตรวจสอบทรัพยากรระบบ เช่น CPU หน่วยความจำ และ I/O ข้ามกลุ่มกระบวนการ (ทุกสิ่งที่คุณมักจะสนใจ) เพียงอย่างเดียวก็ไม่ใช่เรื่องแปลก เนื่องจากระบบปฏิบัติการส่วนใหญ่มีกลไกบางอย่างสำหรับการควบคุมทรัพยากร
สิ่งที่ทำให้ Linux แตกต่างคือวิธีการเปิดเผยการควบคุมนี้ Cgroups ปรากฏเป็นระบบไฟล์ โดยทั่วไปจะเมาท์ที่/sys/fs/cgroup การจัดการทรัพยากรจะกลายเป็นการโต้ตอบกับไฟล์และไดเร็กทอรี และในการสร้างสภาพแวดล้อมที่มีข้อจำกัด คุณจะต้องสร้างไดเร็กทอรี เขียนค่าลงในไฟล์ควบคุม และกำหนดกระบวนการให้กับไดเร็กทอรีนั้น
คุณสามารถจำกัดกระบวนการไว้ที่โควต้า CPU คงที่และเพดานหน่วยความจำด้วยคำสั่งเชลล์จำนวนหนึ่ง โดยไม่ต้องเกี่ยวข้องกับการคอมไพล์ การเรียก API หรือการสนับสนุนใดๆ ระบบตอบสนองทันทีและคาดเดาได้ (ซึ่งหายากกว่าที่ควรจะเป็น) นี่ไม่เพียงแต่สะดวกเท่านั้น แต่ยังเปลี่ยนวิธีคิดของคุณเกี่ยวกับระบบอีกด้วย การจัดการทรัพยากรกลายเป็นสิ่งที่คุณทดลองได้โดยตรง ไม่ใช่สิ่งที่ซ่อนอยู่หลังเครื่องมือหลายชั้น
บน Windows สิ่งที่ใกล้เคียงที่สุดคือวัตถุงาน (ส่วนที่คนส่วนใหญ่จำได้ไม่ชัดเจนมีอยู่) อนุญาตให้มีกระบวนการจัดกลุ่มและใช้ขีดจำกัด แต่อินเทอร์เฟซแตกต่างไปจากเดิมอย่างสิ้นเชิง การโต้ตอบเกิดขึ้นผ่าน Windows API โดยต้องใช้โค้ดใน C, C++ หรือ.NET ต้องเรียกใช้ฟังก์ชันเช่น CreateJobObject และ SetInformationJobObject จัดการการจัดการ และจัดการข้อผิดพลาดอย่างชัดเจน
แม้แต่ข้อจำกัดง่ายๆ ก็ยังต้องมีการตั้งค่าที่ไม่สำคัญ การใช้บรรทัดคำสั่งเป็นแบบอ้อม โดยปกติจะรวมผ่าน PowerShell หรือยูทิลิตี้แบบกำหนดเอง เป็นผลให้นักพัฒนาส่วนใหญ่ไม่เคยมีส่วนร่วมกับสิ่งพื้นฐานเหล่านี้โดยตรง พวกเขาพึ่งพาเครื่องมือระดับสูงที่ปิดบังกลไกพื้นฐาน
รากฐานของภาชนะ
เหตุใดคอนเทนเนอร์จึงให้ความรู้สึกดั้งเดิมบน Linux
Cgroups ไม่ใช่คุณลักษณะที่แยกได้ นอกจากเนมสเปซแล้ว ยังสร้างพื้นฐานของคอนเทนเนอร์ด้วย เมื่อคอนเทนเนอร์ทำงานบน Linux จะไม่มีเลเยอร์นามธรรมเพิ่มเติมที่บังคับใช้ขีดจำกัด (ไม่มีกล่องเพิ่มเติมภายในกล่อง) รันไทม์ของคอนเทนเนอร์จะสร้าง cgroup เขียนข้อจำกัด และวางกระบวนการไว้ข้างใน จากนั้นเคอร์เนลจะจัดการส่วนที่เหลือ
บน Windows การบรรจุคอนเทนเนอร์จะเป็นไปตามเส้นทางอื่น การใช้งานจำนวนมากอาศัยการแยก Hyper-V ซึ่งแนะนำเลเยอร์เครื่องเสมือนแม้ว่าอินเทอร์เฟซจะแนะนำบางสิ่งที่มีน้ำหนักเบาก็ตาม
สิ่งนี้ทำให้เกิดความโดดเดี่ยวแต่เพิ่มความซับซ้อนและค่าใช้จ่าย แม้จะอยู่ในโหมดแยกกระบวนการ Windows อาศัยการผสมผสานระหว่างวัตถุงานและระบบย่อยอื่นๆ ที่ไม่ได้ออกแบบให้เป็นอินเทอร์เฟซแบบรวม ชิ้นส่วนต่างๆ มีอยู่ แต่ไม่มีรูปแบบที่สอดคล้องกัน นักพัฒนาไม่สามารถนำทางไดเรกทอรีเดียวและสังเกตขีดจำกัดทรัพยากรแบบเรียลไทม์ แต่ข้อมูลจะกระจัดกระจายไปตาม API และเครื่องมือการดูแลระบบ (กระจายแบบบาง)
ความแตกต่างนี้ชัดเจนเมื่อทำการดีบัก บน Linux ข้อจำกัดด้านทรัพยากรจะมองเห็นได้และแก้ไขได้ผ่านระบบไฟล์ บน Windows การทำความเข้าใจข้อจำกัดเหล่านั้นจำเป็นต้องมีการนำทางเครื่องมือที่ไม่เคยออกแบบมาเพื่อการตรวจสอบง่ายๆ
ความโปร่งใสและการออกแบบระบบ
ปรัชญาที่แตกต่างกันเป็นตัวกำหนดประสบการณ์
Linux มีแนวโน้มที่จะเปิดเผยฟังก์ชันการทำงานของเคอร์เนลผ่านอินเทอร์เฟซที่เรียบง่ายและสม่ำเสมอ นามธรรมของระบบไฟล์ถูกใช้ซ้ำๆ เนื่องจากสามารถประกอบได้และคุ้นเคย สิ่งนี้จะช่วยลดอุปสรรคในการเข้าสู่ และนักพัฒนาที่เข้าใจคำสั่งเชลล์พื้นฐานสามารถทดลองกับขีดจำกัดทรัพยากรได้อย่างรวดเร็ว Windows ได้รับความนิยมในอดีต และความซับซ้อนถูกซ่อนอยู่เบื้องหลัง API และอินเทอร์เฟซที่ได้รับการจัดการ ซึ่งจะทำให้ได้พื้นผิวที่มันเงาแต่จำกัดการควบคุมโดยตรง
ระบบวัตถุประสงค์ของงานนั้นทรงพลัง แต่ต้องใช้ความมุ่งมั่นในการทำความเข้าใจ (และต้องใช้ความอดทนเป็นอย่างมาก) ข้อมูลประสิทธิภาพมีอยู่ แต่มักจะผ่านระบบที่กระจัดกระจาย เช่น ตัวนับประสิทธิภาพและ WMI ชิ้นส่วนเหล่านี้ได้รับการพัฒนาอย่างอิสระและไม่ได้นำเสนอแบบจำลองแบบครบวงจร
ผลลัพธ์คือระบบที่มีความสามารถแต่ไม่สามารถค้นพบหรือประกอบได้ง่าย และนักพัฒนาโต้ตอบกับเครื่องมือมากกว่าตัวระบบเอง เมื่อคุณใช้ Linux และกระบวนการทำงาน คุณสามารถดู cgroup ของกระบวนการได้ทันทีเพื่อดูว่ามีอะไรถึงขีดจำกัดบ้าง บน Windows การสืบสวนแบบเดียวกันนั้นรู้สึกเหมือนเป็นงานที่น่าเบื่อ บังคับให้คุณต้องใช้เครื่องมือต่างๆ มากมายเพื่อค้นหาคำตอบที่เหมือนกัน
ความขัดแย้งของ WSL
Linux ภายใน Windows พิสูจน์ประเด็นนี้แล้ว
WSL พยายามเชื่อมช่องว่างนี้โดยการฝัง Linux ไว้ใน Windows ประสบความสำเร็จในการให้การเข้าถึงเครื่องมือ Linux แต่ยังเน้นถึงข้อจำกัดพื้นฐานด้วย เมื่อคุณเรียกใช้คอนเทนเนอร์ภายใน WSL คุณไม่ได้ใช้การจัดการทรัพยากรของ Windows คุณกำลังใช้ Linux cgroups ภายในเคอร์เนล Linux ที่ทำงานในสภาพแวดล้อมเสมือนจริง
ที่เกี่ยวข้อง
WSL ดี แต่ยังไม่เพียงพอสำหรับฉันที่จะกลับไปใช้ Windows
ต้องใช้เวลามากกว่าเครื่อง Linux เสมือนในการทำให้ฉันอดทนกับ Copilot
โฮสต์ Windows ยังคงแยกจากกัน และกลไกดั้งเดิมของโฮสต์ไม่ได้เป็นส่วนหนึ่งของเวิร์กโฟลว์นั้น เพื่อให้เป็นไปตามที่นักพัฒนาสภาพแวดล้อมคาดหวัง Windows จึงนำเข้า Linux แทนที่จะขยายโมเดลของตัวเอง Docker Desktop สะท้อนรูปแบบเดียวกัน คอนเทนเนอร์ทำงานภายในเครื่องเสมือน Linux ประสบการณ์นี้ให้ความรู้สึกดั้งเดิม แต่ Windows ไม่ได้จัดเตรียมฟังก์ชันการทำงานพื้นฐานไว้เอง
เฟรมเวิร์กเดสก์ท็อป
ยี่ห้อ
กรอบการทำงาน
ซีพียู
AMD Ryzen AI Max 300 ซีรีส์
ผลที่ตามมาในทางปฏิบัติ
ซึ่งความแตกต่างนี้ปรากฏขึ้นจริง ๆ
ความแตกต่างเหล่านี้ปรากฏให้เห็นในการพัฒนาในแต่ละวัน เมื่อคุณใช้ Linux การเรียกใช้คลัสเตอร์ Kubernetes ในเครื่องนั้นตรงไปตรงมา เนื่องจากเครื่องมือเช่น Kind หรือ Minikube ใช้เคอร์เนลของโฮสต์โดยตรง ขีดจำกัดทรัพยากรของคุณจะทำงานเหมือนกับที่เกิดขึ้นจริงทุกประการ และคุณสามารถแก้ไขจุดบกพร่องทุกอย่างโดยใช้เครื่องมือระบบมาตรฐาน บน Windows การตั้งค่าเดียวกันนั้นมักจะจบลงด้วยการซ่อนตัวอยู่ในเครื่องเสมือน และคุณถูกบังคับให้คำนึงถึงเลเยอร์พิเศษนั้นอย่างต่อเนื่องระหว่างปริมาณงานและฮาร์ดแวร์ของคุณ ซึ่งจะเป็นตัวกลางว่าทรัพยากรทำงานอย่างไรอย่างหลีกเลี่ยงไม่ได้
ที่เกี่ยวข้อง
วิธีเริ่มต้นคลัสเตอร์ Kubernetes ท้องถิ่นด้วย Minikube
Minikube เป็นการแจกจ่าย Kubernetes แบบขั้นต่ำที่ออกแบบมาเพื่อการใช้งานในการพัฒนาในท้องถิ่น
เมื่อเกิดข้อผิดพลาด คุณไม่สามารถมองดูที่คอนเทนเนอร์เพียงอย่างเดียวได้ คุณต้องกังวลเกี่ยวกับระบบการจัดประสานทั้งหมดและสภาพแวดล้อมเสมือนจริงไปพร้อมๆ กัน คุณสามารถเห็นรูปแบบเดียวกันได้ในระบบ CI บน Linux คุณสามารถบังคับใช้ขีดจำกัดผ่าน cgroups โดยมีค่าใช้จ่ายเกือบเป็นศูนย์ และจัดการการกำหนดค่าด้วยสคริปต์ง่ายๆ
ในทางตรงกันข้าม นักวิ่ง Windows มักจะต้องมีการตั้งค่าเพิ่มเติมอยู่เสมอ ไม่ว่าจะเป็น API เฉพาะทาง เลเยอร์สคริปต์เพิ่มเติม หรือการจำลองเสมือนเต็มรูปแบบ ระบบก็มีความสามารถแต่ไม่ตรงเท่า เมื่อเวลาผ่านไป ความขัดแย้งนั้นก็เพิ่มมากขึ้น ซึ่งเป็นเหตุผลว่าทำไมระบบที่ง่ายกว่านั้นจึงง่ายต่อการบำรุงรักษาและมีเหตุผล
ความแตกต่างเชิงโครงสร้าง
ทำไม Gap นี้ถึงปิดยาก
สิ่งที่ทำให้ฟีเจอร์ cgroup น่าอับอายเป็นพิเศษสำหรับ Windows คือการเปิดเผยบางสิ่งพื้นฐานเกี่ยวกับวิถีการออกแบบระบบปฏิบัติการในยุคของการประมวลผลแบบคลาวด์และคอนเทนเนอร์
ลีนุกซ์ไม่ได้ถูกออกแบบตั้งแต่เริ่มแรกโดยคำนึงถึงคอนเทนเนอร์เป็นหลัก (ตรงกันข้ามกับความเชื่อที่นิยม) ฟังก์ชันการทำงานของ cgroup เกิดขึ้นทีละน้อย โดยเพิ่มโดยนักพัฒนาเคอร์เนลที่ตระหนักถึงคุณค่าของการควบคุมทรัพยากรแบบละเอียดผ่านอินเทอร์เฟซที่เรียบง่าย แต่ฟีเจอร์นี้เข้ากันได้อย่างเป็นธรรมชาติกับปรัชญาของ Linux จนให้ความรู้สึกราวกับว่ามันอยู่ที่นั่นมาโดยตลอด
ที่เกี่ยวข้อง
รูปแบบการทดสอบ 6 รูปแบบที่สคริปต์ Bash ในโลกแห่งความเป็นจริงใช้จริง
ตรวจสอบว่าไฟล์นั้นเป็นไฟล์จริงๆ หรือไม่ สตริงประกอบด้วยสิ่งใดๆ หรือไม่ และคุณสามารถรันโปรแกรมด้วยรูปแบบที่สำคัญเหล่านี้ได้หรือไม่
อินเทอร์เฟซระบบไฟล์ ไฟล์ควบคุมแบบข้อความ ความสามารถในการเขียนฟังก์ชันการทำงานด้วยสคริปต์ง่ายๆ คุณลักษณะทั้งหมดนี้สอดคล้องอย่างสมบูรณ์แบบกับประเพณี Unix ที่ Linux สืบทอดและขยายออกไป Windows ขาดการเชื่อมโยงกันในเรื่องการจัดการทรัพยากรและการบรรจุคอนเทนเนอร์ คุณลักษณะดังกล่าวมีอยู่ในบางรูปแบบกระจัดกระจายทั่วทั้งระบบ แต่ขาดวิสัยทัศน์ที่เป็นหนึ่งเดียวและอินเทอร์เฟซที่สอดคล้องกันซึ่งทำให้กลุ่ม cgroup ของ Linux มีประสิทธิภาพและเข้าถึงได้มาก
ความเป็นจริงในทางปฏิบัติที่คุณไม่อาจมองข้ามได้
Microsoft ได้ลงทุนทรัพยากรจำนวนมหาศาลในการพัฒนาคอนเทนเนอร์ Windows ในการปรับปรุงการรวม Docker และในการสร้าง WSL แต่ความพยายามเหล่านี้ไม่สามารถเอาชนะการตัดสินใจทางสถาปัตยกรรมขั้นพื้นฐานที่ทำเมื่อหลายสิบปีก่อนได้ (ประวัติศาสตร์มีแรงผลักดัน) โดยพื้นฐานแล้วบริษัทกำลังพยายามดัดแปลงความสามารถในการบรรจุคอนเทนเนอร์สมัยใหม่ลงบนระบบที่ออกแบบมาสำหรับยุคที่แตกต่างกัน ในขณะที่ Linux พัฒนาไปพร้อมกับการเคลื่อนไหวของคอนเทนเนอร์ ซึ่งเป็นการเพิ่มความสามารถที่นักพัฒนาต้องการในลักษณะที่เป็นธรรมชาติและสอดคล้องกัน
ฉันไม่คาดหวังว่า Microsoft จะเขียนเคอร์เนล NT ใหม่เพื่อสะท้อนปรัชญา Unix; โมเมนตัมของทศวรรษเป็นสิ่งที่ยากจะแก้ไข ตราบใดที่การโต้ตอบหลักของฉันกับระบบเกี่ยวข้องกับการนำทางหลายชั้นของนามธรรมเพื่อดูว่าทำไมกระบวนการถึงชนกำแพง ป้าย “ชั้นหนึ่ง” สำหรับการพัฒนา Windows ให้ความรู้สึกเหมือนเป็นเป้าหมายทางการตลาดมากกว่าความเป็นจริงทางเทคนิค WSL เป็นสะพานเชื่อมที่ยอดเยี่ยม แต่ท้ายที่สุดแล้ว ถือเป็นการสารภาพว่าลักษณะดั้งเดิมของโฮสต์ไม่ได้ถูกสร้างขึ้นสำหรับวิธีการทำงานของเราในตอนนี้
*️⃣ ลิงค์ที่มา:
PowerShell, เนมสเปซ, WSL นั้นดี แต่ก็ยังไม่เพียงพอสำหรับฉันที่จะกลับไปใช้ Windows , Docker Desktop, kind , Minikube , วิธีการ เริ่มคลัสเตอร์ Kubernetes ท้องถิ่นด้วย Minikube , รูปแบบการทดสอบ 6 รูปแบบที่สคริปต์ Bash ในโลกแห่งความเป็นจริงใช้จริง